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

Steps to reproduce:

Open these web site: https://www.planalto.gov.br/ccivil_03/constituicao/constituicao.htm

Click to see source code page

Actual results:

Freezes the Firefox window and consumes lot of memory system

Expected results:

See the source code of brazilian constitution

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

I can reproduce, and I captured a profile of it: https://share.firefox.dev/3mQFuCl On my fast macbook, displaying the source code caused 14.4s of jank in the content process. Most of the time is spent in nsCounterList::SetScope.

Emilio, do you think there's anything actionable here? If so, feel free to forward the needinfo. Thanks!

Looks like an O(n^2) in the counters code? Is it reasonably better on your machine with layout.css.counter-ancestor-scope.enabled=false by any chance?

Yes, with the pref set to false, it goes down to 2.2s instead of 14.4s: https://share.firefox.dev/3j1njsO

Mats, perhaps you can take a look?

Does anyone know where does our view-source code lives? (i.e. the part that generates the markup, and what CSS we apply to that)

https://treeherder.mozilla.org/jobs?repo=try&revision=f2a6dc87f37d42f10af80d86592e0bfb2df5cc07

Set release status flags based on info from the regressing bug 1548753

(In reply to Mats Palmgren (:mats) from comment #6)

Does anyone know where does our view-source code lives? (i.e. the part that generates the markup, and what CSS we apply to that)

The css seems to be https://searchfox.org/mozilla-central/source/layout/style/res/viewsource.css, and the code generating the markup seems to be https://searchfox.org/mozilla-central/source/parser/html/nsHtml5Highlighter.cpp and surrounding files.
It's possible to see the generated markup by selecting some of it and using "View Selection Source" in the context menu.

Backed out for causing hybrid build bustages on nsCounterManager.cpp

• Backout link
• Push with failures
• Failure Log

layout/base/nsCounterManager.cpp(156,51): error: incompatible pointer types assigning to 'nsIFrame *' from 'nsContainerFrame '
[task 2021-10-15T21:26:20.561Z] 21:26:20 INFO - for (auto p = aNode->mPseudoFrame; p; p = p->GetParent())

WTF? That's a compiler bug, right?
It should be perfectly fine to assign a 'nsContainerFrame *' result to an 'nsIFrame *' variable.

What is this "Bp-hybrid" target about anyway?

(In reply to Mats Palmgren (:mats) from comment #14)

layout/base/nsCounterManager.cpp(156,51): error: incompatible pointer types assigning to 'nsIFrame *' from 'nsContainerFrame '
[task 2021-10-15T21:26:20.561Z] 21:26:20 INFO - for (auto p = aNode->mPseudoFrame; p; p = p->GetParent())

WTF? That's a compiler bug, right?
It should be perfectly fine to assign a 'nsContainerFrame *' result to an 'nsIFrame *' variable.

What is this "Bp-hybrid" target about anyway?

I'm not sure, maybe Aryx can help you with that.

Bp-hybrid compiles most of the code non-unified. Details in bug 1725125. :Andi could be contacted for more info.

Oh, so it's a non-unified build that didn't get nsContainerFrame.h included in this file probably. Gotcha, I'll fix that, thanks.

Still, it's a bit sad when you push to Try to check "will this break anything" and everything is green, and then it still breaks... :-(

https://treeherder.mozilla.org/jobs?repo=try&revision=3be1e36150da0c092562f688a05789a77f38c382

Fwiw, I don't know how I feel about commits being backed out just because they fail a non-unified build.
It seems like that will cause a lot of unnecessary churn in our commit history...
Fixing these build errors is almost always as simple as adding a missing #include,
which takes less than a minute to fix if someone is around...

https://hg.mozilla.org/mozilla-central/rev/d1784b93ac61

The patch landed in nightly and beta is affected.
:mats, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

I think this can ride the trains. Feel free to scream if you feel strongly otherwise.