1641673 - Lots of time spend in setTimeout calls on https://www.tvnow.de

Status: RESOLVED DUPLICATE of bug 1652516

(Web Compatibility :: Site Reports, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0 ID:20200525093440

Sometimes the given website uses a full CPU core whereby nearly all the time is spent in calls to setTimeout. Here a profile: https://share.firefox.dev/2TKRuYg

It seems to happen for me when starting to watch a video, then pausing it, and leaving it alone in a background tab. Maybe even a hibernation of the machine could be related.

When I get switch back to the tab, the overlay with the video controls is still visible. Clicking the play button doesn't cause any reaction.

As Olli mentioned to me this is most likely a site issue.

Dennis or Mike, do we have any contact so we could reach out?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also note that the memory as used by the web content processes increased by 144MB during these 8s of profile recording. Next time when I see it, I can clearly wait longer.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

And I hit it just again: https://share.firefox.dev/2zvB8w4

Here what I noticed:

• It's indeed allocating a lot of memory. Within 20s the memory usage went up by 800MB!
• Clicking the play button doesn't work as mentioned above
• I can still play / pause the video by hitting the space key
• Double clicking the video brings it into fullscreen and automatically starts the playback

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The registered handler for the click event runs the following code:

function(e) {
  if (!(e = e || t.event)) return;
  const n = this || e.target || t,
    r = n[L[e.type].false];
  if (r)
    if (1 === r.length) h(r[0], n, e);
    else {
      const t = r.slice();
      for (let r = 0; r < t.length && (!e || !0 !== e[I]); r++) h(t[r], n, e)
    }
}

Comment 4

[Mike Taylor [:miketaylr]]

I don't have any contacts here for this site, and I'm willing to bet that Dennis will have a better time parsing the German language to find one. ^__^

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Maybe this is also requiring the ublock origin, and noscript webextensions to be installed. Especially for the latter I have only tvnow.de, and akameihd.net set as trusted. So loading of a script might fail and as such triggering that behavior. I will test with noscript disabled for a while.

Comment 6

[Karl Dubost💡 :karlcow]

Henrik, could you first restart with addons disabled in the latest nightly and/or create a new profile without addons and test if it's happening. Yes it could be because of addons, and in this case it would probably not be a webcompat issue.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Maybe this is related to NoScript. Lets wait if a fix for bug 1650305 will help.

Comment 8

[Dennis Schubert [:denschub][OOO, back June 3rd]]

I did some testing, and it indeed looks like it's NoScript. I'm happy to do outreach if it turns out to be a Gecko bug, but this looks like it's addon related, and experience shows that people really don't care if we ping them about issues caused by addons, so clearing the ni?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks for the clarification Dennis! Good to hear that others can also see it. I will mention it on bug 1650305.

Comment 10

[Giorgio Maone [:ma1]]

Can you still reproduce in 11.0.34?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I will keep an eye on it over the next days. It's not manifesting right away, so it might take some days.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So far I haven't seen the problem again. I'm going to mark this bug as WFM, and will reopen in case it happens again.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Dennis Schubert [:denschub] from comment #8)

I did some testing, and it indeed looks like it's NoScript. I'm happy to do outreach if it turns out to be a Gecko bug, but this looks like it's addon related, and experience shows that people really don't care if we ping them about issues caused by addons, so clearing the ni?

As noticed on bug 1641673 the problem isn't gone yet. There are still a ton of calls to setTimeout going on. Dennis, maybe you could reach out to the website owners? Some more information can be found at bug 1652516 comment 28.

I would say that we keep both bugs open, bug 1652516 for possible improvements in Gecko and that one for webcompat, and the hope that a change on the website by using less aggressively the timers would help.

Comment 14

[Dennis Schubert [:denschub][OOO, back June 3rd]]

Thanks for nudging. Sad to hear that a addon fix didn't resolve the issue.

I reached out to them and asked if they're willing/able to provide more context and collaborate on a resolution. I've looked at the bug you linked, and this looks like that's probably something that needs addressing inside Gecko, but maybe we can convince them to change their code.

In any way, I don't think we need two bugs, as there isn't anything we could do here besides gathering more context. This isn't something we could possibly fix in an intervention, and our usual approach is to close such bugs as a duplicate of the engineering bug, where we can provide more context to the people working on a Gecko fix - if we get any context. So I'll continue that tradition and mark this bug as a duplicate of bug 1652516.