-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSS loaded as incorrect charset unless explicitly declared #10060
Comments
On Mac and can't reproduce. Perhaps it is just Linux. |
I successfully reproduced this on Windows with my default configuration: disabled slowdown My default configuration includes the HTTPS Everywhere extension (https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp). When I direct HTTPS Everywhere to stop operating and re-run the test, this misbehaviour does not occur. |
Reproduced in 79 on Mac in incognito mode. Reproducible example at http://shkspr.mobi/test/test.html |
@edent I'm not able to reproduce this behavior in a clean Chrome profile and Incognito mode on m79. Is it possible you still have some Chrome extensions running in Incognito mode? |
Aha! Canary + Desktop did the trick thanks folks I'm able to reproduce now on macOS. |
|
Confirmed still an issue on 81.0.4026.0 for me as well on macOS. @connorjclark you're running with exactly these settings, right? |
i dunno then. Can't repro so this is all you atm :) |
Feels eerily similar to #10067 , P1.5 because whatever's going on with DevTools audits deserves a look. |
We've passed the 1 year anniversary of this bug - and it is still a problem. Could someone please help me fix it? Screencast.from.20-12-20.22.53.16.mp4To reproduce:
Minimum Viable Code:HTML<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<link rel="stylesheet" href="test.css">
</head>
<body>
<hr class="emoji"/>
</body>
</html> CSS.emoji:after {
content: "✍";
font-size: 2em;
display: inline-block;
position: relative;
top: -0.33em;
} |
Noticed that the CSS doesn't show up in the Network tab after the LH run. First clear the Network panel, then run LH, then go back to Network panel and you see: (blocking the CSS resource on a normal page load doesn't create the same effect–in that case it's just a page with no text) Also: this only happens if "Disable Cache" is not checked. That's the default in a new chrome profile, which is why Incognito repros so well. Also doesn't repro with just "Performance" checks (seems it only happens when LH does multiple passes?) |
Nice find @connorjclark , possibly
|
Big hunch: perhaps Chrome is correctly (as the spec says) assuming UTF-8 when it gets a CSS response w/ no charset, but when it saves to cache and reads from it later, makes no such assumption about encoding. This might be enough information to file a chromium bug–what do others think? |
@patrickhulce I don't see how that would matter–if the resource were blocked, the page would have no text (because text is only added via the CSS). It's an encoding issue, not a missing resource. But I'll try to comment that out locally in DT. |
If the source of the issue is a subtle change in resource loading assumptions and one part of Chrome thinks this request should be blocked while another part doesn't actually block it, seems like there's at least a chance it's related. The cache route also seems promising, if so, should be able to repro with a simple local server and no LH involved (which makes a far more compelling CRbug IMO :)). |
Still happens even if removing the blockedUrlPatterns. Minimal settings for repro: do not check "Disable Cache", only check PWA category, desktop config. |
The CSS is served by the memory cache in these "corrupted" cases. At the protocol-level, we don't see a Also funny: the |
A workaround is that we run |
I agree it must be serving from cache, but the protocol doesn't say that explicitly. There's a "served from cache" event but that's from before Lighthouse ends, as far as I can tell. I highlighted the last request for the HTML document. No request follows for the CSS (cache or otherwise), according to the protocol. |
Oh, and loading normally w/ cache enabled and devtools open (refreshing, don't run LH), you can see the CSS served by "memory cache" but it never "corrupts" :/ |
I took a look at the data in |
I don't have a minified repro, but I was able to prevent the issue with changes in this branch: It looks like this changes too much with the page load, but reenabling |
Three years later and this bug is still present on Version 110.0.5481.96 Do you have a Patreon or something I can donate to in order to get this fixed? |
Same issues happening here! :( |
Did you find any solution? |
Provide the steps to reproduce
✍
emoji incorrectly renders asâœ
.Before LH
After LH
What is the current behavior?
Why this occurs:
content: "✍";
Content-Type: text/css;
with no charset.@charset "UTF-8";
at the start of the CSS file, it renders correctly after Lighthouse runs.What is the expected behavior?
The CSS spec says, if a text encoding can't be determined, assume UTF-8.
(I am unable to change the server to serve
Content-Type: text/css; charset=utf-8
)Environment Information
Related issues
The text was updated successfully, but these errors were encountered: