573355 - Optimize order of AddOn check

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[Georg Maaß]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11pre) Gecko/20100612 Lightning/1.0b1 SeaMonkey/2.0.6pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11pre) Gecko/20100612 Lightning/1.0b1 SeaMonkey/2.0.6pre

When trying to install a new AddOn to SM several checks are done i.e. check for secure updates and check for compatibility. Unfortunately checking for secure updates is done before compatibility check.

Therefore if an AddOn has insecure updates SM only informs me about not installing it due to insecure updates, but does not tell me whether the AddOn is compatible.

I would like to hear first whether it announces to be compatible. If it does not announce compatibility then I'm not interested in updates. So I would appreciate if compatibility is checked first and check for secure updates is done after wards.

Reproducible: Always

Comment 1

[Tony Mechelynck [:tonymec]]

- If the extension is not yet compatible with your browser/mailer, an update may make it compatible, so in that case you *should* be interested in updates.
- IIUC, the Mozilla doctrine is that unsafe updates are a worse security risk than incompatible extensions, and therefore to be checked first.

I expect this bug will be resolved WONTFIX. Dave, Henrik, what do you think?

Comment 2

[Georg Maaß]

Does this mean that incompatible AddOn are installed but disabled until an update makes it compatible?

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
> Does this mean that incompatible AddOn are installed but disabled until an
> update makes it compatible?

IIUC, and with default preferences in about:config
- If you try to install a new addon, it will only be installed if it is both compatible and provides either safe updates, or none at all.
- If you upgrade the browser/mailer, any already installed addons which are found to be incompatible with the new version will remain installed, but disabled until an addon upgrade makes them compatible again.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Can we get an example of such an add-on? Further what was the behavior of Firefox 3.6 in such a condition?

Comment 5

[Dave Townsend [:mossop] (PTO until July 20)]

(In reply to comment #4)
> Can we get an example of such an add-on? Further what was the behavior of
> Firefox 3.6 in such a condition?

He is using Seamonkey 2.0 (same code as Firefox 3.5).

This was fixed on trunk by bug 553169

Comment 6

[Georg Maaß]

What I tried to install is this:

http://ted.mielczarek.org/code/mozilla/extensiondev/extensiondev.xpi

It did not say anything about incompatibilty but complained only about providing an insecure update. When unzipping it and looking at the install.rdf I saw it is not intended for SM at all, but it did say anything about incompatibility but complained only about providing insecure update.

Comment 7

[Tony Mechelynck [:tonymec]]

Aha! Georg, I think you misunderstand what is meant by "compatibility check". It means checking that the application version falls between the minVersion and maxVersion mentioned for this app in the extension's install.rdf (or, if the extension also mentions a Toolkit version range, that's the app's Gecko version, 1.9.11pre in your case, falls in that range). Ranges are understood "both bounds included" and .* at the end of the maxVersion means infinity.

In your case, the extension doesn't even support either SeaMonkey (i.e. {92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}) or Toolkit (i.e. [e-mail]) so there are no ranges to compare anything with that SeaMonkey knows about and therefore this is a different case: IIRC, with SeaMonkey 2.0, if this extension provided safe updates you would not get a compatibility error but an error popup with some unobvious-to-understand error code. I don't know (yet) if that has changed with SeaMonkey 2.1a2pre's "new addons manager" covered by bug 553169 et al.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Marking as verified fixed based on the landing of bug 553169.

Dave, do we have enough coverage by automated tests, that we don't need a manual test?