Closed Bug 1685334 Opened 3 years ago Closed 3 years ago

View Source loads off network, and incorrect page

Categories

(Core :: Privacy: Anti-Tracking, defect, P1)

defect

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- wontfix
firefox90 --- wontfix
firefox91 --- wontfix
firefox92 --- fixed

People

(Reporter: bugs, Assigned: timhuang)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

I encountered this yesterday in Firefox Nightly when trying to debug a web app. View Source was showing me a completely different page and took me a while to figure out why.
Network tools had the correct text in the request. And of course View Selection Source and Inspect were fine.

My guess is View Source is issuing a request instead of using the actual fetched contents. This breaks if a page just did a POST.
Example URL from the old bug.
http://www.pangloss.com/seidel/Poem/poem.cgi

View source will give you totally different content from the page itself. As well as being slow due to issuing an extra redundant request.

It could also be damaging I imagine if a 2nd POST is issued unintentionally. Certainly is surprising behaviour anyway.

Well, breaks if page did a POST, a cookie changes, the view-source doesn't submit exactly same stuff, or anything at all changes server side like a session expiration.

Ugh... I'm just going to have to treat firefox view-source as totally unusable and unreliable. I have NO idea now where the heck it comes from. I spent an hour trying to figure out how the heck the wrong query was getting deployed until I finally thought... hey. Maybe it was the same thing as that bug I filed - maybe it is getting it from... a local static cache?

Sure enough. View Source and "Inspect" have COMPLETELY different contents (inspect had the right ones of course).

In Nightly, do you have Fission enabled? See about:support and look for fission.

And if not, is this a regression?
Do you think you'd have time to find the regression range.
https://mozilla.github.io/mozregression/ can be quite handy.

Fission is disabled. I'll give a regression window a shot... Shouldn't be too hard to reproduce since I verified it with the old random poetry website. Mostly tedium of regression.
Since thankfully this appears to be across the board and not yet another thing specific to the windows VM at work, mozregression should indeed speed things up.

Has Regression Range: --- → yes
Component: DOM: Navigation → Privacy: Anti-Tracking

Oh. Thanks. I was going to get to that today, just been super busy. Appreciate it. Now I know how to get a firefox that doesn't do that. Should make debugging much more reliable.

Blocks: DynamicFirstPartyIsolation
No longer blocks: dfpi-breakage
Summary: Bug #1025146 regression. Source is now loaded off the network. → View source is now loaded off the network.

Since it was just removed from title, I'll put it here. This was fixed long ago in bug #1025146 post-e10s. But maybe there's rules for things being "regressions" that far back.

At the time it resulted in pretty similar surprises. I rather like View Source for getting raw pages without JS DOM manipulation, and was a shock to get content completely different from what the browser had just shown me, and with additional server posts. Maybe I'm a rare case though, dunno. ☺

Thanks for the comment, that's very helpful. To be clear, in our Bugzilla terminology a bug is a "regression from" the bug that caused the issue, which thinking about it might be counter-intuitive compared to how you'd say it in plain English. So this bug is a regression from bug 1651134 and I've updated the title to avoid confusion. But again, helpful context :)

See Also: → 1025146
Severity: -- → S3
Priority: -- → P3

FWIW, this also seems to impact the developer console. I was trying to debug a JS error on a dynamically rendered server page. I clicked on the JS error in the console for a bit of inline JS. The debugger launched, but with the text "Incorrect contents fetched, please reload."

Reload did not, unsurprisingly, help at all.

Was a typical dynamic page fetched using GET, with nocache headers.

So this issue breaks the debugger as well.

Bit of followup on the above comment.
For reasons I can't fathom, this seems to particularly break my testing on this basic java app on the local vm over HTTP (not HTTPS).

If I view source on the page I'm trying to debug, it kicks me to the homepage. If I manually enter view-source:http://testvm:7001/app/pagetorender ... it kicks me to the home. As if there was a session issue. This is with tracking protection disabled on the page, and no special redirection handling.

If the page has any javascript that causes an error, attempting to click on error in console EITHER links to incorrect script sources (as if they came from the homepage) or an error that the sources had changed.

There appears to be literally no way to view the page source that Firefox just fetched... in Firefox. Google Chrome and Internet Explorer 11 worked perfectly and sent me directly to the typo in the javascript. it's just that I kind of still have the habit of developing and testing first in Firefox, and hard to break it.

View Source in Chrome and Internet Explorer 11 also worked perfectly, although IE does the more useful behaviour of displaying the source it rendered, while Chrome does the buggy "fetch source off network" behaviour of Firefox (maybe this is what firefox is duplicating?)
On the other hand Chrome seems to manage to fetch the correct sources 😝

Frankly, I have no idea how the heck Firefox is ending up on the Home page. It should, if there was a cookie issue, go to the login page. This particular dev site is not setup with SSO. It's mysterious - but regardless, would not be happening if there was not this network fetch that's getting new possibly-incorrect content off the network.

