firefox-extension doesn't work with modern FF on new installs

[jdreed]

The extension has been broken for a while now. We should have stopped using /usr/lib/firefox/extensions back in the FF4 or FF5 days. /usr/lib/firefox-addons/extensions is the canonical location. I'm fairly certain we can not even bother conditionally installing into /usr/lib/firefox/extensions on all the releases we care about.

[jdreed]

This apparently only affects clean installs? I built a version of firefox-extension that doesn't symlink into /usr/lib/firefox-addons, and that installs fine. Then the original version will install fine on top of it.

[jdreed]

Oh. /usr/lib/firefox/extensions is now a symlink to /usr/lib/firefox-addons/extensions. "Yay"

[jdreed]

r25503

[jdreed]

OK, fixed differently in r25514. I ran into some weirdness in testing where the MIT extension changes didn't take effect until the third or 4th restart of Firefox, but I can't narrow it down any further.

[jdreed]

OK, this is awesome. If FF extension is installed, and the user doesn't yet have a FF profile, the extension's changes (e.g. home page, network.negotiate-auth.trusted-uris, etc) won't take effect until any file in /usr/lib/debathena-firefox-extension is touch(1)ed. I don't know if this is the result of how we're shipping it, or what. And I'm not sure how to fix it. We should maybe consider looking at xul-ext-wrapper and other extensions that clearly work and see how it's done.

[jdreed]

This is actually differently awesome.

• The chrome (About->Athena On-LIne Help) is loaded regardless.
• The MIT CA is not installed regardless
• The defaults (e.g. home page, network.negotiate-auth.trusted-uris) are only applied after the touch(1) I mentioned.

I wonder if our extension is just very out of date, or there's some interference with Ubuntu's extensions, or what.

[jdreed]

Right, well, part of the problem is that nobody ever did  this for the extension, so this has been Wrong(tm) since FF4.

[jdreed]

I propose the following:

-Re-do the extension for Gecko 2.0 and ensure its functionality.
-Move it to trunk/debathena/debathena since the autogoo is unnecessary
-Make some changes while we're at it: A menu link (maybe even a toolbar?) for getting certs, testing certs, and Hermes as well as the OLH one.

I'm going to go ahead and do that unless someone convinces me it's a bad idea.

[jdreed]

So, this bug is also blocking reinstalls, so I'm going to build r25514 to -development and push it out after finals, so that hotline can reinstall machines again.

I'm still re-doing the extension for Gecko 2.0, but I don't want to block reinstalls.

[jdreed]

OK, the extension packaging is all kinds of wrong. We do a transformation on ubufox.js in an attempt to unclobber ubufox's changes. Except, that's never worked, because we point at the properties file, which doesn't contain, for example, network.negotiate-auth.trusted-uris. We could duplicate all the preferences from athena.js into the properties file, but I'm not enthused.

Possible solutions:

• Conflict with ubufox/xul-ext-ubufox. Probably the "right" answer, but we lose some of the functionality of ubufox (e.g. automated plugin finder, etc)
• Move our extension into /usr/share/mozilla/extensions, which is where ubufox is. Then our prefs override ubufox's prefs (yes, really)
• Add a preferences observer to re-clobber the preferences back when ubufox is done with them
• Do something with a .cfg file and locked prefs, or whatever.

Thoughts?

[jdreed]

To clarify, by "never worked", I'm talking about Gecko 2.0. This worked in FF3, because extensions are unpacked and applied differently. Even if we continued to transform the correct ubufox.js (See also #1058 #865), in FF 6 (and possibly earlier), only the homepage properties gets applied. trusted-uris is still clobbered.

We can of course fix those two tickets and continue to use the ubufox.js method, but we'll need to throw other properties in there, or simply point at our prefs file or something, but I don't think we can do anything like #include our file? Maybe we can.

[jdreed]

Er, wait, we don't care if trusted-uris gets clobbered. ubufox's setting is more permissive than ours, and it works just fine with Touchstone. So really, this is just the homepage.

I'm not convinced we care, and I'm not convinced there's anything other than aesthetic value in having the MIT homepage. I'm also not convinced diverting ubufox.js was a good idea, since the user could easily have added their own customizations (that's what it's for), which they'd have lost when they uninstalled Debathena. (and we don't have -manual-firefox-extension)

[jdreed]

OK, 10.0.7-0debathena5 is in production, which fixes the installation problem, as that was critical. 10.1-0debathena2 is in -dev, which actually restores the functionality, and unbreaks the transition. I'd like to try and get this out soon before the summer programs show up.

[jdreed]

OK, this is still broken. We need to do one of the things from 11. I think I favor moving it into /usr/share/mozilla/extensions (which also means we don't need to have separate FF and iceweasel directories. Or we can leave it as is, and note in the description that ubufox will override most of these customizations. Upstream's solution is that people should make changes in ubufox.js. So I guess we could go back to diverting it now that the location is unlikely to move again.