Yan Zhu: > Hi Mike, Hey Yan, > What do you think of rewriting HTTPS Everywhere with Jetpack, assuming > you're not the one doing it? The Electrolysis dev folks at Mozilla > think that it'd be a good idea for future e10-compatibility. > > I think I'd be willing to do this just because it would get rid of XUL > and potentially be the easiest path towards Fennec-compatibility, but > let me know if this is a poor life decision.
Unfortunately, I can't say if this is a good idea point blank, but I can give you some things you'll want to consider and investigate before you commit too deeply to your new Jetpack lifestyle ;). In terms of specific issues with HTTPS-Everywhere, the first thing to check is that you get access to the "http-on-modify-request" observer, and that you can use the "redirectTo" API call on the nsIHttpChannel (should be the subject of the observer). With that, the core functionality should be doable. After that, the next most likely thing to break is the context menu in the toolbar (called the "ApplicableList" in the code, and written by Peter IIRC) from the context of this "http-on-modify-request" observer. In a fully e10s-locked mode, you may have difficulty updating that UI from the same e10s process that handles the http-on-modify-request observer redirection. If JetPack somehow enforces this already, things might get tricky. Or maybe Mozilla has provided JetPack APIs for this exact case, and it will actually be easier in the long run to use their mechanism. The risk for TBB here is if Jetpack suddenly starts depending on features only available in the Rapid Releases, and those features are not backported to the ESR series, then we risk losing HTTPS-Everywhere in TBB with this move. Most likely we'll be able to simply avoid using the very shiniest new Jetpack APIs that rely on Rapid Release, but if the underlying implementation of "stable" Jetpack APIs change in some key way, we could end up needing to ship two versions of the addon, packaged with different Jetpack versions. The best way to determine this is probably to see how well supported Firefox 17ESR was by Jetpack and Jetpack addons. Based on this random forum post, it sounds like the ESR series are not carefully tested with newer Jetpack releases, and we may in fact end up needing to use multiple versions of Jetpack to support TBB and other ESR users: https://forums.mozilla.org/addons/viewtopic.php?f=27&t=15007 We should probably ask people we know at Mozilla to make sure this sort of thing won't happen in the future. Longer term (wrt the e10s switchover), I am also worried about this talk of eliminating extension access to arbitrary XPCOM components. One of the things that makes Firefox a good target for prototyping crazy shit is the flexibility afforded by the fact that most things are scriptable by default. > - -------- Original Message -------- > Subject: Re: port HTTPS Everywhere to Electrolysis > Date: Wed, 18 Dec 2013 15:37:52 -0800 > From: Garrett Robinson <[email protected]> > To: [email protected] > > On 12/18/2013 03:24 PM, Yan Zhu wrote: > > Can you folks at Mozilla provide any guidance on this? Would you > > recommend porting the entire extension to Jetpack in the process? > > We can definitely provide guidance on this process. Getting addons to > work in e10s is an ongoing project, but we definitely want popular > extensions like HTTPS Everywhere to work before we turn e10s on by > default. There is currently work being done to get the Top 10 addons > on addons.mozilla.org (Ad Block Plus, DownThemAll, etc.) working with > e10s. > > If porting the entire thing to Jetpack is something you're > considering, it would be a good idea in the context of e10s. AIUI, one > of the goals is to get Jetpack to be e10s-safe so we can limit current > and future extensions use of components that are not e10s safe, or > cannot be without specialized workarounds for each component. > > - -Garrett -- Mike Perry
signature.asc
Description: Digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
