[e10s] view-source on a UTF-8 document with late meta charset that displays correctly shows the source in "Western" rather than UTF-8
Categories
(Core :: Internationalization, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox45 | --- | affected |
People
(Reporter: dbaron, Unassigned)
References
()
Details
(Keywords: regression)
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
Comment 3•9 years ago
|
||
Comment 4•8 years ago
|
||
Comment 5•8 years ago
|
||
Comment 6•8 years ago
|
||
Comment 7•6 years ago
|
||
It seems this bug still happens.
Mike, am I correct when saying that the charset from the meta tag would be set on the channel via HttpBaseChannel::SetContentCharset ? In which case I think that we're sending the response head to the childChannel during OnStartRequest, but the charset is set on the parent channel later than that, so the child never gets it.
I think we could probably add a new IPDL message to set the charset. Assuming the IPC connection is still up by the time we parse the meta tag :)
(In reply to Mike Conley (:mconley) (:⚙️) from comment #6)
I think the problem is at a deeper level.
In the non-e10s (good) case, we return "UTF-8" when attempting to determine
the charset from the channel here:http://searchfox.org/mozilla-central/rev/
8562d3859b89ac89f46690b9ed2c473e0728d6c0/dom/html/nsHTMLDocument.cpp#701
How does the encoding end up on the channel in that place instead of coming from the channel in the TryCacheCharset() step?
Comment 9•6 years ago
|
||
I completely forgot about this bug! Forgive me if my memory is a bit foggy on it.
Reading my comment again, I think I was basically reporting my findings, without really understanding how the underlying mechanisms of determining encoding work. Really, I was just comparing the working case (non-e10s) with the broken case (e10s), and finding what ultimately was different.
How things work under the hood from there is a bit of a mystery there - and I don't have much advice on how best to address it.
FWIW, the mechanism by which WebKit finds the meta is that WebKit doesn't actually fully honor the WebKit-based 1024-byte limit and scans past 1024 bytes if it hasn't seen a tag that is not allowed in head.
The site has fixed the problem, but the original problem reported here is being fixed in bug 1701828.
Description
•