516746 - Electrolysis: unified session history for multiple content processes

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Benjamin Smedberg]

Implement session history for multiple processes. This is not simply "forward session history from content to chrome", because session history may span multiple content processes and, if you're navigation to certain about: pages, chrome may render some of the entries itself.

Also related (but may be a different bug): navigation in the content process should be approved by the chrome process, because it may wish to redirect navigation to another process if its in a different domain.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Are we going to have multiple content processes for Fennec?
I thought the idea was to have just one, or at least just one per tab for now.

Comment 2

[Benjamin Smedberg]

There are two issues here:

Even if we have a single content process, the user may choose to navigate to about:config or other privileged pages. These pages will only work in the chrome process.

dougt has said that we could solve that problem by simply requiring the user to open those pages in a new dedicated tab or something.

The other larger problem is when we want to end up with process-per-domain. But we do not need to (and shouldn't) fix that problem now.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> There are two issues here:
> 
> Even if we have a single content process, the user may choose to navigate to
> about:config or other privileged pages. These pages will only work in the
> chrome process.
Right. If we want the same frameloader to hold chrome and content pages (depending on the state), we'd need quite some changes to frameloader.


> dougt has said that we could solve that problem by simply requiring the user to
> open those pages in a new dedicated tab or something.
Sounds reasonable. Fennec/FF UI could automatically open a new tab if 
user tries to open about:config or something similar.


> The other larger problem is when we want to end up with process-per-domain. But
> we do not need to (and shouldn't) fix that problem now.
And when implementing SHistory for that, we should try to avoid the
rather big performance problems Chrome has (or at least has had)
with session history.

Comment 4

[Benjamin Smedberg]

So do you want to use this bug for the minimal Fennec work, or open a different one?

I don't know anything about the Chrome performance issues, I'd like more details if you've got them.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Well, I'm not familiar with Fennec code, so I hope someone from Fennec team
will handle this in their code. But that sounds like a different bug, and
this could be the bug for E10s session history.

FYI, back-forward at least used to be significantly slower in Chrome than in
other browsers. I don't know any details about it, but I guess switching
processes take a bit time.

Comment 6

[Doug Turner (:dougt)]

For the fennec 2.0 product, we are okay having to detect about: pages and "do something special with them".  Right now, we are not exactly sure about this workaround should be (but have some general ideas).  Input appreciated.

I think this bug is for fixing the problem for realz.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Yeah. This bug can't be really fixed before we have multiple client processes and frameloader can handle that.

For Fennec something a lot simpler could be done, and it doesn't need to have
anything to do with session history.

Comment 8

[Doug Turner (:dougt)]

bug 561207 will track the fennec work-around until this is fixed.

Comment 9

[Doug Turner (:dougt)]

no longer blocking 516521.