Closed Bug 1122077 Opened 10 years ago Closed 5 years ago

Changes in source file not visible in debugger on reload

Categories

(DevTools :: Debugger, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: till, Assigned: bhackett1024)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [debugger-reserve])

Attachments

(1 file)

Attached file Test case
STR: 1. in today's Nightly, save the the attached test case locally and visit it via a local webserver (but really, any file should do) 2. open the debugger and note the displayed source 3. remove lines 15-20 4. reload Actual result: "inner2" isn't logged anymore, but the changes aren't visible in the debugger Expected result: the changes should be visible in the debugger Force-reloading the page (with Cmd-Shift-R) doesn't work. View Source also keeps showing the old source, but reloading View Source updates it, and the update is then also visible in the debugger. Clearing the cache in the preferences also works.
I did a quick test and it worked for me. I will look into this again soon though.
I have the same problem in the current version of Firefox: System ------ Running Apache in XAMPP on Windows 8.1 and FF 35.0.1 newest standard release branch Steps ----- 1. save bug.htm (source code see below) to htdocs folder in XAMPP 2. change to FF In-private browsing 3. load localhost/bug.htm 4. two messages show up in the console 5. look at/verify code of bug.htm in debugger 6. edit bug.htm: delete l('output ok 2'); and save 7. switch to network analysis in FF 8. reload page (200 GET) 9. see only one message in the console as expected 10.go to debugger and see the now wrong, old and unchanged code After the first wrong occurence, this error even persists when Firefox was closed/its process killed in between. Thus the contents must have been saved to disk which might additionally indicate an unwanted leak of private information. More info: - No error appears if the htm file is fetched from disk directly. - Clearing the browser cache/history outside of In-Private & restart fixes the error temporarily until the next changes to the htm source. Source code for bug.htm ----------------------- <html><head> <script type="text/javascript"> function l(msg) { console.log(msg); }; function webGLStart() { l('output ok'); l('output ok 2'); } </script> </head> <body onload="webGLStart();"> <canvas id="glcanvas" style="border: none;" height="450" width="800"></canvas> </body></html>
This appears to still be an issue in FF 58.0.1 on Windows 10. The page operates with and shows the current code in the inspector but the debugger shows outdated code which prevents accurate debugging. I have the 'Disable Cache' option selected on the networking tab, and tried Control-shift-R to force reload, neither would cause the source in the debugger to update. As mentioned view-source also displays the outdated code and reloading it then the main page will get the debugger updated. Opening the page in another tab also works. These extra steps get very annoying quickly though.
Product: Firefox → DevTools

Honza, could you try to reproduce?

Flags: needinfo?(odvarko)

I can still reproduce the problem using STR (and test case) from comment #2

Some more comments

  • Disable cache in the Network panel seems to help.
  • The problem seems to be in Private window only.

Honza

Flags: needinfo?(odvarko)
Priority: -- → P3
Blocks: dbg-70
Priority: P3 → P2
Assignee: nobody → bhackett1024
Whiteboard: [debugger-mvp]

I can reproduce this, and it should be fixed by bug 1538056, at least when reloading the tab while the debugger is open.

From the console.log() calls made it is clear that the current version of the page is running, and that the debugger is showing an outdated version of the HTML. The problem is that the debugger makes its own fetch to get the HTML, and it is getting stale contents. That fetch uses the browser's cache when possible (so that loading the source in the debugger doesn't have to incur overhead by going out to the network again). Presumably, when private browsing is on the browser cache is not updated with the new page contents --- then someone could see what happened while doing the private browsing --- and we wouldn't want to clear entries from the browser cache while private browsing for the same reason. If the debugger is operating a window that is in private browsing mode then it could avoid going to the cache, I guess, but bug 1538056 offers a way around the fetch call entirely. The HTML that is read off the network is used directly, and is guaranteed to be correct. This only applies when the page is loaded/reloaded with the debugger open, though.

Whiteboard: [debugger-mvp] → [debugger-reserve]

This was fixed via bug 1538056.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

oops, updated the wrong bug.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

(In reply to Brian Hackett (:bhackett) from comment #6)

This only applies when the page is loaded/reloaded with the debugger open, though.

I can't reproduce this bug anymore and it seems to be fixed for me.
What do you mean by "when the page is loaded/reloaded with the debugger open"?
I tried to select another DevTools panel and reload and switch back to the Debugger, but it seems to be working.

Honza

Flags: needinfo?(bhackett1024)

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #9)

(In reply to Brian Hackett (:bhackett) from comment #6)

This only applies when the page is loaded/reloaded with the debugger open, though.

I can't reproduce this bug anymore and it seems to be fixed for me.
What do you mean by "when the page is loaded/reloaded with the debugger open"?
I tried to select another DevTools panel and reload and switch back to the Debugger, but it seems to be working.

Honza

Oops, I should have said that other panels besides the debugger will work as well. When the devtools are open and attached to a tab, they mark the tab's docshell as being watched by the devtools, which causes streamed HTML associated with the tab to be sent to the devtools, so that the HTML does not need to be refetched when the debugger shows the source. The latter logic was added by bug 1538056, which per comment 6 should fix the underlying issue in this bug. Since you can't reproduce this bug anymore, that confirms this is fixed.

Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Flags: needinfo?(bhackett1024)
Resolution: --- → FIXED

i can confirm that this bug is present in latest 85.0 version.

I can confirm this happens with 101.0.1 (64-bit). I have to use Edge as a workaround for the moment.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: