Closed Bug 1699785 Opened 3 years ago Closed 24 days ago

View source is showing a cached version of original page after e.g. form submissions

Categories

(Toolkit :: View Source, defect)

Product:
Toolkit
Component:
View Source
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: stephen.cunliffe, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Load any web page, right click View Source or CTRL+U hotkey to view the page source.

Actual results:

Firefox used to render the actual source that was loaded to render the HTML page, but now it is rendering the HTML source of a brand new (and what appears to be not attached to the current session) fetch of the current URL. As such 2 problems occur.

Example flow:
login.html > HTTP Post > 302 GET Redirect to > landingpage.html > View source

Problem 1.)
View source now shows the source of "login.html"(2) because Firefox made a new request for "landingpage.html" (possibly without all cookies?)... because the source shows the login.html page with the error info that the session wasn't valid/ended.

Problem 2.)
Even if a "good" re-fetch of the current page executes, this is still the WRONG source. There is very likely (especially on a landing page) various one-time code injections that will NOT happen on the 2nd to Nth page loads (e.g. JS drop a cookie, calls to localStorage/sessionStorage etc.)

Expected results:

HTML page source should render the currently loaded HTTPResponse HTML like it used to.

Note: The true, code highlighted view-source (w/errors if applicable) is such a beloved developer feature of Firefox!

The Bugbug bot thinks this bug should belong to the 'Core::Storage: localStorage & sessionStorage' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Storage: localStorage & sessionStorage
Product: Firefox → Core

I did mention the 2 storage APIs, but I think the Bugbug bot mistook this as the component. If there is a "View Source" component, that is what this should belong to.

This is probably dupe of bug 307089.

Severity: -- → S3
Component: Storage: localStorage & sessionStorage → Networking: Cache
Priority: -- → P2

That other bug is from like 16 years ago! (wow)... this was something that was working fine just a few months back (and worked fine for the best part of the last 10 years) not sure which new version triggered this regression bug.

Ah ha! I've figured out what I think is going on!

So my specific use case that is bugging me is this...

A.) I go to /some/login/page.html?some_unique_id_i_can_track=123-456-789
B.) On this page, I login, by POSTing to /other/page.html which 302 redirects to /landingpage.html
C.) on /landingpage.html I execute a CTRL+U to get the source of the /landingpage.html

HOWEVER, that isn't what I'm getting... the Regression bug here is that it is looking at the "whole" interaction as "user went to "/some/login/page.html?some_unique_id_i_can_track=123-456-789" show them the source, from the cache, for that page.

But this is not what we want (nor what happened previously)

I verified with Fiddler that there is no new request running through wininet.dll... and with a unique ID appended to the initially loaded URL I can see that that is indeed the page source that I see when doing a view-source.

TL;DR - the bug is that the view-source command is showing the source, from the cache, of the "page that was requested" (before any/all redirects), NOT what it should show, which is the source of the "currently loaded HTTPResponse"

I can submit some test case files as an example if it helps.

Minor clarification... it is loading the cached page at the beginning of the flow, however it appears to be loading a specific copy of this page in the cache... even if I login in multiple tabs/windows, Firefox is loading the same cached copy of the original page, NOT the page at the start of this specific flow.

This is a pretty serious bug for developers, and I'm encountering it too. It's especially nasty when dealing with form submissions, and/or multistage processes.

It appears that, the moment you do a view source, that "viewed source" is cached and remembered forever, even if the page changes.

Example:

  1. Display web page containing form.
  2. View source (opens in new tab).
  3. Close the view-source tab.
  4. Fill out form, submit.
  5. Get new page (response or error or conformation or next step, whatever the site sends).
  6. View source.

What happens at this point is that the old source is displayed - the one from step 1. The source for the page in step 5 IS NOT DISPLAYED.

Further, it is impossible to see that source, because the only way you could get to it would be to "refresh" the original viewed source - but that would of course just display the source from the original step 1 page.

This is a very bad bug, and prevents developers from developing processes using Firefox.

Severity: S3 → --
Component: Networking: Cache → View Source
Priority: P2 → --
Product: Core → Toolkit
Summary: View Page Source (CTRL+U) causes a brand new network request to be sent to render the already fetched HTML → View source is showing a cached version of original page after e.g. form submissions
Version: Firefox 86 → unspecified

Its been 2 months since filing this bug and yet I see it is still unconfirmed. Just wondering if this is because it hasn't been looked at yet, or that there is trouble reproducing it?

If the latter, please advise and I will create a minimum test case to exhibit the bug.

Sorry about the huge delay.

View source does execute a new request to get page HTML (source) (this is clearly reproducible in bug 1712054) and sometimes this additional HTTP request can be served from the browser cache (this is what I can't reproduce in bug 1712054 and here in this bug).

If the latter, please advise and I will create a minimum test case to exhibit the bug.

Yes, please, having a simple test case would be great help.

Honza

Flags: needinfo?(stephen.cunliffe)

I'll try to put together a repro test case and upload soon (within a week?). Oddly enough this was bugging me across multiple browsers and after much moaning and complaining I decided to see if building an extension could resolve this for me. It's not how I wanted to solve this, but... I do have a working extension for this (well, works in Chromium based browsers, working on a manifest v3>v2 port to see if I can get a Firefox version working).

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.

Status: UNCONFIRMED → RESOLVED
Closed: 24 days ago
Flags: needinfo?(stephen.cunliffe)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.