Open Bug 1581296 Opened 2 years ago Updated 2 years ago

Freeze / terrible performance with the attached test case

Categories

(Core :: Layout: Block and Inline, defect, P3)

defect

Tracking

()

People

(Reporter: syskin2, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qf:p3:responsiveness])

Attachments

(1 file)

Attached file bug.html

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

Steps to reproduce:

  1. Open the attached test case in a window that is sufficiently wide (or you'll freeze right there)

  2. Resize the window horizontally to start pushing some of the dashes to new lines as they don't fit.

Actual results:

Pushing down a bunch of dashes down works fine with no visible performance problem. Then, as you resize further, something changes and it will just freeze.

If you want a few minutes (on a modern PC) it will eventually finish the reflow and will unfreeze.

Profile: https://perfht.ml/2LOSDtm

I don't see anything terribly wrong with that callstack, so it's likely that we're reflowing over and over...

Jonathan, do you know if / when and why does the line layout algorithm backtrack?

It'd be good to know if this is a regression somehow, I'll try to bisect myself though right now I'm on a pretty bad connection so...

Status: UNCONFIRMED → NEW
Component: Layout → Layout: Block and Inline
Ever confirmed: true
Flags: needinfo?(jfkthame)
Whiteboard: [qf]

Looks like it's slow at least as far as Firefox 56, though behavior changed sometime between 56 and 58.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Profile: https://perfht.ml/2LOSDtm

Here's that same profile, zoomed to the relevant time-region & just showing the relevant track: https://perfht.ml/309sQFf

This may be related to bug 1308876 (at least, both involve nested-inline blocks and exponential blowup).

Blocks: FastReflows
See Also: → 1308876

I can reproduce this jank at least as far back as Nightly 2011-01-01 (4.0b9pre). I didn't try further than that because pre-4.0 builds tend not to run on my machine (they need an old version of a library or something).

--> Doesn't seem to be a regression. Dropping "regressionwindow-wanted" keyword, and triaging this as qf:p3:responsiveness.

Whiteboard: [qf] → [qf:p3:responsiveness]
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.