reminder: content processes (e10s) are now used by desktop Firefox

[Gavin Sharp]

I've mentioned this at the engineering meeting, but thought it worth a note
here just to ensure everyone is aware:

Bug 870100 enabled use of the background thumbnail service in Firefox
desktop, which uses a <browser remote=true> to do thumbnailing of pages in
the background.

That means that desktop Firefox now makes use of E10S content processes.
They have a short life time (one page load) and are generally triggered by
opening about:newtab when thumbnails are missing or out of date (>2 days
old).

This has exposed some e10s crashes that previously weren't exposed on
desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to
track them - please hang any other such crashes off that bug. If you're
working in a component that has e10s-related crashes, please fix them :)

(Bug 891218 is also planning to make use of content processes for some
Social-related functionality. Those remote processes will be longer-lived,
typically having the same lifetime as the parent process.)

Gavin

[Tom Schuster]

Do we run JS code in these? I can imagine all sorts of things that
would cause a crash if JS code can invoke random dom apis. I however
very happy that we are testing <browser remote=true> in a limited
fashion with this.

Tom

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

[Gavin Sharp]

Yes, JS is enabled in the pages loaded by the background thumbnailing
service (with JS disabled the thumbnails would likely not be very
representative in a lot of cases).

Gavin

[Kyle Huey]

On Tue, Jul 30, 2013 at 5:05 PM, Tom Schuster <t...@schuster.me> wrote:

> Do we run JS code in these? I can imagine all sorts of things that
> would cause a crash if JS code can invoke random dom apis. I however
> very happy that we are testing <browser remote=true> in a limited
> fashion with this.
>
> Tom
>

Most of the content-exposed DOM APIs have to work out of process today for
B2G, so I'm not sure why you'd expect them to crash. There are probably
some fun exceptions like the ancient window.crypto APIs though.

- Kyle

[Robert Kaiser]

Gavin Sharp schrieb:

> This has exposed some e10s crashes that previously weren't exposed on
> desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to
> track them - please hang any other such crashes off that bug. If you're
> working in a component that has e10s-related crashes, please fix them :)

Note that all those crashes I have seen so far are actually crashes of
the browser process, not "just" a content process, i.e. those crashes
take down the whole browser!

KaiRo

[Jeff Gilbert]

Could this be why I'm starting to see banner ads in some of my newtab-page snapshots, despite never seeing them in a tab? I don't appear to see this on an old nightly24 snapshot I have lying around.

-Jeff

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Gavin Sharp]

Seems likely, I recall markh mentioning something similar - adblock
probably doesn't work in the content process.

Gavin

[Nicholas Nethercote]

On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
> Seems likely, I recall markh mentioning something similar - adblock probably
> doesn't work in the content process.

That seems... less than ideal. I don't think creeping down the e10s
path when all the e10s issues haven't yet been resolved is a good
idea.

Nick

[Robert O'Callahan]

On Fri, Aug 2, 2013 at 1:24 PM, Nicholas Nethercote
<n.neth...@gmail.com>wrote:

I thought AdBlock in particular we did have working with e10s. Maybe those
changes haven't landed yet, or maybe it doesn't know about the hidden tabs
where we load sites for thumbnailing.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
*

[Gavin Sharp]

On Thu, Aug 1, 2013 at 6:24 PM, Nicholas Nethercote
<n.neth...@gmail.com>wrote:

Do you have specific issues you're worried about, or are you just speaking
about issues in general?

In general, I don't see us resolving e10s issues until we have some
incentive to do so, and get some sense of their relative severity.

Gavin

[Gavin Sharp]

The experiment you're referring to was Adblock running in Firefox with
remote tabs enabled, I think. I'm not up to date with how that
experiment was progressing, but I think there are some fundamental
differences between that scenario and the background content processes
being used for the background thumbnailing service that might not make
the two cases directly comparable.

It would be valuable for an adblockplus developer to investigate, certainly.

Gavin

[Nicholas Nethercote]

On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
>
> Do you have specific issues you're worried about, or are you just speaking
> about issues in general?

This AdBlock issue worries me specifically. And the fact that there's
breakage with our #1 add-on makes me worry in general.

> In general, I don't see us resolving e10s issues until we have some
> incentive to do so, and get some sense of their relative severity.

Huh? This sentence seems entirely antithetical to our standard
operating procedure. I.e. backing out known regressions, etc.

Nick

[Justin Lebar]

On Thu, Aug 1, 2013 at 6:50 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
>>
>> Do you have specific issues you're worried about, or are you just speaking
>> about issues in general?
>
> This AdBlock issue worries me specifically. And the fact that there's
> breakage with our #1 add-on makes me worry in general.

To be clear, the issue is that thumbnails don't have ABP enabled, not
that ABP falls over in general.

>> In general, I don't see us resolving e10s issues until we have some
>> incentive to do so, and get some sense of their relative severity.
>
> Huh? This sentence seems entirely antithetical to our standard
> operating procedure. I.e. backing out known regressions, etc.

It's a trade-off, right? You can have thumbnails with ABP that jank
the browser, or you can have thumbnails without ABP that don't. (AIUI
the oop business also fixes the issue where thumbnails showed private
data, like bank account info. There are probably other things it
fixes too.)

