1721384 - browser_net_websocket_stacks.js fails with server side target switching enabled

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect)

Description

[Alexandre Poirot [:ochameau]]

./mach mochitest --headless devtools/client/netmonitor/test/browser_net_websocket_stacks.js --setpref devtools.target-switching.server.enabled=true

This test fail because we try to fetch the stack trace for the first navigation request.
And we try to do that late, after the navigation is completed.
The previous target we navigate from has been destroyed and we can't communicate with the previous network content actor and so can't fetch the stack trace.

The test is stuck on this line:
https://searchfox.org/mozilla-central/rev/79a3ae0b0fa6abeca2cb7cf220df293c8dec9207/devtools/client/netmonitor/test/browser_net_websocket_stacks.js#89
Because the following RDP request call will be stuck:
https://searchfox.org/mozilla-central/rev/79a3ae0b0fa6abeca2cb7cf220df293c8dec9207/devtools/client/netmonitor/src/connector/firefox-data-provider.js#313-315
(surprinsingly it seems to not be rejected it just never resolves?)
You will notice that for the first request, actor.targetFront will be different from any other request and will be the previous target, which is already destroyed.

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1721384 - [devtools] Fix browser_net_websocket_stacks.js with server side targets.

Comment 2

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1721384 - [devtools] Fix browser_net_websocket_stacks.js with server side targets

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acf8c90ef510
[devtools] Fix browser_net_websocket_stacks.js with server side targets r=jdescottes

Comment 4

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/acf8c90ef510