Some tests may randomly fail due to forcibly reloaded by font-info-updated notification
Categories
(Core :: Layout, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | affected |
People
(Reporter: masayuki, Unassigned)
References
Details
gfxPlatform::ForceGlobalReflow() may update all documents when font info is updated. That means that all scroll position may be reset to top-left-most. This occurs if a preceding test loads a font, and that is unloaded while another test is running.
|
||
Comment 1•3 years ago
|
||
|
Reporter | |
Comment 2•3 years ago
|
||
I wonder, cannot do mochitest and WPT framework forcibly run the pending runnable event before starting next event?
|
|
Reporter | |
Comment 3•3 years ago
|
||
It seems that bug 1632669 is also a victim of this.
|
||
Comment 4•3 years ago
|
||
What is the "problem" here? It is by design that the async fallback rendering triggers the global reflow at any time.
If other tests depend on that gfx.font_rendering.fallback.async is true, it is a bug itself unless they test the async fallback rendering itself. Since bug 1676966 did not add any new tests, we can safely assume that we have no such tests. (Yes, we should have a test, but it is a different problem.)
|
|
||
Comment 5•3 years ago
|
||
See also this announcement:
https://lists.mozilla.org/pipermail/dev-platform/2021-January/025947.html
We could simply run all tests with the pref set to false, to avoid these issues
|
|
Reporter | |
Comment 6•3 years ago
|
||
If other tests depend on that gfx.font_rendering.fallback.async is true, it is a bug itself unless they test the async fallback rendering itself.
All scroll positions may be reset. That's really terrible thing for the tests checking scroll behavior. And the unexpected global reflow may occur in some tests at start of each chunk even if font list hasn't been changed actually. Therefore, this causes increasing the frequency of intermittent failures of some tests.
|
|
||
Comment 7•3 years ago
|
||
It seems surprising to me that all scroll positions may be reset; shouldn't they generally be maintained across a reflow? If I trigger a similar reflow of all documents while using the browser (e.g. by installing a new font in my system, or deactivating a currently-installed one), I don't see scroll positions everywhere getting reset.
I do sometimes see a small visual glitch, where a scroll position seems to jump a bit, particularly if something scrollable is actively in motion at the time of the reflow. This seems like a bug, though a pretty minor one; it's quite sporadic, only a minor glitch, and this isn't something that will frequently happen in normal use.
Anyhow, it's certainly plausible that triggering reflow "glitches" the position of an in-progress scrolling operation, and this could cause unexpected test failures. I think the best solution to this will be to just run the scrolling tests in a directory with the fallback.async pref disabled. (In theory those tests could fail in the same way if the system's font configuration were to change during the test run, but obviously that doesn't happen in CI.)
As for explicitly testing the async fallback behavior: yes, it would be good to have tests for this, but it's hard to see how to do it reliably. Triggering and testing the fallback will be inherently fragile, as it depends on the installed fonts and on the behavior of OS APIs (e.g. Core Text or DirectWrite) that may evolve with every OS update, as well as on the behavior of any preceding testcases that have been run in the same browser instance and might have already triggered the loader.
|
||
Updated•3 years ago
|
Description
•