[remote-dbg-next] Blank page when navigating from Connected Runtime to This Firefox
Categories
(DevTools :: about:debugging, enhancement, P1)
Tracking
(firefox66 verified, firefox67 verified, firefox68 verified)
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
STRs:
- connect to a remote runtime that supports service workers (network locations only at the moment)
- open the runtime page for this remote runtime
- register a service worker on the remote runtime (go to https://serviceworke.rs/strategy-network-or-cache_demo.html for instance)
- check that the service worker appears in about:debugging
- click on This Firefox
ER: We should navigate to This Firefox
AR: Blank page, need to reload about:debugging
ServiceWorkerAction component assumes that runtimeDetails is always available. However, if we are navigating to another Runtime page (eg This Firefox), the component will be rendered in a state where there is no runtime currently connected.
Currently investigating. Might be related to the fact that ServiceWorkerAction reads this information from mapStateToProps?
Assignee | ||
Comment 1•6 years ago
|
||
I think I tracked down what happens:
(assuming the initial state is: runtime page for a remote runtime)
- clicking on This Firefox renders the Runtime Page route
- we start rendering all the components for the Runtime Page route (at that point they are still showing the information for the remote runtime)
- on componentWillMount of the RuntimePage component, we dispatch the selectPage action
- in the selectPage action, we first unwatch the remote runtime.
- the reducer for unwatch runtime sets selectedRuntimeId to null in the runtimes state, so all the methods from runtimes-state-helper will no longer be able to find the current runtime info
- however we are still displaying the old debug targets from the remote runtime, and the service worker one crashes because it can't find the currently selected runtime
Part of the issue here is that we are duplicating the selected runtime id information. It's both in the runtimes state and in the UI state. If the UI state was the source of truth for the selected runtime id, then this scenario would work fine.
However I wonder if we can't get into similar scenarios if we lose the connection to the remote runtime. It might be overall safer to consider runtimeDetails as potentially null in the serviceWorkerAction component.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Assignee | ||
Comment 4•6 years ago
|
||
Comment 6•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a9582642ea71
https://hg.mozilla.org/mozilla-central/rev/91911f0e1e35
https://hg.mozilla.org/mozilla-central/rev/d0529e2d98a3
Comment 7•6 years ago
|
||
Verified as fixed on Firefox Nightly 68.0a1, Firefox Dev Edition 67.0b4 and on Firefox 66.0.1 on Windows 10 x 64, Mac OS X 10.14 and on Ubuntu 16.04 x64.
Description
•