1519088 - [remote-dbg-next] Blank page when navigating from Connected Runtime to This Firefox

Status: VERIFIED FIXED

(DevTools :: about:debugging, enhancement, P1)

Description

[Julian Descottes [:jdescottes]]

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?

Comment 1

[Julian Descottes [:jdescottes]]

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.

Comment 2

[Julian Descottes [:jdescottes]]

Attachment: Bug 1519088 - Add dedicated action to update selected runtime id;r=ladybenko

If we update the selected runtime id in a single spot, we no longer have
intermediary states with no selected runtime, which was breaking the service worker
action component.

Comment 3

[Julian Descottes [:jdescottes]]

Attachment: Bug 1519088 - Remove selected runtime id from UI state;r=ladybenko

Depends on D16473

The information about the selected runtime id is duplicated between the UI state and 
the runtimes state. I have another stack of patches that takes the other approach, keeping
this state only in the UI state. I don't have a strong opinion on which one is the best.
The other stack is a bit more complicated (more refactor around runtimes-state-helper which
has to read the selected runtime id from the ui state now), so I am proposing this one for 
now. Let me know if you'd prefer to see the other.

Comment 4

[Julian Descottes [:jdescottes]]

Attachment: Bug 1519088 - Test navigation from remote runtime to this-firefox with service workers;r=ladybenko

Depends on D16474

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a9582642ea71
Add dedicated action to update selected runtime id;r=ladybenko
https://hg.mozilla.org/integration/autoland/rev/91911f0e1e35
Remove selected runtime id from UI state;r=ladybenko
https://hg.mozilla.org/integration/autoland/rev/d0529e2d98a3
Test navigation from remote runtime to this-firefox with service workers;r=ladybenko

Comment 6

[Arthur Iakab [arthur_iakab]]

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

[Hani Yacoub, Desktop QA]

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.