[HTTPS-Everywhere] HTTPS Everywhere rewrite in Jetpack?

[Mike Perry]

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 <grobinson at mozilla.com>
> To: dev-tech-electrolysis at lists.mozilla.org
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20131218/b5127902/attachment.sig>