Closed Bug 591601 Opened 15 years ago Closed 14 years ago

Allow developers on trunk builds to install extensions

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
Other
All
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: BenB, Unassigned)

References

Details

Extensions on AMO must not have a maxVersion higher than the last released beta. Furthermore, while AMO lets me override that, Firefox does not. That *guarantees* that I cannot install any extensions from AMO on trunk or nightly builds. That's ... bad, because I eat dogfood and use trunk builds as main browser. There are several ways around it: 1. manually hack install.rdf, delete extension.* etc., and repeat after every ext update. 2. install Nightly Tester Tools, but that itself has this problem, back to 1. 3. put extensions.checkCompatibility.4.0b = false in <about:config> but none cuts it. extensions.checkCompatibility.4.0b = false is close, but: 1. I'd need to set it again for every version. I want one pref which I can set in my main and dev profile and forget about it, not having to set it again and again 2. For my throw-away dev/test profiles, I want prefs to be easily switchable, by going to <about:config> and double-click on it, not remember / write down a string and manually enter/copy it. So, please: 1. Also query plain "extensions.checkCompatibility", not just "extensions.checkCompatibility + "." + version <http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/mozapps/extensions/XPIProvider.jsm#1107> 2. Add extensions.checkCompatibility = true to the default prefs
Severity: normal → minor
> 1. Also query plain "extensions.checkCompatibility", not just > "extensions.checkCompatibility + "." + version see bug 521905...
Assignee: dao → nobody
Also, 3. nightlies (not betas) should probably have extensions.checkCompatibility.4.0b = false set, given that they otherwise can't install any extensions. > see bug 521905... ack, but I still don't think this is practical as-is.
Well, practical or not, the "official" standpoint is that the change from a blanket Boolean to one per version is a security feature against shooting yourself in the foot. As soon as the next version number is known, you can still set it (even in advance) with about:config or even user.js, and then forget about it until the _following_ version; but of course it becomes your own responsibility to disable misbehaving extensions.
Please don't abuse the term "security". "against shooting yourself in the foot." If I use nightlies or trunk builds, I typically know what I do. Please don't patronize developers. I don't want to have to regularly do stuff just to make the software *work*.
I'm not patronizing, I'm giving my own interpretation (which in my mind is neither laudative nor pejorative) of what I read from the developers, and I don't feel it excessively onerous to add one Boolean pref per version, which is what I do. I think this bug is not going to be fixed, but I'll leave it to the owner or peer to declare it WONTFIX — or not.
No one is patronizing developers or anyone else. There are many more nightly users that are not developers vs. developers and both developers and non-developers have shot themselves in the foot with the single preference which was implemented previously. That single preference was referenced often as a way to make extensions work. We found that people often forgot that they had set the preference and then blamed Firefox when it stopped working, ui was broken, etc. due to this.
OK, if you have another solution. Fine, the problem, very concretely, is: I've often been told "install extension ABC" to solve a certain problem, as a developer. Unfortunately, that doesn't work: The extensions version range is so strict that it's pretty much *guaranteed* to never work with the trunk builds that I use. None of the extensions work for me. Now, there are at least 2 ways around that: * Hack install.rdf. That requires going to profile folder manually, finding (on the commandline) which {864764764} folder is the right extension, editing install.rdf, deleting extension.* files, and restarting firefox (not fun with a few hundred pages open). Forgot something, did something wrong: repeat, restart firefox again. Then, the extension is updated. Overwrites install.rdf. Do it all again. Repeat. * Install Nightly Tester Tools <https://addons.mozilla.org/en-US/firefox/addon/6543/>. They allow to override compat, that's great. Unfortunately, they itself suffer from the same problem! Go back to 1. That sucks massively. Please fix this somehow. Proposals: * Allow extensions targetted at developers, or at least the Nightly Tester Tools, to use "5.0" as maxVersion. Even if it may break, the current situation is *guaranteed* to always be broken - the ext is intended for nightlies, and I simply cannot install "Nightly Tester Tools" from AMO on nightlies, Firefox outright refuses to install, no override. I'd have to manually download, unpack the XPI, re-zip it, and install from harddisk. * Build "Override compat" into Firefox, probably with UI turned off with an <about:config> pref (but with default pref, so that I can just double-click on throw-away development profiles) As-is, extensions on trunk builds are just PAIN. I *hate* extensions because of that. I'd like to just use Flashblock and co with Firefox trunk builds, please!
(This was the original mail. The pref "extensions.checkCompatibility.4.0b = false" does *not* cut it, because I have to regularly pamper it.)
I've had to add the following two preferences while on trunk to override the compatibility check. extensions.checkCompatibility.4.0b false extensions.checkCompatibility.3.7a false I'm having difficulty understanding why having to add two preferences during this development cycle would cause such a strong reaction.
(In reply to comment #9) > I've had to add the following two preferences while on trunk to override the > compatibility check. > extensions.checkCompatibility.4.0b false > extensions.checkCompatibility.3.7a false > > I'm having difficulty understanding why having to add two preferences during > this development cycle would cause such a strong reaction. AS a Thunderbird Nightly tester, It's just one more PIA to worry about. Especially with the quick version changes we are seeing. I'm usually dealing with multiple profiles as well. Nothing more annoying than in the middle of bug triage, an extension that you need is not available.
(In reply to comment #9) > I've had to add the following two preferences while on trunk to override the > compatibility check. > extensions.checkCompatibility.4.0b false > extensions.checkCompatibility.3.7a false > > I'm having difficulty understanding why having to add two preferences during > this development cycle would cause such a strong reaction. What's most annoying to me is that the pref for the current version doesn't exist by default, so you need to create it and be extra careful to get the name right.
Yeah. Please consider comment 2 as possibility. That would mean that nightlies "just work". Without this pref, they simply can't use extensions (arguably a bug), so in reality almost any nightly tester would need it. And the pref wouldn't be set anymore with betas, even with the same profile. Downside: the pref changing from false to true to false means that it gets reset, unless you manually put it in user.js (not <about:config>).
Another option, would be allowing a wildcard option. extensions.checkCompatibility.4.* That way it would apply through all point releases. That option wouldn't have to be "public knowledge"
On a side note, at this particular time, an extension which doesn't advertise support of Firefox 4.0 (or Thunderbird 3.2 or SeaMonkey 2.1 or Toolkit 2.0 etc.) probably hasn't been updated for the Great XPCOM Bustage, which means a particularly high risk (not a certainty) of breakage if used with those versions. (OTOH, of course, advertising support is no guarantee that it will work: see bug 590292 for a particularly gory story which happened a few days ago with Lightning.)
Tony, read - for example - the very first sentence of this bug, or comment 7. Even extensions that are uptodate with beta 5 are not allowed to install on trunk. That's precisely the problem here.
Regarding the examples of this being annoying, I agree it can be annoying having to add the preference. I was referring to the strong reaction in several of the comments. (In reply to comment #15) > Tony, read - for example - the very first sentence of this bug, or comment 7. > Even extensions that are uptodate with beta 5 are not allowed to install on > trunk. That's precisely the problem here. If that is "precisely the problem" then the proposed solution would also need to take into account distinguishing between extensions that are "uptodate with beta 5" and extensions that are not "uptodate with beta 5". A solution that satisfies the goals of bug 521905 would need to be proposed.
The Add-on Compatibility Reporter (https://addons.mozilla.org/en-US/firefox/addon/15003/) is always compatible with trunk and disables add-on compatibility checking. That is about as official as a channel I think we can give for this; incompatible extensions causing start-up crashes are a real problem and users don't know how to fix it.
fligtar, thanks for the note. The "Nightly Tester Tools" were suggested to me for this exact purposes and as the official workaround. Can we get this straighted out without "having to know", e.g. install this addon with nightlies? > users don't know how to fix it. Please note that the subject specifically says "developers".
Another possible solution that was floating around awhile back was to support "trunk" or "nightly" as a value for maxVersion. So any extension that has its maxVersion set to "nightly" would always be marked as compatible with nightlies. And AMO would support that value, but it would be re-set to the most current Firefox release version whenever a major version of Firefox was released. This would mean extensions couldn't stay automatically compatible with nightlies forever, without the author being proactive in keeping it updated.
> it would be re-set to the most current Firefox release version whenever > a major version of Firefox was released. ...which would nightlies shortly after the release automatically incompatible to everything, although they most likely still work. You're missing the point. I don't want these checks, at all. Safety-nets are fine. Not override-able safety nets may be fine for users. Not override-able safety nets are not fine for developers under any circumstance. I want this to just get out of the way! (And *stay* out of the way, not come back after a few months.)
Ben, which of the solutions that don't regress bug 521905 do you think is the best?
I think it would be best to disable compat check *by default* in nightlies. That could happen e.g. via a configure build-time flag, so that trunk users who compile themselves could also set it in .mozconfig (they need a mozconfig anyway, so that's even more convenient for them than a pref). Rationale here is that nightlies are currently pretty much incompatible to almost every extension out there, so basically can't use extensions, unless the developer jumps through annoying hoops. Another solution, which could be combined, is to show somewhere obviously, but unobtrusively in the main UI that there incompatible addons in used. E.g. a status bar button shows a "broken" icon with an integer number of such addons, and clicking on it shows the addon-manager, which shows clearly which addons are incompatible, but in use. Rationale here is to address the original concern of bug 521905: That people are running with broken extensions, are not aware of it, and then blame recent Firefox trunk changes for the breakage they cause.
(In reply to comment #22) > Another solution, which could be combined, is to show somewhere obviously, but > unobtrusively in the main UI that there incompatible addons in used. E.g. a > status bar button shows a "broken" icon with an integer number of such addons, > and clicking on it shows the addon-manager, which shows clearly which addons > are incompatible, but in use. This sounds like a useful feature to be added to the Add-on Compatibility Reporter.
(In reply to comment #19) > Another possible solution that was floating around awhile back was to support > "trunk" or "nightly" as a value for maxVersion. So any extension that has its > maxVersion set to "nightly" would always be marked as compatible with > nightlies. And AMO would support that value, but it would be re-set to the most > current Firefox release version whenever a major version of Firefox was > released. This would mean extensions couldn't stay automatically compatible > with nightlies forever, without the author being proactive in keeping it > updated. This sounds good, is there a bug for this already? I couldn't find one. A flag to disable the checks in general when building yourself doesn't sound bad either.
(In reply to comment #24) > This sounds good, is there a bug for this already? I couldn't find one. Not that I know of.
(In reply to comment #0) > So, please: > 1. Also query plain "extensions.checkCompatibility", not just > "extensions.checkCompatibility + "." + version > <http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/mozapps/extensions/XPIProvider.jsm#1107> > 2. Add extensions.checkCompatibility = true to the default prefs Can we please do this, as extensions.checkCompatibility.nightly or something? Manually adding the pref has just gotten more annoying. It's not like x.0a works half a year, then x.0b works half a year, but we're going from x.0a to y.0a every six weeks.
Depends on: 659048
(In reply to comment #26) > (In reply to comment #0) > > So, please: > > 1. Also query plain "extensions.checkCompatibility", not just > > "extensions.checkCompatibility + "." + version > > <http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/mozapps/extensions/XPIProvider.jsm#1107> > > 2. Add extensions.checkCompatibility = true to the default prefs > > Can we please do this, as extensions.checkCompatibility.nightly or something? We've now done this in bug 659048 and it seems to solve the problems talked about here so I believe we can call this fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Thanks
Status: RESOLVED → VERIFIED
Tests were included with the patch on bug 659048. So nothing else is necessary.
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.