1155149 - [e10s] Remove browser remoteness switching code

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

The browser remoteness switching is a neat hack for now but it comes with so many edge cases that we need to address.

I'd like to have this bug track what work is necessary to get rid of it, e.g. convert about:newtab, about:robots, about:performance, about:serviceworkers etc. including any other work I didn't think about yet.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

Wow, there are so many about: pages that need to be updated. The worst is that the recently added ones (about:serviceworkers, about:performance) are at least non-XUL but still require being loaded in the parent. We should find a way to block the addition of new pages without URI_CAN_LOAD_IN_CHILD.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

(In reply to Tim Taubert [:ttaubert] from comment #1)
> We should
> find a way to block the addition of new pages without URI_CAN_LOAD_IN_CHILD.

I would support such a maneuver.

Comment 3

[Dave Townsend [:mossop]]

I'm not sure this can ever go away given that in the future we will have multiple processes and it is likely we may use something like process-per-origin. This will mean switching between different remote processes for a tab at the least.

That said I'm also not convinced we need to switch all in-tab pages to run remotely in order to stop doing this for now. We need to switch the user-facing pages for sure but still like about:performance we could just always load in its own tab with a disabled url bar.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Dave Townsend [:mossop] from comment #3)
> I'm not sure this can ever go away given that in the future we will have
> multiple processes and it is likely we may use something like
> process-per-origin. This will mean switching between different remote
> processes for a tab at the least.

Right, that didn't occur to me. I'm also not super sure it's actually possible (time/resource-wise) to convert all existing internal pages to load remotely. I wonder if we could a little more platform-support for this maybe? Without of course just moving the hack to the Core, but maybe it would be possible to allow privileged code for those pages in the child? Or use CPOWs somehow as they're probably not perf-critical anyway?

> That said I'm also not convinced we need to switch all in-tab pages to run
> remotely in order to stop doing this for now. We need to switch the
> user-facing pages for sure but still like about:performance we could just
> always load in its own tab with a disabled url bar.

Good point, yeah.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Tim Taubert [:ttaubert] from comment #4)
> (In reply to Dave Townsend [:mossop] from comment #3)
> > I'm not sure this can ever go away given that in the future we will have
> > multiple processes and it is likely we may use something like
> > process-per-origin. This will mean switching between different remote
> > processes for a tab at the least.
> 
> Right, that didn't occur to me. I'm also not super sure it's actually
> possible (time/resource-wise) to convert all existing internal pages to load
> remotely. I wonder if we could a little more platform-support for this
> maybe? Without of course just moving the hack to the Core, but maybe it
> would be possible to allow privileged code for those pages in the child? Or
> use CPOWs somehow as they're probably not perf-critical anyway?

I think we can totally have better support in docshell etc. for remote switching. But when I implemented most of the current hacks that seemed harder than the simple fixes. I'd hope as we get multiple remote processes we'll improve things.

Allowing privileged code is easy enough I think, but the largest problem for these pages is likely XPCOM access and CPOWs can't be passed to XPCOM methods. Seems like that could potentially be fixable. The other problem is that we don't have XUL in the child process so that would force a bunch of changes regardless. That's actually probably the largest blocker to something like about:addons and about:preferences where the API needs are pretty well contained but the UI is massive and all XUL based :(

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

Alright, let's wontfix this - at least for now. There are a ton of pages that don't support e10s but this probably won't change anytime soon. I think we will have to support seamless switching between remote and non-remote browsers for the time being if we ever want to ship e10s.