786940 - Something causes occasionally lots of runnables in event loop

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

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

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?

Comment 1

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

But I think latest Nighlies are very bad.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 4

[Alex Keybl [:akeybl]]

I don't think this will be a significant user facing issue given bug 711193. Please re-nom if you strongly disagree.

Comment 5

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

Got this again. Super-annoying. I wish I had a profiler which could give some hints what causes the problem.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Tim, why do you disagree? How many users do you expect to be affected by this?

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

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

Comment 8

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

When this happens, user experience is horrible. FF UI becomes slow, and FF eats all the battery
(when using laptop).

Comment 9

[Jesse Ruderman]

(In reply to :Gavin Sharp (use [e-mail] 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?

Comment 10

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

Testing...

Comment 11

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

So far looking good.

Comment 12

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

Bah, got it again, and when it happens FF drains all the battery.

Comment 13

[bhavana bajaj [:bajaj]]

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

Comment 14

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

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.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

The built-in profiler doesn't produce useful results?

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Seems like's smaug's a better owner here, since he's the only person who can reproduce :)

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

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.

Comment 18

[bhavana bajaj [:bajaj]]

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

Comment 19

[(dormant account)]

p3 until we have a profile.

Comment 20

[Tim Taubert [:ttaubert] (inactive)]

Olli, does this still occur or can we close this bug?

Comment 21

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

I guess this can be closed, since bug 822096 is very much still open. Though, different issues anyhow.