Inconsistent positioning of absolutely-positioned element with Ahem font
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
People
(Reporter: xidorn, Unassigned)
Details
Attachments
(1 file)
366 bytes,
text/html
|
Details |
Steps to reproduce:
- open the attached testcase in a new tab of Nightly Firefox (somehow Ahem is not shown on a release version)
- resize the window horizontally
Expected result:
the position of the block doesn't change
Actual result:
the position of the block moves up slightly
It seems that I need both Ahem and absolute positioning to trigger this issue. It might be an issue of Positioned or Fonts, I'm not sure.
Comment 1•4 years ago
|
||
The severity field is not set for this bug.
:dbaron, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 2•4 years ago
|
||
Jonathon, can you take a look at this?
Comment 3•4 years ago
|
||
I can't seem to reproduce this; tried on my macOS, win10 and ubuntu machines. My guess is it might have something to do with how the font metrics get handled, but perhaps dependent on platform & resolution.
Xidorn, assuming you still see this, could you confirm what system environment is involved?
Reporter | ||
Comment 4•4 years ago
|
||
Interestingly, I can reproduce this on my macOS, Win10, and Ubuntu machines, tested with the latest Nightly.
macOS machine: MacBook Pro 15-inch Late 2013, macOS 10.15.5, 1440x900 2x
Ubuntu machine: Custom PC with 4k screen, 1920x1080 2x (when I reported this issue, it's a 1920x1200 1x screen)
Win10 machine: Surface 3, 1920x1280 1.5x
So I don't think it's related to platform or resolution.
But this issue only happens on the very first load of the page in a tab. If you have opened it once, you need to open a new tab to reproduce it, otherwise it just never happens anymore.
Comment 5•4 years ago
|
||
Ah, I see... it can also be reproduced if you Shift-Reload the page, forcing the webfont to be reloaded instead of used from cache. But it doesn't reproduce if you have Ahem installed locally (which I did), because then it loads synchronously via src:local() instead of asynchronously from a network resource.
So I guess what's happening is that the layout is dependent on the metrics of Ahem, but they're not available when the initial reflow is happening (as the font load only gets triggered when it is encountered during that reflow). And then we're not reflowing -- or at least not sufficiently -- when the font download completes, so we don't get the "final" layout based on the real metrics until you do something (such as resizing the window) that triggers a new reflow.
Description
•