Left menu text does not always appear on page load for the Canvas-based game at http://s20.sfgame.pl/index.php

NEW
Unassigned

Status

()

P3
normal
a year ago
a year ago

People

(Reporter: wisniewskit, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox55 wontfix, firefox56 fix-optional, firefox57 fix-optional)

Details

(Whiteboard: [webcompat][gfx-noted], URL)

(Reporter)

Description

a year ago
The Canvas game given in the related URL does not always display its menu text (along its left side) at page load. This happens for me on OSX, Linux and Windows, regardless of hardware acceleration. The text will appear if the window's size changes (debugger opens, maximized window, etc) but not when the window is iconified/minimized and re-shown, or if the tab changes. The text consistently appears for me on load in Chrome, or before this mozregression range:

>INFO: Got as far as we can go bisecting nightlies...
>INFO: Last good revision: d6d4e8417d2fd71fdf47c319b7a217f6ace9d5a5 (2016-05-25)
>INFO: First bad revision: b0096c5c727749ad3e79cbdf20d2e96bd179c213 (2016-05-26)
>INFO: Pushlog:
>https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d6d4e8417d2fd71fdf47c319b7a217f6ace9d5a5&tochange=b0096c5c727749ad3e79cbdf20d2e96bd179c213

But the obvious candidate in that range (bug 1274936) doesn't seem all that likely to be the cause.
(Reporter)

Comment 1

a year ago
Any ideas here, George?
Flags: needinfo?(gw)
Nothing springs to mind except that bug 1274936 does look suspicious. Jonathan?
Flags: needinfo?(gw) → needinfo?(jfkthame)
I think the issue here is triggered because the game is using a webfont (Komika Text) for the menu items, but the font resources are faulty (perhaps a result of subsetting an original font resource using a buggy subsetting tool?). Sample messages from the web console:

downloadable font: Layout: Lookup flags ask for mark attachment, but there is no GDEF table or it has no mark attachment classes: 512 (font-family: "Komika Text" style:normal weight:normal stretch:normal src index:2) source: http://playagames.akamaized.net/fonts/KomikaText.woff unknown:1:27
downloadable font: Layout: Failed to parse lookup 12 (font-family: "Komika Text" style:normal weight:normal stretch:normal src index:2) source: http://playagames.akamaized.net/fonts/KomikaText.woff unknown:1:27
downloadable font: GPOS: Failed to parse lookup list table (font-family: "Komika Text" style:normal weight:normal stretch:normal src index:2) source: http://playagames.akamaized.net/fonts/KomikaText.woff unknown:1:27
downloadable font: GPOS: Failed to parse table (font-family: "Komika Text" style:normal weight:normal stretch:normal src index:2) source: http://playagames.akamaized.net/fonts/KomikaText.woff unknown:1:27
downloadable font: rejected by sanitizer (font-family: "Komika Text" style:normal weight:normal stretch:normal src index:2) source: http://playagames.akamaized.net/fonts/KomikaText.woff

Because the font doesn't load successfully, we'd generally expect to render with a fallback (e.g. the default serif font); but for some reason that isn't happening for the initial rendering (a timing issue of some kind?). Resizing the window (for example) triggers a reflow and then we draw with the expected fallback.

This is (presumably) only an issue on Nightly (or Dev Edition?) channels, because on Beta/Release the gfx.downloadable_fonts.otl_validation preference defaults to 'false', which relaxes our validation of font resources and allows the Komika Text font to load successfully.
Flags: needinfo?(jfkthame)
FTR, I tested this on macOS Nightly, and consistently see the behavior that the menu is blank on first load if gfx.downloadable_fonts.otl_validation is set to true, but displays successfully if it is false.

However, depending how the game is written, it's possible that it might display blank even with validation disabled, if the font loads relatively slowly (e.g. network latency) and hasn't fully loaded by the time the canvas drawing happens. I haven't tried to dig through the JS to see if it uses APIs such as CSS Font Loading to ensure the resources are available before it tries to paint, or if it just fires off text-drawing calls and hopes for the best...
One more observation: with validation turned on (so that the menu text consistently fails to appear on initial load), and with the Web Console -also- open (in a separate window), which tends to make things load more slowly, I am *intermittently* seeing the site also fail to draw the text within the main central panel of the game's initial screen.

The intermittent nature of this failure makes me suspect the site is not correctly waiting for font-loading to complete before it draws to the <canvas>; it usually works OK provided the font loads fairly quickly, but depending on various timing-related factors -- of which font validation would be one -- it may not be reliable.

It looks like the font loading is handled somehow in sfgame144.js, which contains 4000-plus lines of minified javascript. I'm not going to try and debug that.
Whiteboard: [webcompat] → [webcompat][gfx-noted]
Sounds like there is a problem in the site that we somehow expose more now.
status-firefox55: --- → wontfix
status-firefox56: --- → fix-optional
status-firefox57: affected → fix-optional
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.