script: Populate document.fonts with web fonts from CSS - #46509
Conversation
Signed-off-by: Simon Wülker <[email protected]>
Signed-off-by: Simon Wülker <[email protected]>
| @@ -1,9 +1,10 @@ | |||
| [font-unicode-PUA.html] | |||
| expected: TIMEOUT | |||
There was a problem hiding this comment.
This timeout represents progress: The test runs
promise_setup(_ => Promise.all([...document.fonts].map(f => f.load())));which previously waited on nothing because document.fonts was always empty. That caused intermittent passes. Now it waits forever because we never mark FontFaces backed by @font-face rules as loaded. We can fix that in a later change.
|
🔨 Triggering try run (#29372221445) for Linux (WPT) |
|
Test results for linux-wpt from try job (#29372221445): Flaky unexpected result (31)
Stable unexpected results that are known to be intermittent (18)
|
|
✨ Try run (#29372221445) succeeded. |
TimvdLippe
left a comment
There was a problem hiding this comment.
Nice work. Appreciate all the spec comments to be able to follow the code. Only two clarifying questions
| @@ -1092,17 +1089,23 @@ impl LayoutThread { | |||
|
|
|||
| // Load new @font-face rules and remove old ones if necessary. | |||
| // TODO: Can we make the invalidation set tell us whether any @font-face rules changed? | |||
There was a problem hiding this comment.
Is this TODO still relevant? I am not intimately familiar with this code, but I think it does now.
There was a problem hiding this comment.
Its still relevant. Ideally stylo could tell us whether a stylesheet that was added to the page and then we might not have to call rebuild_font_face_set at all.
| .iter() | ||
| .find(|entry| entry.is_connected_to_font_face_rule(removed_font_face_rule)) | ||
| else { | ||
| if cfg!(debug_assertions) { |
There was a problem hiding this comment.
Is this a pattern we use? It's the first time I see it and usually we unconditionally call unreachable.
There was a problem hiding this comment.
I think for bugs that are minor (don't affect soundness, and likely won't break any other assumptions related to soundess) this is preferable to avoid panics (DOS) in production.
The problem with always only logging a warning is that its easy to ignore, so adding a debug assertion is a middle ground that helps fix such minor bugs (and i guess unconditional debug_assert!(true, ..) might be linted against?)
There was a problem hiding this comment.
I think for bugs that are minor (don't affect soundness, and likely won't break any other assumptions related to soundess) this is preferable to avoid panics (DOS) in production.
Yes, that is the intention.
and i guess unconditional debug_assert!(true, ..) might be linted against?
I've tried it just now and it doesn't trigger lints. I don't have a strong preference on what we should use (but I have used if cfg!(debug_assertions) { unreachable!() } in a couple of places before).
servo#46537) I wasn't sure how to approach this in servo#46509 but it turns out the necessary code already exists, so it is quite trivial. Changes to these descriptors do not yet reflect in the actual @font-face rule. Testing: This change adds a test --------- Signed-off-by: Simon Wülker <[email protected]>
Previously
document.fontsonly contained font faces explicitly added to it via javascript, but each valid@font-facerule should also have an entry here. This fixes intermittency in one test that readsdocument.fontsto wait for web fonts to load, but previously waited on nothing becausedocument.fontswas empty.Testing: New tests start to pass
Fixes #46434