DevTools network request list broken
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
People
(Reporter: knittl89+github, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(5 files)
devtools_network_mozilla.png
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
The network tab in DevTools is broken at least since version 75.0 (64-bit, on Ubuntu 20.04). Some requests miss the value in the status and other columns (see screenshot). When trying to select such a "incomplete" request line, all "incomplete" sibling lines are selected at the same time, plus the last "complete" request line before the broken ones.
The detail view then only displays details about the "complete" request. It is impossible to get details about the incomplete lines.
It is 100% reproducable and happens on different websites. I tried to start firefox with a different profile and have the same problem regardless of the current profile.
Actual results:
Many request lines are shown "incomplete" (missing value in status, type, transferred, size columns). Selecting one of these lines will highlight multiple lines but show details for the last "complete" request before the broken ones.
Expected results:
All cells should contain correct values and selecting 1 line should only select this single line. Selecting a line must display details for this line and not for a different line.
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
Honza, this is what Victoria saw as well and its easy to see on mozilla.org (tested on Nightly). Is this potentially also due to incorrect order of events from necko?
(In reply to :Harald Kirschner :digitarald from comment #2)
Honza, this is what Victoria saw as well and its easy to see on mozilla.org (tested on Nightly). Is this potentially also due to incorrect order of events from necko?
Yes, this is most likely dup of bug 1628162
Note that I can't reproduce the issue when loading mozilla.org, so having another test case would be great help here.
@knittl89: What page are you loading to see the issue. Could you please provide a test case?
Honza
@knittl89: I created a patch that should fix the problem and there is a Linux build that includes the patch. Can you please test it and let me know whether you can still see the issue?
See Job Details at the bottom of the page: the artifacts uploaded
Should be this one:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/L7HA182DRG-rE_aDjHwy_w/runs/0/artifacts/public/build/target.tar.bz2
Honza
|
|
Reporter | |
Comment 5•4 years ago
|
||
(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #4)
@knittl89: I created a patch that should fix the problem and there is a Linux build that includes the patch. Can you please test it and let me know whether you can still see the issue?
Should be this one:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/L7HA182DRG-rE_aDjHwy_w/runs/0/artifacts/public/build/target.tar.bz2
I downloaded and ran firefox from this tar (says Firefox Nightly 78), but the bug is still present, see new attached screenshot.
To answer your question from an earlier response: I tried it on https://mozilla.org. I didn't mention HTTP/2, which was my initial assumption too, because it also happens on http://example.com (which uses plain old HTTP/1.1). It happens with any site, I have not seen a site with which iit does not happen.
|
|
Reporter | |
Comment 6•4 years ago
|
||
|
|
Reporter | |
Comment 7•4 years ago
|
||
@knittl89: Thanks for the testing!
I have another build here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a52f9ef58a1f40479e5900b4e085e99f3ef4ef93&selectedTaskRun=cLVTUs1PRt-wMqG-zHYwrA-0
Could you please test it as well (again the build is in the Job Details tab at the bottom of the page)
The thing, is that I can't reproduce the issue on my machine.
Thanks,
Honza
|
|
Reporter | |
Comment 9•4 years ago
|
||
Hi, thanks for the new build. I downloaded and ran it. Still the same problem (with both mozilla.org an example.com). Can I somehow provide more information that would help in solving this?
I could also offer doing an online screen sharing session together, maybe showing this "live" helps?
Thanks for the update.
Are you able to reproduce the issue on Win or Mac?
Or is it only Linux issue?
@bomsy, are you able to repro this issue?
Can I somehow provide more information that would help in solving this?
Do you have development environment set on your machine?
Are you able to build Firefox from the source and run?
I could also offer doing an online screen sharing session together, maybe showing this "live" helps?
Thanks, yes we might want to try it eventually
Honza
|
|
Reporter | |
Comment 11•4 years ago
|
||
Hi, I only have a Linux machine available. And no, unfortunately, I have not setup a build environment for Firefox.
My offer for a screen sharing session still stands (I'm UTC+2, preferably in the evening from 15:00Z).
|
||
Comment 12•4 years ago
|
||
Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
||
Comment 13•4 years ago
•
|
||
So i think there might be two things going on here.
- I don't see the duplicates any more (i.e cases where multi-selection happens when a request is clicked).
- But i still see requests which are incomplete (they return with no response) which i think is a different issue. I've opened a bug for that in 1637188
@knittl89 Please can you confirm that you still see the multi-selection specifically happening for you?
Thanks
|
|
||
Updated•4 years ago
|
After looking at other bugs, it seems that the multiselection issue is only reproducible on Linux
Bug 1625666 - Can't select single request in Network Monitor
Bug 1632953 - Unable to select singular request in DevTools network tab
Bug 1634302 - Devtools network request list selects multiple requests when clicking on one
Honza
|
|
Reporter | |
Comment 15•4 years ago
|
||
@bomsy yes, the multi-selection issue still occurs with the latest build linked in this thread [78.0a1 (2020-05-07) (64-bit) at https://treeherder.mozilla.org/#/jobs?repo=try&revision=a52f9ef58a1f40479e5900b4e085e99f3ef4ef93&selectedTaskRun=cLVTUs1PRt-wMqG-zHYwrA-0]. I tried it on http://example.com, an HTTP/1.1 site.
Another odd issue I noticed now: I open a new firefox instance, open network tab in devtools (F12), enter "example.com" in the address bar and hit enter → the devtools window closes and re-opens immediately. No requests are shown though. I need to hit refresh or enter one more time for the requests to show up.
Selecting any of the two request lines highlights both, but only shows details of the first one (the line with a value in the "Status" column). See the screenshot attached to this report https://bug1635516.bmoattachments.org/attachment.cgi?id=9146110, which was taken with the nightly build.
Refreshing the page once more after that returns Status 304 for the path "/" and 404 for the path "favicon.ico" – both statuses show up in the devtools network view and both are clickable. "Initiator" column of the favicon request is "FaviconLoader.json:165 (img)", for "/" it is "document". Both rows have "Transferred" = "cached".
Compare that to the "broken" network view: "Initiator" of "/" is "BrowserTabChild.jsm:98 (document)", Transferred = 648B. For the "favicon.ico" request the Initiator is "img", Transferred is "cached". Maybe is a hint in the right direction?
NB. I tried this today with a brand new profile, to no avail. Same buggy behavior. So it is not a broken profile (which I had once in the past).
|
|
Reporter | |
Comment 16•4 years ago
|
||
Something (related?) I noticed today: when "persist logs" is activated and you trigger the problem of a "ghost" request line (one without a status). Then, sorting the table (by status and method?) leads to duplication of the request rows – not only the "ghost" row, but also the "linked" row. I took a screenshot. Something is really fishy with the table under Ubuntu Linux (Gnome Shell 3.36.1)
|
|
Reporter | |
Comment 17•4 years ago
|
||
|
|
Reporter | |
Comment 18•4 years ago
|
||
This seems to be no longer happening on my system since the last Firefox upgrade (now running 76.0.1 (64-bit)). example.com, mozilla.org and all other websites I have tried now show all information in the network tab of devtools and I can select single rows again and get details for each row.
Not sure what fixed it and even more confused why this (still?) happened in the nightly build. Maybe some dependency of Firefox that breaks things? Has to be. Just fired up the last nightly build linked from this bug and lo and behold: network tab in devtools works as it should.
|
||
Comment 19•4 years ago
|
||
I can confirm that this is still very much an issue for me on 77.0b7 (Developer Edition). Easily reproducible in a new, clean profile by visiting firefox.com, mozilla.org, etc.
It makes Firefox Developer Edition practically unusable for development. I would humbly suggest the severity of this issue be escalated seeing as that is the primary market for this product. This has been happening for weeks now. It also occurs on Ubuntu's 76.0 release build.
|
|
Reporter | |
Comment 20•4 years ago
|
||
In case it helps, attached is my apt history of all updated packages in this month.
|
||
Comment 21•4 years ago
|
||
I can confirm this issue on Firefox 77.0.1 (64-bit) on Arch Linux.
But in my case this issue appears only some time after OS boot. Not sure what is the cause but the last time it started after I have reopened the browser.
What's even weirder, after list breaks in Firefox, it breaks in Firefox Nightly too.
OS reboot temporarily fixes this issue. Browser restart/reset (via setting or by manually removing profile folder) does not.
Description
•