Open Bug 1327995 Opened 3 years ago Updated Last year
[e10s] devtools reload and loose all progress if I navigate between pages that load in different processes
>>> 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.
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
No longer blocks: 1147911
Status: UNCONFIRMED → NEW
Depends on: 1147911
Ever confirmed: true
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.
No longer depends on: 1147911
Summary: Devtools reload and loose all progress if I navigate from web page to local page (file:// URLs) or vice versa → [e10s] devtools reload and loose all progress if I navigate between pages that load in different processes
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?
(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.
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.
Component: Developer Tools: Console → Developer Tools
Priority: -- → P2
Moving this inactive P2 to the backlog (P3)
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.