Opened 10 years ago

Closed 10 years ago

#2096 closed defect (fixed)

Global Install Option

Reported by: dm0 Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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.)

Child Tickets

Attachments (3)

mozilla-https-everywhere-global-rules.patch (1.1 KB) - added by dm0 10 years ago.
Patch to use addon install location
mozilla-https-everywhere.spec (1.5 KB) - added by dm0 10 years ago.
RPM spec to test installing the addon globally
try-again.patch (2.8 KB) - added by dm0 10 years ago.
This should work now

Download all attachments as: .zip

Change History (12)

Changed 10 years ago by dm0

Patch to use addon install location

Changed 10 years ago by dm0

RPM spec to test installing the addon globally

comment:1 Changed 10 years ago by pde

Status: newaccepted

comment:2 Changed 10 years ago by pde

Status: acceptedneeds_review

comment:3 Changed 10 years ago by pde

Resolution: fixed
Status: needs_reviewclosed

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

comment:4 Changed 10 years ago by swalker

Resolution: fixed
Status: closedreopened

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

comment:5 Changed 10 years ago by pde

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:

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

comment:6 Changed 10 years ago by dm0

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.

comment:7 Changed 10 years ago by pde

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

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.

comment:8 Changed 10 years ago by dm0

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.

Changed 10 years ago by dm0

Attachment: try-again.patch added

This should work now

comment:9 Changed 10 years ago by pde

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.