Open Bug 1472581 Opened 3 years ago Updated 9 months ago
Debugger reloads current URL rather than displaying source of current document
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180628175621 Steps to reproduce: Pressed F12. Actual results: Saw changed document at same URL reloaded from network. Expected results: Seen source of actual current document.
I know there are headers that expire the document, for good reason, so new requests to the URL should not fetch a cached result. However, conceptually, using the debugger should not be treated as a reload, another tab, or any other user-initiated request. The current document has to be allowed to display as a DOM in the browser so I don't see how it's a security/cache violation to have an in-memory-only copy of its source for use in the debugger, etc. If the document is reloaded by the user, this memory only copy should not be used anyway as it may have been modified by document.write(). Frankly, I'd rather see a notice that the document has expired and your tool is incapable of showing the response source, and provide an option to request again, rather than assume and make another network request. If it's a performance issue, then let us opt-in to keeping source markup in memory. I noticed this because of a separate but related issue that the debugger is not maintaining the current Container's context, so when (re-)loading the URL, as it shouldn't, its getting redirected to an entirely different page and the resulting source displayed in the debugger has nothing to do with the currently displayed document.
I noticed it because of bug 1375036.
Regarding your STR: Can you be a bit more specific about what you mean with "actual current document" and "changed document"? It is unclear what you were expecting. Regarding the functionality you described: The debugger must fetch the sources independently of the browser for performance, we throw away the source as soon as it is parsed, and we load sources lazily. We make the second fetch in order to get and save the source texts. I am not sure if there are other reasons. I believe that bug has an explanation regarding the thinking behind reloading sources at https://bugzilla.mozilla.org/show_bug.cgi?id=1060732#c19 -- There is a mention of changing our approach to how we do things, but it isn't clear if this was implemented (it wasn't part of the patch that resolved that bug) I will confirm with Jim.
Sorry, I mean... Actual results: See document source in the debugger that does not exactly match the one rendered in the current tab. Expected results: See the source of the currently rendered document, exactly as it was fetched (ideally including modifications made with document.write(), etc. before the document was closed for writing). I disagree with "The debugger must fetch the sources independently of the browser for performance". It's not a "must" it's a design decision and it breaks accurate debugging as it requests a different document. If a URL can only be used once, it gets broken, if unique data is put in a response, then the source in the debugger doesn't have it. It's unexpected and unobvious. It means, when developing with Firefox, we're debugging only an approximation. I'd rather cop the extra kilobytes of RAM usage than be baffled as to why the breakpoint I'm paused at has values that don't match the code.
Hi Roy, You might have missed the last part of my reply: > There is a mention of changing our approach to how we do things, but it isn't clear if this was implemented (it wasn't part of the patch that resolved that bug) You will find more context regarding this in the link from my previous comment.
:jimb -- to clarify: can you give a bit of context about why the debugger is making a second request to get sources? specifically in the case of cookies / containers, but it looks like we have already seen similar issues with post requests.
ping :jimb, :yulia what is the status of this bug?
I don't think there has been any movement on it
I agree we ideally should not be re-fetching documents if we don't have to; in practice, fetches are side effects. This is not something we're going to be able to look into immediately, so I'm setting its priority to P3.
Priority: -- → P3
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1375036
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
You need to log in before you can comment on or make changes to this bug.