User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36 OPR/77.0.4054.172

Steps to reproduce:

Firefox hangs when trying to view source for the attached file.

On a Mac, launch Firefox, go to menu File > Open file and select the file crashme.html. Then press Cmd+U to view source. Try to return to the original tab or opening a new tab, you can't see rendered pages.

Actual results:

Firefox takes more than 10 minutes to render the source code. While waiting, all other tabs become unresponsive: I can switch and use menus and all, but the actual render area has only a waiting circle animation, so I can't really do much while waiting.

Expected results:

Show tab source, let me use other tabs while waiting.

It's a large, complex file. But Chrome can render the source in about 30 seconds, and it doesn't lock up like Firefox does.

In fact, Firefox hangs when trying to render that same HTML from my server (the regular view, not the source), but I couldn't find a way to reproduce that. The ESR 72 version is the last version that can render it. I think it might be related to this.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

I also reproduce this bug on Win10. According to profile, nothing both in the main process and the content process works hard the long duration. However, the main process allocates a lot of memory, and there are a lot of waiting async IPC.

So, I guess that this is caused by the design of "view source".

I can reproduce the issue in Nightly91.0a1 Windows10 even if set accessibility.force_disabled=1 Windows10.

At least I found a regression window(with accessibility.force_disabled=1 to prevent bug 1691813).

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=33b1ed31c18a3066b2e41f1901f8221375a808dd&tochange=75559571662961f502e2f424cc3b2d7572c50bb5

And I confirmed that setting layout.css.counter-ancestor-scope.enabled = false fixes the issue in Nightly91.0a1 Windows10.

Here's another profile that shows that most of the time is spent in AddCounterChangeNode: https://share.firefox.dev/3AVaYNS

I can reproduce this hang with just a html doc with many many blank lines. This is a testcase with a few lines of text and then just a ton of blank lines, for a total of 200,000 lines according to wc -l.

(The reporter's testcase had 155,038 lines; I rounded up to 200,000 lines to create this testcase.)

This hangs forever when viewing in view-source.

I tried variants of my reduced testcase with smaller numbers of lines, and I got smaller hangs, but the hang time goes up dramatically as the number of lines go up. It feels like something quadratic is going on here. In particular, the difference between the 20,000-line scenario and 40,000-line scenario is pretty striking (2x the lines but ~4x the hang time).

Testcase with 20,000 lines:
https://share.firefox.dev/3yoSbJl
approx 2.7 seconds of hanging

Testcase with 40,000 lines:
https://share.firefox.dev/3CaRqpx
approx 11 seconds of hanging

Testcase with 50,000 lines
https://share.firefox.dev/3C5cr4O
approx 17 seconds of hanging

Looks like this is effectively a duplicate of bug 1695530, which is also about Firefox hanging when viewing files with hundreds of thousands of numbered lines (with the same regressor as this bug).