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

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: martijn.martijn, Unassigned)

Tracking

({regression, testcase})

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

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

11 years ago
Created attachment 282352 [details]
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

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.)
(Reporter)

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.
(Reporter)

Comment 5

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

Comment 6

11 years ago
Created attachment 303434 [details]
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).
(Reporter)

Comment 7

11 years ago
..and using large amounts of memory.
(Reporter)

Comment 8

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

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

Updated

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.
Status: NEW → RESOLVED
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.