Summary: View source is now loaded off the network. → View Source loads off network, and incorrect page

Another bit of insanity.
I have a STATIC HTML file where I had just changed ALL the URLs.
I hit ctrl-shift-r, verify correct contents.
Hit ctrl-u... minor heart attack. The HTML seems totally wrong - it's the old version.

Waaaaait a sec thinks I. Firefox view-source has been totally broken for some time now.
I hit ctrl-shift-p, load the page, view source... correct sources.

So... now I really have no idea what firefox is doing. It's getting it from... the wrong cache? Maybe that explains how it rendered the wrong page, since the java app above was using a redirect?

It's so confusing. All I know is it is basically never the contents it rendered ☹

One more annoying situation to document for visitors to this bug.
One workaround for this behaviour is to use the DOM Inspector. It may not be the same as the raw HTML, but you can usually get something somewhat like what firefox was trying to render from it.

One case this will not work in, is the case of an XHTML or XML parse error. The page firefox renders does not show any of the content in the DOM inspector, and if you use View Source to see the line firefox is referencing, due to the cache bug, it may be completely different from what the XML erro is referring to.

Just ran into this variant today ☺

Priority: P3 → P1
Blocks: dfpi-hq
Assignee: nobody → tihuang
Status: NEW → ASSIGNED
See Also: → 1721445

The root cause of the bug is that Firefox doesn't partition the view-source page. So, it will access a different cache that has a different content than the actual page. Bug 1651134 stopped partitioning view-source pages, which is a valid solution by then. And that's before we enabled the network partitioning.

IMO, we should partition the view-source pages as well after we enabled the network partitioning. And this should not affect Bug 1651134. I've tried partition view-source pages and this doesn't cause a regression of Bug 1651134. And it fixes the view-source problem of http://www.pangloss.com/seidel/Poem/poem.cgi because it accesses the right cache.

(In reply to Tim Huang[:timhuang] from comment #13)

IMO, we should partition the view-source pages as well after we enabled the network partitioning.

I thought the network partitioning is already enabled since Firefox 85 according to bug 1681330. Is it wrong? Or does it mean we should partition the view-source pages right now?

This patch make the view-source to be partiitoned. This will make the
view-source to access the right cache.

Thank you so much for addressing this! This has been bugging me almost every other day for past year since I still prefer to use Firefox as a default dev environment over Chrome. I try to find workarounds but, yeah, Inspector is not the same as what came over the network, and the Network tab was itself unreliable and difficult to view.

Also, while mobile Firefox has banned almost all addons making detailed testing in Stable/Beta far more limited (and you can't opt in, even with the F-Droid build which exposes about:config), view source is still accessible if you manually type it in which is quite helpful... so long as it displays the same thing the page did 😃

(In reply to Masatoshi Kimura [:emk] from comment #14)

(In reply to Tim Huang[:timhuang] from comment #13)

IMO, we should partition the view-source pages as well after we enabled the network partitioning.

I thought the network partitioning is already enabled since Firefox 85 according to bug 1681330. Is it wrong? Or does it mean we should partition the view-source pages right now?

We did enable the network partitioning since Firefox 85, but view-source pages are excluded from it because of Bug 1651134. And it was the time that network partitioning was not enabled by default. So the fix was reasonable by then. But it will cause the issue in this bug after network partitioning enables. So, I think we should apply network partitioning to view-source pages.

Pushed by tihuang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8996e2738dfd
Part 1: Partitioning the view-source: pages. r=pbz
https://hg.mozilla.org/integration/autoland/rev/6912e864751e
Part 2: Add a test to verify if the view-source pages access the right cache. r=pbz
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch

Hi nemo,

Would you be able to verify if the issue is fixed for you by using the latest Nightly?

Thanks.

Flags: needinfo?(bugs)

Confirmed on the poem generator and on a few internal apps, everything seems to be working great. Thanks again!

Flags: needinfo?(bugs)

One odd thing I'll just mention here since it is cache related in nightly.
Nightly 2021-08-12 - Was testing setting up HTTP Basic Auth on a website, and as was my habit I used CTRL-SHIFT-P as a quick and dirty way to get a clean test page with no cache, no STS, no credentials.

I was boggled that the HTTP Basic auth did not seem to be triggering on the base site page.
After multiple retests and configuration tries, I finally reached a state where it was serving what was obviously the wrong page (not changing after dropping a rewrite rule server side).

I hit CTRL-SHIFT-R

I was immediately prompted for HTTP Basic Auth.

This was astounding to me because CTRL-SHIFT-P normally does not use any existing firefox caches.
Hopefully unrelated to this bug, and I'll see if I can reproduce it reliably for another bug.

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

Attachment

General

Created:
Updated:
Size: