This seems to happen especially after session restore, and especially when restoring multiple tabs at once. I've seen this behavior few times during last 2 or 3 weeks. Does chrome end up using setTimeout or setInterval a lot?
But I think latest Nighlies are very bad.
So what I was seeing was that there were three articles on nytimes.com in my saved session, and nytimes.com now has something in its articles that constantly reloads an iframe -- and I think chrome does something when iframes are loaded. Or something like that; I didn't look into it very closely. But in any case, closing those three pages fixed the problem I was seeing.
pageShowEventHandlers runs off a timeout in response to all pageshow events. It's a no-op when the pageshow event is for a subframe. We could avoid setting the timeout entirely in that case.
I don't think this will be a significant user facing issue given bug 711193. Please re-nom if you strongly disagree.
Got this again. Super-annoying. I wish I had a profiler which could give some hints what causes the problem.
Tim, why do you disagree? How many users do you expect to be affected by this?
(In reply to Lukas Blakk [:lsblakk] from comment #6) > Tim, why do you disagree? How many users do you expect to be affected by > this? Sorry, I didn't do this on purpose :( I just wanted to add myself to the CC list and unfortunately can't fix the flags myself.
When this happens, user experience is horrible. FF UI becomes slow, and FF eats all the battery (when using laptop).
(In reply to :Gavin Sharp (use email@example.com for email) from comment #3) > pageShowEventHandlers runs off a timeout in response to all pageshow events. > It's a no-op when the pageshow event is for a subframe. We could avoid > setting the timeout entirely in that case. This was fixed in bug 780594. Smaug, did that help at all?
So far looking good.
Bah, got it again, and when it happens FF drains all the battery.
(In reply to Olli Pettay [:smaug] from comment #12) > Bah, got it again, and when it happens FF drains all the battery. Did this happen as part of a session restore? What's browser.sessionstore.restore_on_demand set to? This will help us to understand the severity of this issue for release. Assigning to Gavin since we think he may be in the best position to help. Feel free to reassign :)
I explicitly load all the tabs, and after that FF CPU usage stays somewhere around 80%. Unfortunately I haven't figured out what is causing this all. Profiling FF hasn't been too successful so far.
The built-in profiler doesn't produce useful results?
Seems like's smaug's a better owner here, since he's the only person who can reproduce :)
I investigated the issue mentioned by dbaron in comment #2 and filed bug 791997. I don't think it's related to this bug as smaug usually only has a couple of bugzilla and mxr tabs open.
As we've only had one report of this and its not a common user scenario , we don't think this needs to be tracked . If this gets fixed, happy to uplift :)
p3 until we have a profile.
Olli, does this still occur or can we close this bug?
I guess this can be closed, since bug 822096 is very much still open. Though, different issues anyhow.