- From: Simon Sapin via GitHub <sysbot+gh@w3.org>
- Date: Sat, 02 Feb 2019 23:00:36 +0000
- To: public-css-archive@w3.org
> Firefox fails almost all of these tests, because in every single case (including the invalid ones!) it just returns exactly what the author wrote into `unicode-range`. I can reproduce this in your test case, but I don’t understand it when looking at code. [`FontFace::GetUnicodeRange`](https://searchfox.org/mozilla-central/rev/69d3c6c61dca9a41f14797cd9924733289238d1a/layout/style/FontFace.cpp#246) ends up calling [`UnicodeRange::to_css`](https://searchfox.org/mozilla-central/rev/69d3c6c61dca9a41f14797cd9924733289238d1a/third_party/rust/cssparser/src/unicode_range.rs#168) which serializes two 32-bit integers. When profiling though I see calls [`CSSFontFaceRule::Style`](https://searchfox.org/mozilla-central/rev/69d3c6c61dca9a41f14797cd9924733289238d1a/layout/style/CSSFontFaceRule.cpp#183) but not `FontFace::GetUnicodeRange`. (But this is a sampling profiler and I haven’t tried an actual debugger.) The former method returns `nsICSSDeclaration*` pointer that looks like it might not know about `@font-face` but rather pretent it is a style rule. @emilio does this ring a bell? Now the parsing does [take a shortcut](https://searchfox.org/mozilla-central/rev/69d3c6c61dca9a41f14797cd9924733289238d1a/third_party/rust/cssparser/src/unicode_range.rs#40-43) by taking a single slice of the original input rather than concatenating the representation of each token after removing comment tokens. This would make an observable difference for cases like `U+/**/1`, but doesn’t explain the results we get. -- GitHub Notification of comment by SimonSapin Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3588#issuecomment-460006888 using your GitHub account
Received on Saturday, 2 February 2019 23:00:38 UTC