Closed Bug 1746115 Opened 3 years ago Closed 3 years ago

url blank after opening new tab and going back to it


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

Firefox 95
Windows 11



99 Branch
Tracking Status
firefox-esr91 --- disabled
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- fixed
firefox100 --- verified


(Reporter: u635660, Assigned: nika)


(Blocks 1 open bug)


(Keywords: regression)


(2 files)

Attached file 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

Component: Untriaged → Tabbed Browser
OS: Unspecified → Windows 11
Hardware: Unspecified → Desktop
Component: Tabbed Browser → DOM: Core & HTML
Product: Firefox → Core
Summary: url blank bug after opening new tab and going back to it → url blank after opening new tab and going back to it

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.

Flags: needinfo?(bugs)
Regressed by: 1715300
Has Regression Range: --- → yes
Component: DOM: Core & HTML → DOM: Navigation

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

Assignee: nobody → bugs
Severity: -- → S3
Priority: -- → P3
Summary: url blank after opening new tab and going back to it → url blank after opening new tab and going back to it

I and peterv do track this through ship-regressions.

Flags: needinfo?(bugs)

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 to parent process.

Another testcase, which triggers a blank page
(make sure to load that page using http://. The iframe uses https://) 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.

Assignee: bugs → nobody
Blocks: fission
No longer blocks: ship-regressions
Flags: needinfo?(nika)
Flags: needinfo?(ckerschb)
No longer regressed by: 1715300

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

I believe we should move 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.

Assignee: nobody → nika
Flags: needinfo?(nika)
Pushed by
Perform data URI blocking from DocumentLoadListener, r=smaug
Regressions: 1755070
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch
Flags: needinfo?(ckerschb)
Flags: qe-verify+

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.

Flags: needinfo?(nika)

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.

Flags: needinfo?(nika)

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

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.