2007846 - For some network requests the Timings tab is empty

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[Roman Deev]

Attachment: network.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

1. Open about:blank
2. Open DevTools and switch to Network tab
3. Check Persist Logs setting
4. Paste into urlbar https://tile.openstreetmap.org/16/39626/20572.png and Press Enter
5. Reload tab without cache
6. Check Timings tab for requests

Actual results:

The Timing tab for the second request is empty. This doesn't always happen, but you'll likely get it within a few tries (you can see it in the attached screencast).

Expected results:

The Timing tab for the second request isn't empty.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Julian Descottes [:jdescottes]]

Hi Roman,

Thanks for the report!

Reload tab without cache

Can you just confirm what you mean by this? Are you using a specific shorctut to bypass the cache, or are you using the "Disable Cache" feature from the Network panel.

Comment 3

[Roman Deev]

Can you just confirm what you mean by this? Are you using a specific shorctut to bypass the cache, or are you using the "Disable Cache" feature from the Network panel.

Keyboard shortcut, Cmd + Shift + R

Comment 4

[Roman Deev]

But by the way, with "Disable Cache" enabled, this also reproduces. It plays the same way as in the video, after the second reboot.

And yet, as it turns out, "Persist Logs" does not affect the bug.

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for checking, we can easily reproduce, just wanted to make sure we were testing the same scenario.
It seems that the image is sometimes read from the cache, but we fail to show it as cached?

Will check where the channels comes from.

Comment 6

[Julian Descottes [:jdescottes]]

Interestingly, I'm only able to reproduce on my Nightly profile, in non-private windows. I tried to disable my webextensions but it doesn't make any difference. In a local build (clean profile) or on any other of my regular profiles, this doesn't happen?

Comment 7

[Julian Descottes [:jdescottes]]

Actually it seems related to React DevTools, but I had to restart my browser after uninstalling it?

Roman, do you have the "React Developer Tools" webextension installed

Comment 8

[Roman Deev]

Roman, do you have the "React Developer Tools" webextension installed

Installed, but disabled

Comment 9

[Roman Deev]

I also removed React Developer Tools completely, but the problem persists.

I also tested in 148. 0a1 (2026-01-05), where I only have TamperMonkey/ViolentMonkey/FoxyProxy/uBlock Origin installed. The problem persists.

Comment 10

[Julian Descottes [:jdescottes]]

(In reply to Roman Deev from comment #9)

I also removed React Developer Tools completely, but the problem persists.

I also tested in 148. 0a1 (2026-01-05), where I only have TamperMonkey/ViolentMonkey/FoxyProxy/uBlock Origin installed. The problem persists.

Can you try in a Private window or with a clean profile. It could be related to any of the other extensions you have installed.

Comment 11

[Roman Deev]

I think I found the culprit. The bug appears if the "Show Content Scripts" option is enabled on the Debugger->Sources->⚙️ tab and any extension is active (for example, I reproduced this in a clean profile with uBlock Origin)

Comment 12

[Julian Descottes [:jdescottes]]

I will check where the network events come from now that we have better steps to reproduce. I also confirm that disabling show content scripts fixes the issue. As mentioned by ochameau during triage, this is probably a race condition which triggers more easily when handling content scripts from webextensions.

Comment 13

[Julian Descottes [:jdescottes]]

Attachment: Bug 2007846 - [devtools] Remove commented out code

Comment 14

[Julian Descottes [:jdescottes]]

Attachment: Bug 2007846 - [devtools] Only check existing FRAME targets before creating new WindowGlobalTarget

Comment 15

[Julian Descottes [:jdescottes]]

Attachment: Bug 2007846 - [devtools] Only consider frame targets in getWindowGlobalTargetByInnerWindowId

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5b08f7124ba1
https://hg.mozilla.org/integration/autoland/rev/aa1ccd7d714d
[devtools] Remove commented out code r=ochameau
https://github.com/mozilla-firefox/firefox/commit/3608531f2e6c
https://hg.mozilla.org/integration/autoland/rev/cf36663b2b4e
[devtools] Only check existing FRAME targets before creating new WindowGlobalTarget r=devtools-reviewers,nchevobbe
https://github.com/mozilla-firefox/firefox/commit/b3a43546fc6e
https://hg.mozilla.org/integration/autoland/rev/80b86c8d2421
[devtools] Only consider frame targets in getWindowGlobalTargetByInnerWindowId r=devtools-reviewers,nchevobbe

Comment 17

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/aa1ccd7d714d
https://hg.mozilla.org/mozilla-central/rev/cf36663b2b4e
https://hg.mozilla.org/mozilla-central/rev/80b86c8d2421