Open Bug 1643868 Opened 4 years ago Updated 4 years ago

Inconsistent positioning of absolutely-positioned element with Ahem font

Categories

(Core :: Layout: Text and Fonts, defect, P3)

defect

Tracking

()

People

(Reporter: xidorn, Unassigned)

Details

Attachments

(1 file)

Attached file testcase

Steps to reproduce:

  1. open the attached testcase in a new tab of Nightly Firefox (somehow Ahem is not shown on a release version)
  2. 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.

The severity field is not set for this bug.
:dbaron, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dbaron)

Jonathon, can you take a look at this?

Severity: -- → S3
Flags: needinfo?(dbaron) → needinfo?(jfkthame)

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?

Flags: needinfo?(jfkthame) → needinfo?(xidorn+moz)

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.

Flags: needinfo?(xidorn+moz)

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: