397596 - 100% cpu usage with binding setting position: fixed in constructor

Status: RESOLVED FIXED

(Core :: XBL, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, which uses 100% cpu on load with current trunk build.
It doesn't happen with a 2007-02-24 build, but does happen with a 2007-02-25 build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-24+04&maxdate=2007-02-25+09&cvsroot=%2Fcvsroot
I think this is a regression of bug 366770, because I explicitly need to use the url for the binding without the fragment identifier to get the bug to appear.

This is no hang, I can still use the browser, but I had unminimized testcases that could hang the browser completely, fwiw.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

The hanging testcase would be great too.

attachment 282352 [details] gets somehow into a loop where 
nsGfxScrollFrameInner::AsyncScrollPortEvent::Run gets called all the time.
AsyncScrollPortEvent is nsRunnable, so processing other events isn't blocked, 
which is why the testcase doesn't hang.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Using overflow and underflow events one could pretty easily reproduce non-hanging 100% cpu usage, I think. Just modify DOM or styling in overflow/underflow event listener so that a new event is dispatched.
But IMO that isn't actually any worse than
function foo() { setTimeout(foo, 0); } setTimeout(foo, 0);

But ofc in this case it would be better know why those bindings trigger
overflow/underflow event loop.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Some more information. Something creates new AsyncScrollPortEvents, but
those never actually do anything. So the loop is elsewhere.
(I think I can still prevent some useless AsyncScrollPortEvents, but
that is a different bug.)

Comment 4

[Martijn Wargers (dead)]

(In reply to comment #1)
> The hanging testcase would be great too.

I'm afraid I don't have a small testcase for that, only the very big testcase (which is really big).
I just minimized the existing testcase further, without keeping a copy of the smallish hanging testcase.

Comment 5

[Martijn Wargers (dead)]

Attachment: binding needed for testcase2

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase2

I'm also getting a similar thing with this testcase, this time using ::before in the binding. Again, 100% cpu using without locking up the browser, although I have an unminimized testcase that also completely locks up the browser (and eats up memory).

Comment 7

[Martijn Wargers (dead)]

..and using large amounts of memory.

Comment 8

[Martijn Wargers (dead)]

Attachment: testcase3, zipped

Similar testcase as testcase2, but now it's hanging the browser.

Comment 9

[Timothy Nikkel (:tnikkel)]

I can reproduce on testcase (and it is fixed by bug 507991), but not on testcase 2 or testcase 3.

Comment 10

[Timothy Nikkel (:tnikkel)]

Should be fixed by bug 507991.