1746115 - url blank after opening new tab and going back to it

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[u635660]

Attachment: blank bug firefox.html

Steps to reproduce:

open firefox with blank bug firefox html file

click the click here for the blank bug text

open a new tab

then go back to the previous tab

Actual results:

it changes the url fully blank

Expected results:

it should continue to show the url shown before

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hmmm, this is the regression window I got - bug 1715300

Note that the behaviors in Fx 95 and the latest nightly 97 are a bit different.
In Fx 95, if I clicked "Click here for the blank bug" in the test, URL bar became blank. (To be more specifically, bug 1715300 caused this Fx 95 regression).
In nightly 97, the result is as comment 0. URL bar didn't become blank right after clicking "Click here for the blank bug." It became blank after I switched to another tab then switched back.

Comment 2

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

Set release status flags based on info from the regressing bug 1715300

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

I and peterv do track this through ship-regressions.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

This isn't a session history issue after all. One could fix the initial testcase by disabling bfcache in that case, but this is about blocking data: url load on top level docshell.
I believe we should move https://searchfox.org/mozilla-central/rev/7056a708787621758bef9793a93aa7ca8375eeef/docshell/base/nsDSURIContentListener.cpp#147 to parent process.

Another testcase, which triggers a blank page
http://mozilla.pettay.fi/moztests/dataurl_top.html
(make sure to load that page using http://. The iframe uses https://)

http://mozilla.pettay.fi/moztests/data_bfcache.diff.txt is a patch which makes the initial testcase work, but it is a bfcache specific hack but the actual fix should be higher up on stack and shouldn't have anything to do with bfcache.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

(In reply to Olli Pettay [:smaug] from comment #4)

I believe we should move https://searchfox.org/mozilla-central/rev/7056a708787621758bef9793a93aa7ca8375eeef/docshell/base/nsDSURIContentListener.cpp#147 to parent process.

Ah yeah, we should definitely do some of that check in the parent process. I've put together some basic patches which fix the bug, moving the check to the parent process.

I also happened to notice that the code for logging the navigation blocked error is currently broken, even without fission enabled, and even with my fix, devtools appears confused and reports us navigating to the data URI despite the load being cancelled. My patch will fix the logging issue, but doesn't fix the devtools issue.

Comment 6

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1746115 - Perform data URI blocking from DocumentLoadListener, r=smaug

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4ab5515b401
Perform data URI blocking from DocumentLoadListener, r=smaug

Comment 8

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/b4ab5515b401

Comment 9

[Ardelean Oana, Desktop QA [:oardelean]]

I tried to reproduce this on Windows 11 on Firefox 98 with no success;the url is still shown after i return to the previous tab.
Would you be so kind as to verify this fix on the latest beta/nightly builds?
Thank you.

Comment 10

[Nika Layzell [:nika] (ni? for response)]

On Windows 11 with the 100.0a1 (2022-03-14) (64-bit) nightly, the fix appears to work as expected. Clicking on the link in the test case from comment 0 no longer navigates to a different page, no history entries are added, and the URL bar is left as-is, as the page was not navigated.

Comment 11

[Ardelean Oana, Desktop QA [:oardelean]]

Thank you! Based on your answer, I shall remove the qe-verify flags and update accordingly.