myvue.com breaks sometimes after a reload (Can't access rules of still-loading stylsheet)
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox84 | --- | fixed |
People
(Reporter: steven+mozilla, Assigned: emilio)
References
()
Details
Attachments
(5 files)
The website https://www.myvue.com/ is broken. It's impossible to select a venue and much of the navigation is missing.
Steps to reproduce:
From a clean install of Firefox in a fresh profile with no add-ons (via moz-regression):
- Go to www.myvue.com
- Wait for the page to load and the cookie banner to appear. Accept the cookies to dismiss the banner.
- Note that the page renders correctly (between the "What's on at" dropdown and the section marked "Top films" there are a series of links "Book now", "All times", "All your favourites are back"). There's also a menu-bar at the top of the page ("What's on" ... "Join").
- Clicking on the drop down marked "Choose your view" results in a list of venues appearing (it may take a second or so to appear).
- Refresh the page (I tried ctrl-R and ctrl-shift-R)
Observed behaviour:
Much of the site doesn't work. Most importantly, it's impossible to select a venue. Also, the top menu isn't working and the links just below What's on are missing.
In the console there are the following error messages that are not present on a working build.
Uncaught DOMException: CSSStyleSheet.cssRules getter: Can't access rules of still-loading stylsheet
Unable to get search data DOMException: CSSStyleSheet.cssRules getter: Can't access rules of still-loading stylsheet
[The typo "stylsheet" is in the console message.]
Expected behaviour
The page should render correctly each time it's visited.
Workarounds
Working around this is tricky as the problem is persistent.
It's still broken after shutting down and restarting Nightly. Clearing the cache through the options page, using ctrl-shift-R or bringing up the networking developer tab and selecting disable cache does not cause the page to work. Clearing myvue.com cookies also doesn't work. Clearing the cache and clearing myvue.com cookies doesn't work
Eventually, I could get my live version of Nightly back into the good state temporarily. I had to: close the web site, clear the cookies for the myvue.com domain, clear the cache, shut down Nightly and then restart.
During the moz-regression bisection (at least when I was near the start of the regression at noticed the pattern), the initial first good load was consistent (steps 3 and 4).
Bisection results
moz-regression says the build 9bddaf45 is good and the build 061e049e is bad. It identifies bug 1648736 "Don't mark a load as performed on a given document until it has actually finished." as the regressing change (and the description of that bug and the console error messages observed make this a plausible conclusion).
The site is still broken on current Nightly (84.0a1 2020-10-28).
Reporter | ||
Comment 1•4 years ago
|
||
Reporter | ||
Comment 2•4 years ago
|
||
For reference, here are the console log error messages:
Uncaught DOMException: CSSStyleSheet.cssRules getter: Can't access rules of still-loading stylsheet line 1 > injectedScript:4
i https://www.myvue.com/ line 1 > injectedScript:4
value https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
value https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
value https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
o https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
each jQuery
o https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
init https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:12
init https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:3
A https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
<anonymous> https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:1
c https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
l https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
simulateStateAfterDeferScriptsActivation https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
callback https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
run https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
P https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
callback https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
run https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
n https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
s https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js:1
Unable to get search data DOMException: CSSStyleSheet.cssRules getter: Can't access rules of still-loading stylsheet app.min.js:12:35575
init https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A:12
Reporter | ||
Comment 3•4 years ago
|
||
I've observed that a couple of times, going to the networking tab, ticking disable cache and pressing ctrl-shift-R occasionally also causes the page to render correctly, but this is not consistent. Also, according to the developer networking tab, on a random failed load, it said the main site CSS (site.min.cs?...) loaded from 825 to 901 ms but rocket-loader.min.js loaded from 829 to 976 ms and app.min.js from 2.08 to 2.19 s. icons.data.svg.css loaded from 3.20 to 3.27 s. So, possibly some CSS has loaded, but not all of it.
Reporter | ||
Comment 4•4 years ago
|
||
I've observed that a couple of times, going to the networking tab, ticking disable cache and pressing ctrl-shift-R occasionally also causes the page to render correctly, but this is not consistent.
Also, according to the developer networking tab, on a random failed load, it said the main site CSS (site.min.cs?...) loaded from 825 to 901 ms but rocket-loader.min.js loaded from 829 to 976 ms and app.min.js from 2.08 to 2.19 s. icons.data.svg.css loaded from 3.20 to 3.27 s. So, possibly some CSS has loaded, but not all of it.
One of the pieces of Javascript giving an error (the one marked as injectedScript:4) appears to be the Grunticon library (version 2.1.6). I've attached the Javascript returned from the site after running through a pretty printer (although I think I mangled attaching it to this bug). The library is available at https://github.com/filamentgroup/grunticon.
Assignee | ||
Comment 5•4 years ago
|
||
Thanks for filing and for the details. I can repro the website being broken and can take a look.
That being said it's a bit odd that you need to reload. Probably a bad interaction with the CSS caches.
Assignee | ||
Comment 6•4 years ago
|
||
So I took a look and I think this is not a regression. It just happened to be that between bug 1599160 and bug 1648736 we incorrectly reused a cached stylesheet. In fact, if I launch Firefox 78 I see the same errors. So not technically a regression I guess.
The issue is that they're using a css loading script which does something somewhat weird. In particular, on top of the <link rel=stylesheet>
load event (which is what they should be using) they also do some polling on document.styleSheets, and assume that if a stylesheet with that href is there, the stylesheet is loaded, which is not true...
Given how popular that repo seems to be, I'm surprised this is the first time we've heard about this pattern... I suspect our scheduling of timeouts during load kinda saves us most of the time. But in this case they're somehow calling onloadcssdefined
explicitly from some <img>
load event, and thus stuff breaks.
That css loader thing seems completely broken btw (it can call the load callback multiple times for a successful load, because it doesn't clear out ss.onloadcssdefined
), but whatevs.
So the real question is whether document.styleSheets
should expose the stylesheets while they're not fully loaded yet. Honestly changing that is a pretty scary change, but I guess we could give it a shot. It seems WebKit-based browsers behave like that, test-case incoming.
Assignee | ||
Comment 7•4 years ago
|
||
Assignee | ||
Comment 8•4 years ago
|
||
Reporter | ||
Comment 9•4 years ago
|
||
Thanks for the quick initial investigation. It sounds like a nasty problem and I'm happy for you to take the time fix it properly without breaking anything else.
I happen to have SeaMonkey 2.53.4 installed as well and that's showing the same problem on myvue.com. I thought earlier today that SeaMonkey wasn't affected, but that could either have been finger trouble on my part, or some sort of timing sensitivity.
I can confirm that Firefox 78 shows the problem for me as well. However, if I go back to Firefox 76 then the problem disappears again. I also tried Firefox 70 and that didn't have a problem. Interestingly, I note that on Firefox 70 and 76 I don't get the cookie banner. Let me worry about this observation, I'll update here either with a note as to where things changed or saying that these observations were false due to inconsistent behaviour.
For clarity, although I think you understood this, it's not just an explicit reload that triggers the problem. Shutting down the browser, restarting and going to the page also shows the problem. Real users are more likely to be affected by that than an explicit reload if they visit the site frequently enough that it's not in disk cache. I put the reload in the reproduction steps as the problem never shows from a clean load, which is what the regression bisection steps start with.
There's definitely a timing dependency. Playing around now with clearing the cache I can sometimes get the web site to load correctly in a fresh tab. It's possible that the hoops I was jumping through before to get a clean load (clearing cookies, shutting down and restarting the browser, as well as clearing the cache) were just coincidence.
This is all consistent with your analysis so far.
I can't comment on the details of any of your technical analysis, as it's way beyond my level of understanding.
Reporter | ||
Comment 10•4 years ago
|
||
The new bisection has completed and there was a regression.
In this case the last good build was 741feae5 and the first failing build was 2bccc3e8. The change was:
Bug 1639607 - Enable <link rel=preload> on Nightly and Early Beta only by default, r=dragana,NhiNguyen
On my latest live Nightly, if I set network.preload to false then the problem goes away, when I set it to true then the problem comes back.
This does support your analysis of some timing sensitivity.
Interestingly, the failure is correlated with the cookie banner. If the cookie banner appears (on the initial load of the website on a clean profile) then the website will break on reload. If the cookie banner does not appear then the website will be OK on reload. I think the missing cookie banner is a separate bug (perhaps in the site's Javascript).
Assignee | ||
Comment 11•4 years ago
|
||
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Depends on D95064
Assignee | ||
Comment 12•4 years ago
|
||
Hmm, I have a couple tests to fix at least...
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 13•4 years ago
|
||
Assignee | ||
Comment 14•4 years ago
|
||
The last version in phab should be green.
Assignee | ||
Comment 15•4 years ago
|
||
Assignee | ||
Comment 16•4 years ago
|
||
(In reply to Steven Singer from comment #10)
The new bisection has completed and there was a regression.
In this case the last good build was 741feae5 and the first failing build was 2bccc3e8. The change was:
Bug 1639607 - Enable <link rel=preload> on Nightly and Early Beta only by default, r=dragana,NhiNguyen
On my latest live Nightly, if I set network.preload to false then the problem goes away, when I set it to true then the problem comes back.
Oh, I had missed this comment. That's a very interesting data point... They're definitely using <link rel="preload">
on the site, they have a bunch of stuff like:
<link rel="preload" href="/assets/fonts/isonorm-regular-webfont.woff2" as="font" crossorigin="">
I wonder if that's making effectively load the stylesheet slower (after all these other things have loaded too) which would explain this.
Assignee | ||
Comment 17•4 years ago
|
||
I can confirm that at least here, the patch fixes that website.
If you want to confirm, you can go to the link in comment 15, click on the relevant B
task for your platform (it seems you're on windows so Windows 2012 x64 opt
, probably), and download the target.zip
file from the "Artifacts" tab, which will contain a build with the patch.
You shouldn't need to install it, just unzip it somewhere and run it. Or you can wait for the patch to be on Nightly too, there's no rush :-)
As I said it's a pretty scary change (so I put it behind a pref in case we have to emergency-turn-it-off...)
Updated•4 years ago
|
Comment 18•4 years ago
|
||
In the console
The resource at “https://www.myvue.com/assets/fonts/robotocondensed-bolditalic-webfont.woff2” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. www.myvue.com
The resource at “https://www.myvue.com/assets/fonts/robotocondensed-italic-webfont.woff2” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. www.myvue.com
The resource at “https://www.myvue.com/assets/fonts/robotocondensed-light-webfont.woff2” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. www.myvue.com
The resource at “https://www.myvue.com/assets/fonts/robotocondensed-lightitalic-webfont.woff2” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. www.myvue.com
https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js
And this is manipulating a lot the preload
resources.
Comment 19•4 years ago
•
|
||
Hmm clicking on the poster image
going to https://www.myvue.com/film/tenet for example, and I get other interesting stuff in the console.
Uncaught DOMException: CSSStyleSheet.cssRules getter: Can't access rules of still-loading stylsheet
Unable to get search data DOMException: CSSStyleSheet.cssRules getter: Can't access rules of still-loading stylsheet
(typo btw in the error message: stylsheet)
errors are triggered by https://www.myvue.com/assets/js/app.min.js?D4BE03CF7960963AC326D98C5323294A
function (t) {
window.LazyLoad.tryLoadImage(t)
})), S.default.init(),
init is defined at
init: function () {
var t,
e;
0 < $('body.sc-edit-mode').length || (t = new i.default,
e = document.querySelector('body').getAttribute('data-selected-locationid'),
t.getSearch(e).then(function (t) {
S = t,
o()
}).catch (function (t) {
console.error('Unable to get search data', t)
}))
},
which was itself called by https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js
Assignee | ||
Updated•4 years ago
|
Reporter | ||
Comment 20•4 years ago
|
||
I had a quick look at the build from comment 15 and it seems to work. myvue.com loads correctly and I didn't observe any odd behaviour on a selection of other sites.
Assignee | ||
Comment 21•4 years ago
|
||
Sweet, thanks for checking!
Comment 22•4 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/702857fa260e Don't expose incomplete sheets in LinkStyle.sheet / Document.styleSheets. r=nordzilla
Comment 23•4 years ago
|
||
Backed out for wpt failures on ttwf-cssom-doc-ext-load-count.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/a9847fe27caac3426eba8f517e7699cc646d0879
Log link: https://treeherder.mozilla.org/logviewer?job_id=320300197&repo=autoland&lineNumber=2728
Comment 24•4 years ago
|
||
Please also check this unexpected-pass -> https://treeherder.mozilla.org/logviewer?job_id=320303420&repo=autoland&lineNumber=8300
Assignee | ||
Comment 25•4 years ago
|
||
That test fails in all other browsers, so I'll just annotate it for now... https://wpt.fyi/results/css/cssom/ttwf-cssom-doc-ext-load-count.html?label=experimental&label=master&aligned
Assignee | ||
Updated•4 years ago
|
Comment 26•4 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1ee5fddc1caf Don't expose incomplete sheets in LinkStyle.sheet / Document.styleSheets. r=nordzilla
Comment 27•4 years ago
|
||
Backed out for wpt failures on ttwf-cssom-doc-ext-load-tree-order.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/03b2044ba47c37be88bf17e94bca0921afef463b
Log link: https://treeherder.mozilla.org/logviewer?job_id=320323548&repo=autoland&lineNumber=2160
Updated•3 years ago
|
Comment 29•3 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3e671ccc31d5 Don't expose incomplete sheets in LinkStyle.sheet / Document.styleSheets. r=nordzilla
Comment 30•3 years ago
|
||
bugherder |
Reporter | ||
Comment 31•3 years ago
|
||
It looks like the fix for this has now been pushed out to Nightly. I'm pleased to say the site is now working for me.
Thanks.
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26379 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Description
•