1411953 - font rendering different when dev tools is open

Status: UNCONFIRMED

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

Description

[thomas.welter]

Attachment: ffTest.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171023180840

Steps to reproduce:

1. Open included web page (make shure arial.ttf is in the same folder)
2. open dev tools, reload
3. close dev tools, reload

for the bug the following needs to happen:
- firefox dev edition on windows
- font-face is used
- h1.offsetWidth should be called
- matrix3d needs to be used and called using JS
- resizing has no impact on the bug


Actual results:

The text shifts in position if devtools is open


Expected results:

dev tools should have no impact on the page result.

Comment 1

[Jonathan Kew [:jfkthame]]

The reason devtools has an effect here is because (by default) when the tools are open, the cache is bypassed, and this affects the loading of the webfont. If you Shift-reload the testcase (to force Firefox to bypass cache) I think you'll see the same effect even without devtools open.

You can disable this feature of devtools in the Toolbox Options panel (scroll down to find Disable HTTP Cache under the Advanced Settings section).

The layout shifts in the case when offsetWidth was accessed before the webfont had been loaded and applied to the element, and so it returns a measurement based on the default font instead. When reloading the page (without devtools open), it'll generally load from cache and be available "immediately", so then you get the expected measurement based on the webfont's metrics.

(There's nothing special about the use of matrix3d here; a similar effect can be produced with a simpler script like

    <script>
	var h1 = document.querySelector('h1');
	var s = h1.offsetWidth;
	h1.style.marginLeft = (s - 180) + 'px';
    </script>

where the resulting marginLeft will depend on whether the font had been loaded yet or not.)

Comment 2

[Jonathan Kew [:jfkthame]]

So I don't think this is necessarily a bug, as filed; it's a result of running script that depends on layout, without ensuring that the font resource needed for the "final" metrics to be reported is actually available.

The proper way to do this would be to use the 'ready' promise of the document's FontFaceSet to run the layout-dependent script once the font resources are ready. Note, however, that bug 1374974 may make this a bit tricky to do reliably at the moment.