Ticket #1136 (reopened defect)

Opened 12 years ago

Last modified 11 years ago

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

Reported by: jdreed Owned by:
Priority: blocker Milestone: Precise Beta
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description (last modified by jdreed) (diff)

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.

Change History

comment:1 Changed 12 years ago by 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.

comment:2 Changed 12 years ago by jdreed

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

comment:3 Changed 12 years ago by jdreed

  • Status changed from new to committed

comment:4 Changed 12 years ago by jdreed

  • Description modified (diff)
  • Summary changed from firefox-extension doesn't install on Precise to firefox-extension doesn't work with modern FF on new installs

comment:5 Changed 12 years ago by 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.

comment:6 Changed 12 years ago by 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 (After the profile has been created). 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.

Last edited 12 years ago by jdreed (previous) (diff)

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by jdreed

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

comment:9 Changed 12 years ago by 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.

comment:10 Changed 12 years ago by 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.

comment:11 follow-up: ↓ 18 Changed 12 years ago by 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.


comment:12 Changed 12 years ago by 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.

comment:13 Changed 12 years ago by 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)

comment:14 Changed 12 years ago by jdreed

  • Status changed from committed to development

comment:15 Changed 12 years ago by 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.

comment:16 Changed 12 years ago by jdreed

  • Status changed from development to proposed

comment:17 Changed 12 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed

comment:18 in reply to: ↑ 11 Changed 11 years ago by 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.

comment:19 Changed 11 years ago by jdreed

  • Status changed from closed to reopened
  • Resolution fixed deleted
Note: See TracTickets for help on using tickets.