1327995 - [e10s] devtools reload and loose all progress if I navigate between pages that load in different processes

Status: NEW

(DevTools :: General, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 53, 32bit, ID 20161129171714 (2016-11-29)
STR_1:
1. Save page https://www.mozilla.org/en-US/firefox/nightly/firstrun/
2. Open devtools -> options, enable "Enable persistent logs"
3. Open devtools -> console, enable all filtering
4. Open page saved in Step 1 in current tab

AR:  logs are lost
ER:  logs should persist

This is a regression. Nightly 2016-05-26 is unaffected, Nightly 2016-11-29 is affected.

Comment 1

[Justin [:JW_SoftvisionQA]]

After running a quick regression on this it seems that this bug is being blocked by 1147911. 

Bob I see you worked on 1147911. Is there any information on this that would be useful?

23:07.95 INFO: Last good revision: 49228a69b071bc200360aa43845b42b996759479
23:07.95 INFO: First bad revision: 0637dd270ef14763921d3099b6f6d5780fa702f6
23:07.95 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=49228a
69b071bc200360aa43845b42b996759479&tochange=0637dd270ef14763921d3099b6f6d5780fa7
02f6

23:08.24 INFO: Looks like the following bug has the changes which introduced the
 regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1147911

Comment 2

[:Gijs (he/him)]

The same thing happens if you e.g.:

1. load about:newtab (ie open new tab)
2. open devtools
3. eval "console.log('hi');"
4. load any webpage in that tab

This is because about:newtab loads in the parent process, and the web page will load in a child process.

The separate file content process only made this happen when files are involved, but the original issue is older. I expect it's probably filed somewhere already.

Comment 3

[Brian Grinstead [:bgrins]]

It used to be that the toolbox got closed and didn't get opened again when switching from parent to child.  This was improved by Bug 1068400 where now the toolbox will at least reopen.  But because it closes, state in the devtools UI gets lost: https://bugzilla.mozilla.org/show_bug.cgi?id=1068400#c70.

Unless if there's another bug on file for this, we can use this issue to explore options for more seamlessly switching processes without closing the toolbox (or somehow restoring toolbox state when reopening).  I guess this is something that will start happening more as multiple content processes get introduced.  Alex, any ideas?

Comment 4

[Alexandre Poirot [:ochameau]]

(In reply to Brian Grinstead [:bgrins] from comment #3)
> Unless if there's another bug on file for this, we can use this issue to
> explore options for more seamlessly switching processes without closing the
> toolbox

I sounds like the right thing to do, but also looks like a nightmare to implement.
I don't have any easy way to implement that. We pass the target object everywhere and is not meant to be swapable.

> (or somehow restoring toolbox state when reopening).

Sounds more feasible... but definitely less perfect UX. Especially given how slow our tools are to startup.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I agree with Alex that restoring the toolbox state would be quite complex, to put it mildly...  

When changing processes, there's state in the actors on the server side, and if toolbox UI is going to reload, then there's state in each open tool.  All of this would need to be restored somehow.  For modern tools that use Redux and single app state object, it seems _possible_, but still probably tricky.

Perhaps there's a magic solution that avoids that complexity, I'll keep thinking about it...

Moving to DevTools, since it seems we want this to track the general problem, not the Console specific symptom.

Comment 6

[Patrick Brosset <:pbro>]

Moving this inactive P2 to the backlog (P3)