[HTTPS-Everywhere] HTTPS Everywhere rewrite in Jetpack?

[Yan Zhu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 12/18/2013 11:19 PM, Mike Perry wrote:
> 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.
> 

Yep, this is possible. For now, any XPCOM component is accessible in
Jetpack.

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

This is going to be the tricky part in full e10's mode AFAICT. The
http-on-modify-request observer runs in the parent, so the core
functionality of HTTPS Everywhere is easily doable. But we have to get
information from the child in order to update the chrome, which only
the parent can do. Right now there's no API for doing this directly,
so we have to register a web progress listeners in each child and pass
messages to the parent in these objects called CPOWs [1] using the
message manager [2]

[1] https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers
[2] https://developer.mozilla.org/en-US/docs/The_message_manager

FWIW, Mozilla folks also seem to be thinking of a sane and consistent
way to do this message-passing in the future since they need it for
the mixed content blocker UI.


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

I agree that this would suck.

Jetpack doesn't automatically guarantee e10's compatibility because
you can use arbitrary XPCOM components right now, but the shiny new
API's that it advertises are supposedly the ones that will be
future-e10s compatible. If we were to port to Jetpack now, we'd have
to keep depending heavily on XPCOM for all the backend work of HTTPS
Everywhere; the main immediate benefits would be a UI that is no
longer XUL and the opportunity to clean up the code.

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

They were pretty helpful for me and seemed really interested in not
causing all extensions to break, but this sounds like something we
should bug them about!

- -Yan

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

- -- 
Yan Zhu                           yan at eff.org
Technologist                      Tel  +1 415 436 9333 x134
Electronic Frontier Foundation    Fax  +1 415 436 9993
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJStev+AAoJENC7YDZD/dnsJ1gH/RZWq9D45cEsH/EW9HyHmEyt
p6IUE4rGSy9pprCjrDVu/nDF3qFW7Qu/kPrB70eSrMT/d0/1UF8fL25eiHK6F1ag
XuBiKCiUzQxuRwfiJz04HBGnYxKKZLe4+g2LToPZNsWHs5gqn6/Jc4dsJmRq064p
/TQllawZ+ycpi+o5SOU2r+ZD6MuQF5EDfboDvYywtWdow4tiIBVR3mw4Co00j+6i
R+OBvtqmi5ZxCbRMr2m1MFbL9MfeyCQ46OTe/1enu0iMjbvXLMlfC3XV0uOJHXzq
AkwXCSzXTWbQP5jfaHHTqYbRSrmtaxXPEUWO6WXkCkk8jQWZq8EI7sdUW3vSv8k=
=9/h1
-----END PGP SIGNATURE-----