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: ​https://bugzilla.mozilla.org/show_bug.cgi?id=629820

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.

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 irc.mozilla.org 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.

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

It also looks as though Giorgio is committed to continuing down the Mozilla rabbit hole to support the Firefox mobile multiprocess model: ​http://noscript.net/nsa/

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

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.

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.