Closed Bug 1574392 Opened 5 years ago Closed 5 years ago

Crash in [@ SkTextBlob::getIntercepts]


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

70 Branch



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 --- fixed


(Reporter: over68, Assigned: cmarlow)




(Keywords: regression)

Crash Data


(1 file)

Steps to reproduce:

  • Open the testcase


Actual results:

The tab crashed.

Crash report: bp-78a7a765-f17f-4978-849f-c39ad0190816

Top 10 frames of crashing thread:

0 xul.dll SkTextBlob::getIntercepts gfx/skia/skia/src/core/SkTextBlob.cpp:653
1 xul.dll nsCSSRendering::PaintDecorationLine layout/painting/nsCSSRendering.cpp:4133
2 xul.dll void nsTextFrame::PaintDecorationLine layout/generic/nsTextFrame.cpp:5700
3 xul.dll static void nsTextFrame::DrawTextRunAndDecorations::<unnamed-tag>::operator layout/generic/nsTextFrame.cpp:7049
4 xul.dll void nsTextFrame::DrawTextRunAndDecorations layout/generic/nsTextFrame.cpp:7092
5 xul.dll void nsTextFrame::DrawText layout/generic/nsTextFrame.cpp:7155
6 xul.dll nsTextFrame::PaintText layout/generic/nsTextFrame.cpp:6840
7 xul.dll void nsDisplayText::RenderToContext layout/painting/nsDisplayList.cpp:9540
8 xul.dll bool nsDisplayText::CreateWebRenderCommands layout/painting/nsDisplayList.cpp:9473
9 xul.dll mozilla::layers::WebRenderCommandBuilder::CreateWebRenderCommandsFromDisplayList gfx/layers/wr/WebRenderCommandBuilder.cpp:1800

Interestingly, this doesn't crash for me on macOS; probably related to differences in emoji font support. Note that David's flag is a long sequence of codepoints that (potentially) ligate into a single glyph, or (if not fully supported) most of them may be ignored.

Don't know if you'll have a chance to look into this, Charlie? If not, I'll try to reproduce and debug here.

Flags: needinfo?(charles.w.marlow)

:over68, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Flags: needinfo?(over68)
No longer blocks: 1572800
Regressed by: 1572800

The steps from bug 1574387.

How to reproduce:

  1. Access bug 802882
  2. Hover the mouse over "David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7"
  3. Crashed
Flags: needinfo?(over68)

blinky: thanks for the report! Would you mind letting us know what font(s) are involved in rendering this page, on your system?

In particular:
(1) Visit the testcase without the underline (so you don't insta-crash): data:text/html;charset=utf-8,🏴󠁵󠁳󠁣󠁡󠁿
(2) Open DevTools (F12), make sure "Inspector" is selected, and click the "Fonts" subtab
(3) Let us know what the "Fonts Used" list says

Flags: needinfo?(over68)

The fonts found within the "Fonts" subtab:

  • Segoe UI
  • Twemoji Mozilla
Flags: needinfo?(over68)

Looks like "Segoe UI" fonts are available at (via a link to ), in case that font happens to be specially-able to trigger this bug (not sure). [EDIT: These fonts didn't help me trigger the bug on Linux, but I did trigger the bug on Win10 without having to install any fonts -- see comment 11]

I've reproduced this bug on Windows 10, it is using Segoe UI Emoji font

Flags: needinfo?(charles.w.marlow)

I can reproduce on Windows 10, too, FWIW, using the underlined-flag testcase from comment 0. (Like Charlie, I'm also seeing the testcase render using the Segoe UI Emoji font.)

I believe the problem is triggered because the tag characters used in David's California-flag sequence (at least I guess that's what it is, I haven't got a font that supports it) aren't supported by the Segoe UI Emoji font, so they fall back to TwEmoji Mozilla; but then by themselves, they don't render anything, they're default-ignorable and get eliminated if they aren't recognized as part of a supported ligature sequence. Which leaves us with a TwEmoji Mozilla glyph run that doesn't actually generate any glyphs.

In a debug build this would trip the assertion at, but in a non-debug build we proceed past there and then crash down in skia.

I think the straightforward fix is to make CreateTextBlob just return nullptr if no glyphs are generated, and in that case skip trying to get any intercepts for this glyph run.

Priority: -- → P3
Pushed by
fix for crash caused by a zero length textblob r=dholbert
Assignee: nobody → charles.w.marlow
Flags: in-testsuite+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.