The “https://www.mozilla.org/en-US/firefox/nightly/firstrun/ ” page is wrongly displayed after a browser update
Categories
(Core :: Networking: Cache, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox97 | --- | unaffected |
firefox98 | --- | unaffected |
firefox99 | --- | fixed |
People
(Reporter: srosu, Unassigned)
References
Details
(Keywords: regressionwindow-wanted)
Attachments
(1 file)
1.54 MB,
image/gif
|
Details |
[Affected versions]:
- Firefox Nightly 99.0a1 Build ID: 20220221094019
[Affected Platforms]:
- Windows 10 x64
- MacOS 11.6
- Ubuntu 20.04
[Prerequisites]:
- Have an older version of Firefox Nightly browser installed.
- Have a new Firefox profile.
[Steps to reproduce]:
- Open the Firefox browser with the profile from prerequisites.
- Click on the "Hamburger menu" button>Help>About Firefox.
- Click on the “Restart to update” button.
- Observe what happens.
[Expected result]:
- The “https://www.mozilla.org/en-US/firefox/nightly/firstrun/” page is correctly loaded.
[Actual result]:
- The elements from the “https://www.mozilla.org/en-US/firefox/nightly/firstrun/” page are not loaded.
[Notes]:
- Attached is a screen recording of the issue.
Comment 1•3 years ago
|
||
I don't think this is a Layout/Text bug; the page isn't being wrongly displayed, it's full of garbage data (looks like some kind of a binary file). I can reproduce the behavior, and although it's hard to thoroughly compare with the attached .gif, it looks like I'm seeing the same binary garbage in place of the first-run page (so it's not some random uninitialized data, it appears to be something quite specific).
My guess is that the first-run page here is being loaded from cache, and the cached page is somehow corrupted. If I hit Reload, the page remains broken, but if I do Shift-Reload to bypass the cache, it loads correctly. Moreover, if I Clear Recent History (including clearing cache) immediately before the version-update restart, the first-run page loads properly after the restart.
So I think we're getting garbage from the cache, for some reason.
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
I was unable to find a regression window using the Mozregression tool because the builds need to be updated to reproduce this issue.
Comment 3•3 years ago
|
||
Just FTR: yesterday, I was unable to reproduce this with any other pages besides the first-run page, but just now I saw the same kind of corruption happen to the https://www.mozilla.org/en-US/contribute page, when reloading from cache in an updated build. Again, force-reloading so as to pull a fresh copy from the network fixed the problem.
So it's not unique to the first-run page, although that seems to be the easiest case to reproduce, using the original STR here.
Comment 4•3 years ago
|
||
Fallout from bug 1675054 maybe?
Comment 5•3 years ago
|
||
Probably. This looks like essentially the same thing as bug 1756566, just happening to cached HTML instead of cached scripts.
Comment 6•3 years ago
|
||
Test scenarios:
- Download Nightly v99.0a1 from 2022-02-21 -> update to latest -> displays page correctly
- Download Nightly v98.0a1 from 2022-02-01 -> update to latest -> displays page correctly
- Download Nightly v99.0a1 from 2022-02-07 -> update to latest -> displays page correctly
I can't seem to reproduce it on my Windows 10. It appears that the original issue can not be reproduced when an update is made to the latest version and not 20220221094019. Furthermore, I would have performed a manual regressor investigation for a regression range, but it appears impossible.
I would set it as worksforme since it is now virtually unreproducible. Simona, can you please retest too?
Reporter | ||
Comment 7•3 years ago
|
||
I can also confirm that this issue is no longer reproducible.
- The “https://www.mozilla.org/en-US/firefox/nightly/firstrun/” page is correctly loaded after opening an older Firefox Nightly 99.0a1 build (Build ID: 20220219214049) and updating it to the latest version (Build ID: 20220301215224).
Considering that we are unable to find a regression window to see what bug caused this fix, I’m closing this issue as worksforme.
Updated•3 years ago
|
Description
•