1351882 - Ordered list numbers not initially rendered with a out-of-spec font with low nglayout.initialpaint.delay

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: A document with an ol using a Google subsetted font

When a document such as the attached is reloaded in current nightly (buildid 20170329071901), there is a brief flash and then the page is rendered with the list numbers/indices missing. Switching to another tab and back causes the numbers to appear properly.

This seems to happen when using a subsetted font that is blocked by OTL validation (see bug 1331737), as setting gfx.downloadable_fonts.otl_validation to false clears up the issue (and displays the text in Merriweather).

In looking for a regression range I found that it is associated with bug 1283302, which changes PAINTLOCK_EVENT_DELAY from 250 to 5; by adding pref nglayout.initialpaint.delay = 250 the issue also goes away (and comes back when setting that pref to 5).

I've reproduced on latest nightly on both Windows 10 and OS X El Capitan, and in a VM running Windows 7.

As the OTL validation isn't done on beta and release this may not manifest there, but perhaps other reasons to fail to load the font might cause a similar issue.

I first noticed this on:
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
It is most easily seen if the list is in view when refreshing, but sometimes when the list is just off the bottom of the window it also occurs.

Comment 1

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Demonstration of missing numbers on a page

Comment 2

[Jonathan Kew [:jfkthame]]

Curious.... so the "problem" font (which gets rejected) is specified for the whole of the testcase, but it's only the auto-numbers that fail to render.

Just guessing here: the low nglayout.initialpaint.delay means that the initial paint happens before the font resource is fully downloaded/validated, and so we hide the text that is styled to use it. Then, when the download completes (and the font is rejected), we should reflow and repaint using the fallback; but for some reason that reflow doesn't handle the list numbers properly, and they remain hidden. Doing something that triggers a further reflow (e.g. zooming the window, or resizing such that a scrollbar appears) fixes things and the numbers are rendered with the fallback font just like the rest of the content.

Comment 3

[Teng-pao Yu [:tyu]]

https://cla.developers.google.com/clas/new?domain=DOMAIN_GOOGLE&kind=KIND_INDIVIDUAL is affected to. (Login with Google account needed.) My knowledge to fonts does not allow me to tell if the cause are the same but seems quite likely to me.