Bad offsetWidth size caching for fonts |
|||||
Issue descriptionChrome Version: Windows 10 Version 63.0.3239.132 (Official Build) (64-bit) I have a function that aligns a set of elements all to the same width using offsetWidth -- "set_to_biggest_width". There's a problem when the font isn't completely loaded -- the width calculations use the previous (default or "initial" font). Thus, the text seems to be out of the bounds of the containing elements (because Open Sans is a bigger-width font than the default font). Issue replicated here: https://jsfiddle.net/agamemnus/Lx2n80q2/24/ (refresh once after loading to get correct view) No issues here: https://jsfiddle.net/agamemnus/Lx2n80q2/23/ It seems that the offsetWidth is sometimes cached inappropriately if a new font (Open Sans in this case) is loaded. If I create the elements and THEN wait for the font to load as in /23/ above, it is fine: document.fonts.load('12px "Open Sans', "ß").then(function () { h.set_to_biggest_width () }) ... however, the font is always already loaded in the web app where I use this technique, so this bug is therefore causing issues in my web app. This issue is not replicated in latest Edge and Firefox browsers.
,
Jan 24 2018
Looks like Style and Layout are doing the right thing with the wrong info. I'm not sure where a relayout needs to be triggered from. Assigning to WebFonts folks to look at.
,
Jan 24 2018
Ok, so yeah it is really weird. Just to clarify (?), it doesn't seem like a race condition or the font being partially loaded, I think... I can do a timeout of like 10 seconds before doing anything and it won't matter. 1) Font says it is loaded. (I used two different methods -- not necessarily an issue with document.fonts.load) 2) I create the elements. 3) The offsetWidth is wrong. (The non-native font checking method I have there (unused) does compare widths as well...) And in the second example, if either that (again, commented out) or the native loader is triggered, everything seems fine after. So that was weird. Is it really loaded or not? Head-scratcher. I don't have this issue when the font is native (I have Open Sans on my computer).
,
Jan 25 2018
Hi,
document.fonts.load('12px "Open Sans"') implies default font-weight (400), so it loads only the normal (400) face of Open Sans.
The bold face starts to download when an element with bold text is added to the DOM. When offsetWidth is checked, it's still downloading, so width of fallback font is returned.
It will work if you use document.fonts.load('700 12px "Open Sans"') instead.
,
Mar 1 2018
Interesting. You identified the issue, but that doesn't mean it's not a bug. This isn't the behavior of any other browser. Working for Edge: https://jsfiddle.net/agamemnus/Lx2n80q2/51/ The goal should be to have websites function the same, regardless of the browser...
,
Mar 1 2018
What ksakamoto explained is what the spec requires. Your code relies on undefined behavior, and Edge works just by chance.
,
Mar 1 2018
It also works the same way in Firefox... that's a lot of chance occurrences there! Maybe the spec should be slightly altered so that Chrome works the same way as both Firefox and Edge?
,
Mar 2 2018
In my environment (debian Linux), Firefox returns different offsetWidth in first and second load. (The fallback font is wider than OpenSans here, so it looks less ugly though.) |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tkent@chromium.org
, Jan 24 2018