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




11 years ago
9 years ago


(Reporter: martijn.martijn, Unassigned)


({regression, testcase})

Windows XP
regression, testcase
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(4 attachments)



11 years ago
Created attachment 282352 [details]

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:
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
(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

11 years ago
Created attachment 303433 [details]
binding needed for testcase2

Comment 6

11 years ago
Created attachment 303434 [details]

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

11 years ago
..and using large amounts of memory.

Comment 8

11 years ago
Created attachment 316226 [details]
testcase3, zipped

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


11 years ago
Severity: normal → critical
Depends on: 507991
I can reproduce on testcase (and it is fixed by bug 507991), but not on testcase 2 or testcase 3.
Should be fixed by bug 507991.
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.