1621751 - DevTools network tab confuses requests

Status: RESOLVED DUPLICATE of bug 1628162

(DevTools :: Netmonitor, defect)

Description

[Denis Lisov]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

1. Open https://example.org
2. Open Developer Tools, Network tab
3. Refresh page with F5 and select the first request (may need to repeat this step several times until the bug reproduces)

I've seen this bug on both Nightly 2020-03-09 I'm currently running and Firefox 68 (via mozregression), so this does not look like a regression.

Actual results:

Sometimes the requests get mixed up:

• the GET / shows status 404,
• the GET /favicon.ico shows no status,
• when I try to select the first request, both lines are selected.
  I've checked the browser toolbox and the immediate reason is likely that both lines have the same data-id attribute (for example, both have data-id="server0.conn26.netEvent618").

Expected results:

The network pane is expected to show two "normal" requests:
GET / with normal status (normally either 200 or 304)
GET /favicon.ico with status 404 (this site has none)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[:Harald Kirschner :digitarald]

Bomsy, any idea what's going on here? I tried reproducing it without luck.

Comment 3

[Hubert Boma Manilla (:bomsy)]

Attachment: Screenshot 2020-03-20 at 00.20.16.png

After a couple of refreshes what i've been able to repro is that i see one request which does not have a status. As shown in the screenshot.

I'll dig in a little bit more to check what is going on.
it happens intermittently.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

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

Attachment: image.png

Dennis, I am only seeing one request when loading https://example.org/, no status at all, the page just fails to load. Can you still reproduce the problem?

Honza

Comment 6

[Denis Lisov]

I've got no idea why you cannot load https://example.org as it's a standard example domain and works for me. Still, the weird part is that I've tried to reproduce the problem and failed, including the versions that used to reproduce it in the original report. In both cases there were launched via mozregression, so I don't understand what could make the difference (system updates? some nonstandard network configuration? something else?..).

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

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

Hubert, were you able to load the https://example.org ?

Honza

Comment 9

[Hubert Boma Manilla (:bomsy)]

Yes it loaded for me

Comment 10

[chaephahw0kai2kaugh4]

Here is how this issue looks with much more requests: https://megous.com/dl/tmp/mikusduupktuqoyydces.mp4 on FF 74.0

It happens with all kinds of requests. Image loads, script loads, XHR, ...

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

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

Attachment: image.png

Thanks for the screencast!

It shows multiple selected requests (we are not supporting multiselection), which is the same symptom as in bug 1628162

Are you seeing any errors in the Browser Console?

Especially the following one?

Warning: Encountered two children with the same key, `server0.conn1.netEvent*`. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.
    in tbody (created by RequestListContent)
    in table (created by RequestListContent)
    in div (created by RequestListContent)
    ...

I am happy to look into this but, I need a reproducible test case to see it on my machine.

Honza

Comment 13

[chaephahw0kai2kaugh4]

No, but I see bunch of errors like these:

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface]

at network-response-listener.js:84 (in Firefox 75)

  /**
   * This object implements nsIProgressEventSink, but also needs to forward
   * interface requests to the notification callbacks of other objects.
   */
  getInterface(iid) {
    if (iid.equals(Ci.nsIProgressEventSink)) {
      return this;
    }
    if (this._wrappedNotificationCallbacks) {
      return this._wrappedNotificationCallbacks.getInterface(iid);  <---- this line is 84
    }
    throw Cr.NS_ERROR_NO_INTERFACE;
  },

Comment 14

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

This exception should be fixed in bug 1179250 (10 days ago so, Firefox 76)
Could you try 76 as well?

Honza

Comment 15

[chaephahw0kai2kaugh4]

On 77a1:

That exception is gone, but the problem persists. There are more verbose exceptions that were less verbose in 75, that probably include the one you mentioned:

https://megous.com/dl/tmp/defbd0c3413b191a.png
https://megous.com/dl/tmp/bed05a5426322fca.png
https://megous.com/dl/tmp/796b5ee71fc4b392.png

Comment 16

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

Any chance you can provide a test case so, I can see the issue on my machine?

Honza

Comment 17

[chaephahw0kai2kaugh4]

For example this breaks:

<!DOCTYPE html>
<meta charset=utf-8>
<title>Bla</title>

<script>
for (let i = 0; i < 10; i++) {
        fetch('t.html', {
                method: 'GET',
        }).then(r => {
                return r.text();
        });
}
</script>

https://megous.com/dl/tmp/29a6ea1fe3d0587d.png

Comment 18

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

Attachment: image.png

Thanks for the test case!

But I still no luck to repro the issue. Attaching my screenshot.

I believe that this is dup of bug 1628162
And having reproducible test case is key here to fix it.

Honza

Comment 19

[chaephahw0kai2kaugh4]

The issue happens for me with both HTTP 1.1 and 2.0. Here's the full set of headers:

https://megous.com/dl/tmp/b47bc1db4dd56438.png

All I need to do is to install Firefox 77a1, run it with -P --no-remote create a fresh profile and load the t.html served by a nginx server, and then press F5. The issue starts appearing after first F5 refresh.

Comment 20

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

Hubert, can you reproduce this using STR from comment #17 & #19?

Honza