Showing banner ads in the screencaps doesn't seem like a big deal to
me compared to what we get in return... I guess the biggest issue
from my perspective might be that we're allowing advertisers to track
us, by making HTTP requests we otherwise wouldn't. Hopefully we send
the cookies to /dev/null, but even still they get our IP.

[Gavin Sharp]

On Thu, Aug 1, 2013 at 6:50 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> Huh? This sentence seems entirely antithetical to our standard
> operating procedure. I.e. backing out known regressions, etc.

What "known regression" are you referring to here? Ads on thumbnails?
That seems like a much less serious problem than the one that
background thumbnailing solves (thumbnails missing entirely).
Obviously the crashes and such will need to get fixed, and we won't
ship the feature until we're happy with its overall quality. But the
feedback we're getting from it being enabled on Nightly is invaluable.

Gavin

[Bill McCloskey]

On 08/01/2013 06:50 PM, Nicholas Nethercote wrote:
> On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
>> Do you have specific issues you're worried about, or are you just speaking
>> about issues in general?
> This AdBlock issue worries me specifically. And the fact that there's
> breakage with our #1 add-on makes me worry in general.

Without special support, addons won't see content in the remote
thumbnail processes since they don't have access to the DOM there. We
have been working on making Adblock and other addons work in other
processes, but the code isn't ready to ship.

>> In general, I don't see us resolving e10s issues until we have some
>> incentive to do so, and get some sense of their relative severity.
> Huh? This sentence seems entirely antithetical to our standard
> operating procedure. I.e. backing out known regressions, etc.

As far as I know, the only strict backout policy we have is for
performance regressions on certain commonly accepted benchmarks. It
would be impractical to backout any change that causes a regression in
anything.

I think decisions about the thumbnail code should be made on the merits
of that code alone. Personally I think that the benefits of generating
the thumbnails off the main thread outweigh the loss of ad blocking in
the thumbnails.

-Bill

[tr...@adblockplus.org]

On 02.08.2013 03:35, Gavin Sharp wrote:
> The experiment you're referring to was Adblock running in Firefox with
> remote tabs enabled, I think. I'm not up to date with how that
> experiment was progressing, but I think there are some fundamental
> differences between that scenario and the background content processes
> being used for the background thumbnailing service that might not make
> the two cases directly comparable.
>
> It would be valuable for an adblockplus developer to investigate, certainly.

Unless I missed something, this is about Adblock Plus supporting the original incarnation of Firefox Mobile, the one with two separate processes for chrome and content. This code is long gone in the current Adblock Plus versions - it was a real pain to support due to lots of unavoidable code duplication. The last version still having it is Adblock Plus 1.3.10.

The code in question was explicitly running in Firefox Mobile only. It used messageManager.loadFrameScript() API to inject code into the content process of new tabs - I doubt that it will work the same here, Adblock Plus would probably need to look explicitly for these <browser remote="true"> elements (is there an event when they are created?).

Altogether, supporting this in Adblock Plus should be possible - but it will require significant amounts of additional code and introduce quite a bit of new complexity. I also have doubts whether this is work that should receive priority.

[Marco Bonardo]

