User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Open the website http://csocrew.com/
show the source code, try to select text

Actual results:

All tabs crashed

Expected results:

Text should be selectable and no crash should happen

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

The source code seems not to be able to show correctly on http://csocrew.com/ (like the attached screenshot). I got the same result on 57, so it seems like a long-existing flaw. But I didn't encounter any crash while selecting the content on my Mac.

madwi, thanks for reporting this issue. Have you sent the crash report? If not, you could view all unsubmitted crash reports and submit in about:crashes panel. If yes, could you share the link to us? The link for submitted crash reports could be also found in about:crashes panel. Thanks.

https://crash-stats.mozilla.org/report/index/27fc885f-f537-4395-9643-cf19f0190930
https://crash-stats.mozilla.org/report/index/32989668-1bd6-4190-9abe-701790190930

(In reply to madwi from comment #4)

https://crash-stats.mozilla.org/report/index/27fc885f-f537-4395-9643-cf19f0190930
https://crash-stats.mozilla.org/report/index/32989668-1bd6-4190-9abe-701790190930

The crashes have a similar signature as bug 1397220. Move to WebRender for further investigation.

Nical, does this look related to bug 1397220 ?

Looks like the same assertion but whatever is too large in the IPDL message now is probably different from the one of bug 1397220. Something related to text selection apparently, we probably generate a large number of items when selecting the very long line in the source of that page (or maybe something related to the gazillion instances of what gets rendered as that unicode charatcer thingy in the source).

Alexis, this might be a good bug for you

I can easily reproduce this, looking into it now.

This website seems to be maliciously designed to prevent scraping/analysis, for whatever reason. Some minor guesses here because the page is so nasty that a lot of tools choke processing it:

• The HTML is prefixed by 500,000 (FIVE HUNDRED THOUSAND) null bytes
• Performance-wise, this is hidden by gzip. The transmited page is only 3k, but the "actual" size is 500k.
• Evidently browsers ignore this and draw the page just fine
• However if you View Source, we try to honour that sent page and emit those 500,000 nulls as characters
• Null Is Not A Character, so it becomes tofu
• On the WR path, a Tofu is actually rendered as a Border and 4 Images
• This encoding represents a ~1000x size amplification, making the display list ~300MB
• The IPC code understandably gets upset and kills the process for trying to send that

So there's 3 high order points:

1. This page is explicitly malicious to inspection, so I don't think we should care much about view-source crashing
2. It's pretty sad that tofus take up this much space!
3. Before we perform a selection, only about ~1000 tofus are in the display list dump (~1MB), but for some reason selecting a few at the start breaks this (??? hard to debug exactly what's happening here)

We should maybe look a bit more at why selection is making things so much worse here, but I think we have more urgent things to fix than making this page work better.

Closing because no crashes reported for 12 weeks.