Opened 5 years ago

Closed 20 months ago

#2471 closed enhancement (fixed)

Port to Firefox Mobile (Fennec+Electrolysis)

Reported by: mikeperry Owned by: mikeperry
Priority: normal Milestone:
Component: EFF-HTTPS Everywhere Version:
Keywords: Cc: zyan, autonome@…, strangecharm, swrobel
Actual Points: Parent ID: #5709
Points: 6 Sponsor:


Both Torbutton and HTTPSEverywhere are going to have some fun times dealing with something the Fennec people call 'Electrolysis':

It prevents components and observers from getting events originating in different tabs. You must register your observers in *each* process manually:

I've decided to port HTTPSEverywhere to Fennec first because it will be easier and more straight-forward to doing Torbutton.

Child Tickets

Change History (21)

comment:1 Changed 5 years ago by mikeperry

  • Points set to 6

Review Electrolysis docs and despair: 1
Implement multiprocess content policy: 2 or 5

Implementation is 5 points if it ends up being the case that we cannot share or easily mirror our data structures in each process.

comment:2 Changed 5 years ago by mikeperry

  • pointsdone set to 1

comment:3 Changed 5 years ago by mikeperry

  • actualpointsdone set to 1

comment:4 Changed 5 years ago by dietrich

  • Cc autonome@… added

comment:5 Changed 5 years ago by mikeperry

Re comments in #2784: the multiprocess stuff does not make this port as trivial as it could be. We actually have quite a few observers that need to listen and redirect based on a very lare amount of global state (the rule tables). Right now, we're waiting for some better plumbing to register global observers such as the content policy, and/or suggestions on how to do RPC efficiently. See:

I get the distinct feeling this Electrolysis stuff is not really well thought out, because nobody seems to be paying any attention to these issues at Mozila. It seems weird to me that it would be advisable for Mozilla to break addon compatibility so badly for the Mobile Firefox for this stuff.. I don't get why multiprocess Firefox is even a benefit on a platform like Android. The Android memory reaper is constantly killing it whenever it gets backgrounded anyways, because the tab-per-process model also takes a lot of RAM. So it is not like there's a huge win for stability on the platform. It actually seems to make it less stable due to the memory reaper.

At any rate, my current plan is to ignore the issue until someone from Firefox actually wakes up and realizes that the model doesn't make sense. Or at least improves the RPC and observer registration to be slightly less insane.

If anyone wants to take this up, you can get an .xpi that installs in FF mobile using the firefox-mobile in my git: git://

It installs, but does not work properly because the observers only get added to the main process.

It is rebased to the latest origin/master from yesterday (8471a2ffb11a).

comment:6 Changed 5 years ago by dietrich

Wow, and I thought we weren't super welcoming to new contributors to Firefox!

I think it's crazy that you think nobody is thinking about this at Mozilla. Ask about the out-of-process stuff in #mobile on if you actually want to know why. Hint: It's not a bunch of people who hate add-on developers and thought it'd be great fun to put content in a separate process for no reason ;)

Anyways, I'd like to have a positive experience helping out here. I might have some time available over the next couple of weeks, will see what I can do.

comment:7 Changed 5 years ago by mikeperry

I'm not trying to be unwelcoming here. I pointed you at my latest efforts and told you what the blockers were. It's just that one of the blockers hits a nerve for me wrt Firefox addon development.

I've been doing Firefox addon development for way too long: forgive me if it's left me cynical, alienated, and bitter. It's nothing against you. I hope you understand :).

If you like, pde and I can answer any questions you have about the codebase in #https-everywhere on

comment:8 Changed 5 years ago by mikeperry

Ok, I got some info from #mobile on mfinkle said that we should definitely only register the http-* observers in the parent process, as those are fired for every element load.

fabrice said that AdBlockPlus registers a content policy for each child process and implements a cache to avoid performing the message passing RTT for every element:

He did not know why ABP still registers http-on-modify-request as well as onChannelRedirect in the remote children. It has something to do with properly tracking channels according to the comments. Not sure if it is required because onChannelRedirect is not fired to children, or if it is merely a scoping convenience thing..

Sounds like a real proper mess that the ABP people managed to untangle enough for it to function, but it still doesn't sound very sane, robust, or efficient...

comment:9 Changed 4 years ago by mikeperry

It also looks as though Giorgio is committed to continuing down the Mozilla rabbit hole to support the Firefox mobile multiprocess model:

If he ports the IOUtil and redirect mechanisms we use to this model, we may be able to merge them back in to HTTPS-Everywhere and get support for mobile that way. Sadly, it looks like the HTTPS support is not currently on his roadmap though (unless it is part of the ABE machinery).

comment:10 Changed 3 years ago by arma

  • Parent ID changed from #1506 to #5709

comment:12 Changed 3 years ago by pde


(mailman's threading is pretty broken if a thread crosses a month-boundary)

comment:13 Changed 3 years ago by StrangeCharm

  • Cc strangecharm added

comment:14 Changed 2 years ago by pde

  • Summary changed from Port HTTPSEverywhere to Fennec+Electrolysis to Port to Firefox Mobile (Fennec+Electrolysis)

Updating the title of this bug so that everyone can find it properly :)

comment:15 Changed 2 years ago by swrobel

What's the latest on this?

comment:16 Changed 2 years ago by swrobel

  • Cc swrobel added

comment:17 Changed 22 months ago by cypherpunks

Any updates on this?

comment:18 Changed 22 months ago by pde

  • Cc zyan added

Great question! Since we now have the channel.redirectTo API, this should in theory be something that we can just go and do (ie, it should simply be a matter of making the UI). There are footnotes about making sure you're running in the right E10s thread, but the parent should be able to do this.

Probably the first test is for someone to run a simple test extension in Firefox for Android to see that the redirectTo API is actually working there. One could do that by (a) writing a minimal extension that uses it for some specific purpose or (b) by cherry picking this commit into the current git master and then working through all of the UI crashes that I'm guessing probably prevent HTTPS Everywhere from running there.

comment:19 Changed 22 months ago by zyan

Ha, Mozilla just told me that Fennec doesn't use e10's anymore. So this might just work. I asked them to try installing HTTPS Everywhere to see if it works because I'm lazy.

comment:20 Changed 22 months ago by zyan

Ok, I quickly tried installing HTTPS Everywhere stable with the new install.rdf in Android Firefox. It successfully redirected URLs but also apparently prevented pages from loading (even pages without rulesets). Will investigate more once I set up the Android SDK.

rumor has it that this android firefox thing doesn't use XUL.


comment:21 Changed 20 months ago by zyan

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

Declaring victory on this since I just released the FF for Android version.

We might have to open a new ticket for Fennec if it ever gets released (Fennec != Firefox for Android).

Note: See TracTickets for help on using tickets.