On 02/08/2013 03:50, Nicholas Nethercote wrote:
> On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
>>
>> Do you have specific issues you're worried about, or are you just speaking
>> about issues in general?
>
> This AdBlock issue worries me specifically. And the fact that there's
> breakage with our #1 add-on makes me worry in general.

Ads are particularly annoying when you are using a page, in a thumbnail
that effect is quite mitigated or nonexistent. The only problematic
thing seems to be the thumbnail appears different than the page you
commonly see, so you may not recognize it visually.

-m

[Andreas Gal]

We are working on ways to make add-ons like adblock work with e10s on
desktop without major changes to the add-on. That mechanism might work
for the thumbnail case. Gavin can reach out to trev and discuss whether
this is something we should try to make work. I do agree this isn't
super high priority right now though and we can live with this behavior
for thumbnails. Using e10s for this is really cool and greatly improves
responsiveness, after all.

Andreas

[Philip Chee]

On 02/08/2013 16:57, tr...@adblockplus.org wrote:

> The code in question was explicitly running in Firefox Mobile only.
> It used messageManager.loadFrameScript() API to inject code into the
> content process of new tabs - I doubt that it will work the same
> here, Adblock Plus would probably need to look explicitly for these
> <browser remote="true"> elements (is there an event when they are
> created?).
>
> Altogether, supporting this in Adblock Plus should be possible - but
> it will require significant amounts of additional code and introduce
> quite a bit of new complexity. I also have doubts whether this is
> work that should receive priority.

It has just occurred to me that Flashblock would probably be affected
similarly.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Jeff Gilbert]

It's certainly worrying given the number of security- and privacy-related addons people rely on working. Seeing ads in thumbnails is relatively harmless (if disconcerting), but if someone is relying on an addon for important security or privacy reasons, and we auto-updated them and bypassed their protections, that's more serious.

-Jeff

----- Original Message -----

[Asa Dotzler]

On 8/2/2013 1:52 PM, Jeff Gilbert wrote:
> It's certainly worrying given the number of security- and privacy-related addons people rely on working. Seeing ads in thumbnails is relatively harmless (if disconcerting), but if someone is relying on an addon for important security or privacy reasons, and we auto-updated them and bypassed their protections, that's more serious.
>
> -Jeff

I think it's up to add-ons to keep up with Firefox, not the other way
around. We give them no less than 3 months to adjust to our changes. Is
that not enough time?

- A

[Mark Hammond]

On 3/08/2013 5:30 AM, Philip Chee wrote:
> On 02/08/2013 16:57, tr...@adblockplus.org wrote:
>
>> The code in question was explicitly running in Firefox Mobile only.
>> It used messageManager.loadFrameScript() API to inject code into the
>> content process of new tabs - I doubt that it will work the same
>> here, Adblock Plus would probably need to look explicitly for these
>> <browser remote="true"> elements (is there an event when they are
>> created?).
>>
>> Altogether, supporting this in Adblock Plus should be possible - but
>> it will require significant amounts of additional code and introduce
>> quite a bit of new complexity. I also have doubts whether this is
>> work that should receive priority.
>
> It has just occurred to me that Flashblock would probably be affected
> similarly.

We ask the docShell to not allow plugins or media - so no flash should
be seen anyway (which obviously some will consider a bug, but there you
have it)

Cheers,

Mark

[Robert Kaiser]

Mark Hammond schrieb:

> We ask the docShell to not allow plugins or media

So that means that for any page with a video or a big Flash/Java thing
on it, I would get a completely wrong thumbnail? That's unfortunate.

Robert Kaiser

[Justin Lebar]

It's a lot better than the page

a) playing audio,
b) spinning your cpu, or
a) pwning you.

All of which can happen if we run flash/java. :)

Still, if this is a problem (there /are/ a lot of websites which are
just one big flash object), I wonder if we could detect it.

[Brian Smith]

On Wed, Jul 31, 2013 at 1:10 AM, Gavin Sharp <ga...@gavinsharp.com> wrote:

> Bug 870100 enabled use of the background thumbnail service in Firefox
> desktop, which uses a <browser remote=true> to do thumbnailing of pages in
> the background.
>
> That means that desktop Firefox now makes use of E10S content processes.
> They have a short life time (one page load) and are generally triggered by
> opening about:newtab when thumbnails are missing or out of date (>2 days
> old).
>

