Closed Bug 1694755 Opened 8 months ago Closed 8 months ago

Intermittent test failure of letter-spacing-control-chars-001.html on Windows with the non-native theme enabled

Categories

(Core :: Widget: Win32, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1392106

People

(Reporter: spohl, Unassigned)

References

Details

I am trying to make sense of this test failure, but I can't seem to figure out why this would be triggered by the non-native theme and/or why this is only occurring intermittently. Emilio or Markus, would you have any idea? I couldn't find an existing bug for this intermittent test failure, so it truly seems to be triggered by the non-native theme.

I retriggered the test for a total of four runs. The test failure occurred two out of four times:
Reftest analyzer for failure 1
Reftest analyzer for failure 2
Try run showing two failures and two passes for this test

Flags: needinfo?(mstange.moz)
Flags: needinfo?(emilio)

Puzzling. I find it hard to believe that it only fails with non-native theme. Maybe it's a new failure from some other recent change that just hasn't been filed yet.

Flags: needinfo?(mstange.moz)

I tried to deterministically trigger the broken rendering by doing various permutations of the following, but it always rendered correctly:

var textNode = document.querySelector(".text").firstChild;
// \u200blet\u200bter\u200bspac\u200bing\u200b should not be\n\u200caf\u200cfec\u200cted\u200c by\n\u200dze\u200dro\u200d-\u200dwidth\u200d\n\u2060for\u2060mat\u2060\n\ufeffchar\ufeffac\ufeffters\ufeff

textNode.data = "\u200blet\u200bter\u200bspac\u200bing\u200b should not be";
textNode.appendData("\n\u200caf\u200cfec\u200cted\u200c by\n\u200dze\u200dro\u200d-\u200dwidth\u200d\n\u2060for\u2060mat\u2060\n\ufeffchar\ufeffac\ufeffters\ufeff");

Jonathan, could this be caused by async font resolution? Do we try to find zero-width format characters in fonts or are we smart enough not to go looking for them?

Flags: needinfo?(jfkthame)

Does this happen only on Win7? I think this is almost surely not a non-native-theme bug. Win 7 does have known intermittent font problems and this could be one of them, see bug 1392106.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

Does this happen only on Win7? I think this is almost surely not a non-native-theme bug. Win 7 does have known intermittent font problems and this could be one of them, see bug 1392106.

Yes, as far as I can tell, only Windows 7 seems to be affected. So far, I can't reproduce locally or on try on Windows 10.

I think then it's likely to just be a dupe of that bug (Sheriffs are aware of that bug and probably that's why they haven't filed one for this specific failure)

Okay thank you. Let me know if I should annotate this test somehow. Marking as duplicate of bug 1392106 for now.

Status: NEW → RESOLVED
Closed: 8 months ago
Flags: needinfo?(jfkthame)
Resolution: --- → DUPLICATE
Duplicate of bug: missing-letter-win7

(In reply to Markus Stange [:mstange] from comment #2)

Jonathan, could this be caused by async font resolution? Do we try to find zero-width format characters in fonts or are we smart enough not to go looking for them?

AFAICS we shouldn't be hitting font fallback for the zero-width non-joiner, which is the control char at the point where those failures happen; the code in gfxFontGroup::FindFontForChar should just assign it to the same font as the preceding text.

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