Sprite sheet images not loading properly on first page-load at m.vlive.tv
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: twisniewski, Assigned: emilio)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
As per the diagnosis on webcompat.com, the mobile page at m.vlive.tv does not load its logo or hamburger menu in Firefox, which seem to come from the same spritesheet. This reproduces for me in the responsive design mode, until I hard-reload the page or if I tweak the CSS of the logo and disable/enable any rule.
I ran a mozregression on this and got this range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c68fe15a81fc2dc9fc5765f3be2573519c09b6c1&tochange=567a8768593eb06a86deb263f94d9de2d3d3e8fa
Emilio mentioned to me that two bugs in that range seem to stand out to him as likely culprits:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1641682
- https://bugzilla.mozilla.org/show_bug.cgi?id=1599160
As such I've tentatively placed this in the imagelib component until we can have a closer look and confirm what might be going on here.
|
Assignee | |
Comment 1•2 years ago
|
||
Taking a closer look, given it's a sprite (so it's an image that gets loaded multiple times in the page at the same time) and it happens with shift-reload (so the shared stylesheet cache shouldn't be in effect), bug 1641682 looks almost surely the culprit.
|
||
Updated•2 years ago
|
|
|
||
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1641682
:tnikkel, since you are the author of the regressor, bug 1641682, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
|
||
Comment 3•2 years ago
|
||
Although bug 1641682 does seem like a reasonable culprit I backed it out (trivial to do even after 2 years) and the problem still happened. Maybe Emilio you could take a second look to see if anything bad might be going on with regards to the code that bug 1599160 changed?
|
|
||
Comment 5•2 years ago
|
||
I put a printf at
(the one place that bug 1641682 changed) and it is not hit for the image that fails to draw. In fact I put a printf in imgLoader::LoadImage and that only gets called once for the image in question per page load, and that's the same if the image draws or does not draw on that page load. I can most readily reproduce when loading the page for the first time in a fresh profile, so we never hit the ValidateEntry path for that image on that page load.
I observed some weird behaviour though. On a fresh profile, on the very first load of the page, if I have network devtools open and the problem happens then the main style sheet (the one with the background image style for the sprite sheet) for the page does no show up there, and neither does the image in question (sp_common.png). If I inspect the element it has the background image style (so the data from the missing stylesheet must be making it through just not showing up in devtools?), and if I hover the image url then the sprite sheet shows in a popup and now the image shows up in the network pane.
I'm going to tentatively mark bug 1599160 as the regressor because that seems like enough to absolve bug 1641682.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 6•2 years ago
|
||
Here's a reduced test-case: https://crisal.io/tmp/image-stylesheet-cache/.
For future reference:
<!doctype html>
<link rel="stylesheet" href="styles.css">
<div class="foo"></div>
<script>
if (location.search == "") {
// Should trigger the request.
document.querySelector("div").getBoundingClientRect();
location.href = "?1";
}
</script>
<!doctype html>
<link rel="stylesheet" href="styles.css">
<div class="foo"></div>
<script>
if (location.search == "") {
// Should trigger the request.
document.querySelector("div").getBoundingClientRect();
location.href = "?1";
}
</script>
The main issue is that the navigation cancels all ongoing loads, but the load is shared with the next page. So the next page gets a request that is already canceled.
|
|
Assignee | |
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Updated•2 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/db51149fe959 Mark CSS image value loads as not cancelable. r=tnikkel
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/37042 for changes under testing/web-platform/tests
|
||
Comment 10•2 years ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
|
|
||
Comment 12•2 years ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox108towontfix.
For more information, please visit auto_nag documentation.
|
|
Assignee | |
Comment 13•2 years ago
|
||
Comment on attachment 9304281 [details]
Bug 1800979 - Mark CSS image value loads as not cancelable. r=tnikkel,aosmond
Beta/Release Uplift Approval Request
- User impact if declined: comment 0, also suspected to affect facebook, see https://github.com/webcompat/web-bugs/issues/112878
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Relatively simple fix (as gnarly as the bug is)
- String changes made/needed: none
- Is Android affected?: Yes
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 14•2 years ago
|
||
Comment on attachment 9304281 [details]
Bug 1800979 - Mark CSS image value loads as not cancelable. r=tnikkel,aosmond
Approved for 108.0b5
|
|
||
Comment 15•2 years ago
|
||
| bugherder uplift | ||
|
||
Updated•2 years ago
|
|
||
Comment 16•2 years ago
|
||
Reproduced the issue with Firefox 108.0b4 on Ubuntu 20.04 by following the infos provided in Comment 0.
The issue is fixed in Firefox 108.0b5 (treeherder build) and Firefox 109.0a1 (2022-11-21). Tests were performed on macOS 13.0.1, Ubuntu 20.04 and Windows 11.
|
||
Updated•2 years ago
|
Description
•