Steps to reproduce:

• Open the testcase

  data:text/html;charset=utf-8,<u>🏴󠁵󠁳󠁣󠁡󠁿
  

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

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9ae108bb86e2c93d9d74f43cfa8f39a9e84cc8b2&tochange=91ae5f60b8c081767422e8bf9bb88d666ff204b3

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.

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

The steps from bug 1574387.

How to reproduce:

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

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

The fonts found within the "Fonts" subtab:

• Segoe UI
• Twemoji Mozilla

Thanks.

FWIW, we're seeing crash reports with this signature on all platforms:
https://crash-stats.mozilla.org/search/?release_channel=nightly&signature=%3DSkTextBlob%3A%3AgetIntercepts&product=Firefox&version=70.0a1&date=%3E%3D2019-08-09T00%3A00%3A00.000Z&date=%3C2019-08-16T16%3A22%3A00.000Z&_facets=install_time&_facets=version&_facets=address&_facets=moz_crash_reason&_facets=reason&_facets=build_id&_facets=platform_pretty_version&_facets=signature&_facets=useragent_locale&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports

In all cases I've seen (I've checked at least one crash report per platform), the crash is reported as being on line 653, the it.glyphCount() call:
https://searchfox.org/mozilla-central/rev/3a61fb322f74a0396878468e50e4f4e97e369825/gfx/skia/skia/src/core/SkTextBlob.cpp#653

Looks like "Segoe UI" fonts are available at https://docs.microsoft.com/en-us/windows/uwp/design/style/segoe-ui-symbol-font (via a link to https://aka.ms/SegoeFonts ), 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

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 https://searchfox.org/mozilla-central/rev/15cff10fa2d10fcc763b22e909412dcd6e9c4e88/layout/painting/nsCSSRendering.cpp#3880, 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.

https://hg.mozilla.org/mozilla-central/rev/68e4d6939b34