1717050 - browser_net_initiator.js fails with server side target switching enabled

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect)

Description

[Alexandre Poirot [:ochameau]]

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

Fails to open the stack trace for the 4th request, xhr_request:
https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/test/browser_net_initiator.js#44-50
The test times out on:
https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/test/browser_net_initiator.js#180-184

    // Clicking on the initiator column should open the Stack Trace panel
    const onStackTraceRendered = waitUntil(() =>
      document.querySelector("#stack-trace-panel .stack-trace .frame-link")
    );
    await onStackTraceRendered;

because we happen to receive the NETWORK_EVENT resource before the STACKTRACE one.

That's an issue because networkEvent.cause.stacktraceAvailable isn't set to true, as we expect the order to always be consistent over here:
https://searchfox.org/mozilla-central/rev/b172dd415c475e8b2899560e6005b3a953bead2a/devtools/client/netmonitor/src/connector/firefox-data-provider.js#334-337
Ultimately, the stacktrace panel is kept hidden because of this code:
https://searchfox.org/mozilla-central/rev/b172dd415c475e8b2899560e6005b3a953bead2a/devtools/client/netmonitor/src/components/TabboxPanel.js#220

We should either try to ensure that the server always emit STACKTRACE before NETWORK_EVENT -or- accomodate to the two order in the frontend.

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@bomsy: It is possible that devtools/client/netmonitor/test/browser_net_cause_source_map.js fails from the same reason? (i.e. different order of resources of various types due to batching)

Here is a list of tests that are failing on timeout since waiting for payloadReady that never happens.
Perhaps there could be common underlying issue

• devtools/client/netmonitor/test/browser_net_cause_source_map.js (passes with devtools.target-switching.server.enabled=true + patch from bug 1713607)
• devtools/client/netmonitor/test/browser_net_initiator.js (this report, passes with devtools.target-switching.server.enabled=true + patch from bug 1713607)
• devtools/client/netmonitor/test/browser_net_websocket_stacks.js
• devtools/client/netmonitor/test/browser_net_worker_stacks.js

Honza

Comment 2

[Hubert Boma Manilla (:bomsy)]

Thanks Honza.

@bomsy: It is possible that devtools/client/netmonitor/test/browser_net_cause_source_map.js fails from the same reason? (i.e. different order of resources of various types due to batching)

Yes it looks like the same issue.

Here is a list of tests that are failing on timeout since waiting for payloadReady that never happens.
Perhaps there could be common underlying issue

• devtools/client/netmonitor/test/browser_net_cause_source_map.js (passes with devtools.target-switching.server.enabled=true + patch from bug 1713607)
• devtools/client/netmonitor/test/browser_net_initiator.js (this report, passes with devtools.target-switching.server.enabled=true + patch from bug 1713607)

Interestingly these do not pass consistently for me with the patches from bug 1713607. I ran the tests multiple times, it passes most of the time but still fails some of the time. It seems like the regularity for the failures have reduced, but still has some issues.

Did you run the tests more that once? I wonder if the intermittent failures is just me.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Hubert Boma Manilla (:bomsy) from comment #2)

Did you run the tests more that once? I wonder if the intermittent failures is just me.

You are right, I just tried to run both tests with:
$ mach <test-path> --verify --headless --enable-fission --setpref devtools.target-switching.server.enabled=true

• patches from bug 1713607 included

and I am seeing some test failures (Win10)

Comment 4

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1717050 - Network events and network stacktrace events no longer depend on their orders r=nchevobbe

Previously, we worked with the assumption the NETWORK_STACKTRACE_EVENT resources will always
come before NETWORK_EVENT resources. Even though that's the order they are sent on the backend.
There is no gurantee when it comes through the resource watcher api, this becomes obvious with
server side target-switching on. Ideally there should not be dependency on the order. This patch
fixes that and fixes these 2 tests browser_net_initiator.js and browser_net_cause_source_map.js.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1717050#c0 and https://bugzilla.mozilla.org/show_bug.cgi?id=1717050#c3
for exact commands to run the tests

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ade59042d740
Network events and network stacktrace events no longer depend on their orders r=nchevobbe

Comment 6

[Natalia Csoregi [:nataliaCs]]

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