Global Install Option

I wanted to put HTTPS-Everywhere into an RPM so its files are tracked, but installing the addon globally like this breaks the rule listing. It seems that opening the primary rule directory is hard-coded to use the user's profile.

Attached is a quick patch to check in the addon install location instead of the user profile. It should be noted that I have zero experience writing Mozilla addons, so there is a 50/50 chance of it destroying your computer.

I'll also include the RPM spec if it helps anyone test a global install more easily. (It is intended for a recent version of Fedora.)

Trac:
Username: dm0

added component::https everywhere/eff-https everywhere owner::pde priority::medium reporter::dm0 resolution::fixed status::closed type::defect labels

Trac:
Username: dm0

mozilla-https-everywhere-global-rules.patch

Patch to use addon install location

Trac:
Username: dm0

Trac:
Username: dm0

mozilla-https-everywhere.spec

RPM spec to test installing the addon globally

Trac:
Username: dm0

Trac:
Status: new to accepted

Trac:
Status: accepted to needs_review

Reportedly some debian developers were after this too. The patch has been applied in git, it'll be in the next development release.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

This broke Minefield (Firefox trunk builds) and will be broken in Firefox 4 whenever it is finally released.

https://mail1.eff.org/pipermail/https-everywhere/2010-November/000425.html

https://www.requestpolicy.com/dev/ticket/117

Trac:
Username: swalker
Resolution: fixed to N/A
Status: closed to reopened

Okay, we need a new version of this patch which catches the exception in the Firefox 4 case and switches over to the AddonManger API instead:

https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIExtensionManager

In the mean time, I'm going to revert this patch out of master because it's blocking our next release :(

Sorry for the delay; I just noticed the patch was removed in git. I have a problem with this: mainly that the entire AddonManager API is asynchronous. I don't see how to work this into HTTPS Everywhere without major rewrites. A new patch is attached that does not crash, but it doesn't work in Firefox 4 as it does in Firefox 3.

To keep the changes simple, I tried to have it retrieve the path asynchronously earlier in the plugin, and populate a variable with the value to be used once getRuleDir is called. However, no matter where I move that function call in the plugin, the value is only populated after getRuleDir is run (at least on my machine). I don't really know anything about writing Firefox addons (particularly for versions of Firefox that are not released), so I might be missing something obvious, but it seems that AddonManager calls are too slow to return the value in time.

I can try to make up a bigger patch later to properly use the asynchronous calls, but maybe someone else can find an easier way to handle this before then.

Trac:
Username: dm0

QFD. dm0, feel free to use the mailing list or our IRC channel to try and get help writing a fully-working version of this. The other resource that may be of use is #extdev on irc.mozilla.org.

Until we have something that's completely sane in both FF3 and FF4, I'd prefer to stick to the current behaviour but of course in the mean time distros are encouraged apply something like your patch if they'd like to build packages and are sure that their users won't be running FF4. They should probably simultaneously changed src/install.rdf to prevent FF4 installation.

I had a chance to read around the code a bit more, and it wasn't so bad to at least get it working. Although, I think this makes the assumption that the asynchronous call returns before any URL rewriting takes place. (At least the rules wouldn't be loaded until it returns.)

The updated attachment works for me in the latest Firefox stable and today's Minefield.

Trac:
Username: dm0

Trac:
Username: dm0

try-again.patch

This should work now

Trac:
Username: dm0

This patch was committed in git a while ago and is going out with a new stable release shortly.

Trac:
Points: N/A to N/A
Status: reopened to closed
Actualpointsdone: N/A to N/A
Resolution: N/A to fixed
Actualpoints: N/A to N/A
Pointsdone: N/A to N/A

closed

mentioned in issue #5720 (moved)

moved to tpo/applications/https-everywhere-eff#2096 (closed)