Port to Firefox Mobile (Fennec+Electrolysis)
Both Torbutton and HTTPSEverywhere are going to have some fun times dealing with something the Fennec people call 'Electrolysis': https://bugzilla.mozilla.org/show_bug.cgi?id=629820
It prevents components and observers from getting events originating in different tabs. You must register your observers in each process manually: https://wiki.mozilla.org/Mobile/Fennec/Extensions/Electrolysis
I've decided to port HTTPSEverywhere to Fennec first because it will be easier and more straight-forward to doing Torbutton.
Activity
Trac:
Username: dietrich
Cc: N/A to autonome@gmail.com
Re comments in #2784 (moved): 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.
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://gitweb.torproject.org/mikeperry/https-everywhere.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).
-
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.
Trac:
Username: dietrich -
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 irc.oftc.net.
-
Ok, I got some info from #mobile on irc.mozilla.org. 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: https://hg.adblockplus.org/adblockplus/file/7d47f4083064/modules/ContentPolicyRemote.jsm https://hg.adblockplus.org/adblockplus/file/7d47f4083064/modules/Utils.jsm https://hg.adblockplus.org/adblockplus/file/7d47f4083064/chrome/content/fennecContent.js
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).
Trac:
Parent: #1506 (closed) to #5709 (moved)Also https://mail1.eff.org/pipermail/https-everywhere/2012-August/001503.html
(mailman's threading is pretty broken if a thread crosses a month-boundary)
Trac:
Cc: autonome@gmail.com to autonome@gmail.com, strangecharm-
Trac:
Username: swrobel
Cc: autonome@gmail.com, strangecharm to autonome@gmail.com, strangecharm, swrobel 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.
Trac:
Cc: autonome@gmail.com, strangecharm, swrobel to zyan, autonome@gmail.com, strangecharm, swrobelOk, 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.
-Yan
mentioned in issue #2513 (closed)
mentioned in issue #2784 (moved)
mentioned in issue #8763 (moved)