Besides the crashes, NSPR logging to a file is messed up because all the
processes write to the same log file. See:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging?redirectlocale=en-US&redirectslug=HTTP_Logging#Creating_separate_logs_for_child_processes

I think it is time to make GECKO_SEPARATE_NSPR_LOGS the default.

Cheers,
Brian

[Robert Kaiser]

Justin Lebar schrieb:

> It's a lot better than the page
>
> a) playing audio,
> b) spinning your cpu, or
> a) pwning you.

True.

> Still, if this is a problem (there /are/ a lot of websites which are
> just one big flash object), I wonder if we could detect it.

Yes, I worry about those pages that are one big Flash object, or about
pages which have a video as the centerpiece or such.
We also get worse thumbnails than before on pages that are basically
just a big login screen when you aren't actually logged in.

It's pretty hard to figure out the right thing to do in cases like that,
I guess (esp. on the "well, but private info can't be shown" front).

Robert Kaiser

[Asa Dotzler]

Private info can't be shown is not a hard requirement here -- at least
that's not the position of the Product or Privacy teams.

The issue we're solving for here is over-the-shoulder privacy and we've
used a pretty big hammer that we may want to back off of some.

We should evaluate, possibly through telemetry or FHR, how many users
are seeing the e10s thumbnails and if that number is high, I think we'll
want to change the criteria for when we go to the e10s thumbnails.

- A

[John Schoenick]

Note that until bug 874016 lands it is unsafe to use plugins in content
processes.

[Robert Kaiser]

Asa Dotzler schrieb:

> We should evaluate, possibly through telemetry or FHR, how many users
> are seeing the e10s thumbnails and if that number is high, I think we'll
> want to change the criteria for when we go to the e10s thumbnails.

I saw a bug in a recent triage that said we are (or have been)
overwriting thumbnails created before with less useful background
thumbnails. That might be just a real bug, though. :)

Robert Kaiser

[Mark Hammond]

On 6/08/2013 2:30 AM, Robert Kaiser wrote:
> We also get worse thumbnails than before on pages that are basically
> just a big login screen when you aren't actually logged in.

In the short-term, bug 897880 might help with that - it will arrange so
that an error response (roughly, a non 2XX response) will not cause an
existing thumbnail to be overwritten. Thus, any thumbnails taken while
actually visiting the page (ie, by the "foreground" thumbnail service)
should continue to be used.

We make no attempt to handle sites using purely cookie-based auth (ie,
sites that always return 200 responses, but still render a "please log
in" page based purely on cookies). Also, I mention it may only help in
the short-term as it seems possible we will end up removing the
foreground service completely to avoid jank and keep all thumbnailing
off the main thread/process. However, AFAIK there are no concrete plans
for this.

Cheers,

Mark

[Nicholas Nethercote]

On Tue, Jul 30, 2013 at 4:10 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
>
> Bug 870100 enabled use of the background thumbnail service in Firefox
> desktop, which uses a <browser remote=true> to do thumbnailing of pages in
> the background.
>
> That means that desktop Firefox now makes use of E10S content processes.
> They have a short life time (one page load) and are generally triggered by
> opening about:newtab when thumbnails are missing or out of date (>2 days
> old).

This change triggered
https://bugzilla.mozilla.org/show_bug.cgi?id=903949, for which I just
landed a fix. Chalk it up as another unexpected side-effect of the
introduction of e10s. Thanks to Hugh Nougher for noticing some hangs
in Nightly and profiling them.

Nick

[don.se...@gmail.com]

Dne středa, 31. července 2013 1:10:34 UTC+2 Gavin Sharp napsal(a):

> I've mentioned this at the engineering meeting, but thought it worth a note
>
> here just to ensure everyone is aware:
>
>
>

> Bug 870100 enabled use of the background thumbnail service in Firefox
>
> desktop, which uses a <browser remote=true> to do thumbnailing of pages in
>
> the background.
>
>
>
> That means that desktop Firefox now makes use of E10S content processes.
>
> They have a short life time (one page load) and are generally triggered by
>
> opening about:newtab when thumbnails are missing or out of date (>2 days
>
> old).
>
>
>