Closed Bug 652472 Opened 14 years ago Closed 8 years ago

Higher setTimeout/setInterval clamping in inactive tabs breaks countdown scripts

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(firefox5+ wontfix)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox5 + wontfix

People

(Reporter: dao, Unassigned)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: comment #50 should be the end of this) 

Quote from <http://forums.mozillazine.org/viewtopic.php?p=10728359&sid=ad082c29e7d173e9c5d49f6987078f2c#p10728359>:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110423 Firefox/6.0a1 ID:20110423042612

Please help confirm the problem:

1. Go to the any download page of Freakshare
(You may use this link: http://freakshare.com/files/g5msm8k8/xul.dll.html, the file is Nightly's xul.dll uploaded by me so it's completely legit)
2. There is a countdown timer on the Free column, counting from 59.9sec
3. Switch to another tab in Nightly for few seconds, then switch back to Freakshare's tab
4. You should notice that the countdown stops if you switch to another tab, but resume after switching back. EDIT: Sometimes the timer still counts, but at a much slower rate than normal, something like 2sec:1sec

This is reproducible in a new profile in Nightly; and it does not happen in Fx4 (portable version), Chrome stable, and IE9.
Version: Trunk → 5 Branch
Yes, this is the expected behavior given bug 633421.  Fwiw, Chrome dev has the same behavior we do, for the same reason.

Of course this page is fundamentally flawed in that it assumes things fire at the rate it sets, which was never guaranteed...
Given that the time-out is meant to be an incentive to subscribe to their premium subscription, I don't think the designers of the website have a lot of incentive to fix their algorithm to work better in a background tab ... If anything, they might want to make it worse to force you to stare at the countdown.

'Makes free file hosting services less annoying' might be a valid selling point for browsers, so a consensus among browser vendors might be important ... but I don't know if that's worth taking into account.
tracking in case this is widespread.
tracking-firefox5: ? → +
Looks like fileserve.com has a similar setup.
URL: http://freakshare.com/files/g5msm8k8/...
Summary: Higher setTimeout/setInterval clamping in inactive tabs breaks countdown script → Higher setTimeout/setInterval clamping in inactive tabs breaks countdown scripts
no top sites concerning us yet. also sites will have to modify not just for us but chrome as well.
tracking-firefox5: + → -
Is there evidence that Chrome is going to ship with this as well?

Note that these sites aren't interested in super accurate countdowns, as comment 3 rightly points out. The scripts work pretty much as intended in all released browsers; calling them "fundamentally flawed" seems quite wrong.
> Is there evidence that Chrome is going to ship with this as well?

Well, it's in their dev builds.  Whether they ship is something we won't know till they ship, obviously.
Right. Dev is on a level with Aurora, I think, so this doesn't really mean a lot. Maybe they're having the same discussion right now, or maybe they aren't, because nobody told them about site compatibility issues yet. Either way, it seems that this decision shouldn't be based on what Chrome is experimenting with, unless they make the explicit statement that they're determined to ship this.
I didn't say it was limited to dev builds.  That was just all I had tested...

I just checked, and the 1s clamp for background tabs is present in Chrome 11.0.696.57 (which is the current stable Chrome 11 release).  So they've shipped this in a final release as of 5 days ago.
Okay, so the next question is whether they actually made an informed decision, i.e. if the had similar bug reports, and if we should really follow their lead and expect sites to change. As said before, I don't think it's fair to call these scripts flawed.
And I think you're wrong.  If the scripts want to enforce a particular wall-clock wait, then they should be checking Date.now() when the timer fires.  Otherwise the wait time they produce will be different from the desired time if timers fire inexactly, which they do all the time due to load, say.  So these scripts produced incorrect times all along; I just got one of them to take 2x as long as it's supposed to in Firefox 4 by just doing something compute-intensive in another tab at the same time.  If that's not "flawed", what is?

I take your point on Chrome, but for both us and Chrome cutting down on CPU (ab)use by background tabs is a pretty high priority.  So I suspect that as long as this is the only observable issue we will stick with the high background tab clamp.  But you're welcome to search Chrome's bug database to answer your question!  I tried, and can't find any issues related to this.
(In reply to comment #13)
> And I think you're wrong.  If the scripts want to enforce a particular
> wall-clock wait, then they should be checking Date.now() when the timer fires.

They don't care about wall-clock time. They want to let users wait some time in order to encourage them to get a premium account. The concrete time span is arbitrary and the countdown is good enough if the steps vaguely resemble seconds.

> Otherwise the wait time they produce will be different from the desired time if
> timers fire inexactly, which they do all the time due to load, say.  So these
> scripts produced incorrect times all along; I just got one of them to take 2x
> as long as it's supposed to in Firefox 4 by just doing something
> compute-intensive in another tab at the same time.  If that's not "flawed",
> what is?

Let me emphasize again that it doesn't really matter whether it takes 60 or 80 seconds. 2x is unfortunate but still seems acceptable for an edge case, especially if the user isn't looking at the counter. These kind of countdowns aren't new, apparently they worked well enough for years.

Taking ten minutes instead of one even if nothing compute-intensive is happening seems like a different quality. Both here and in bug 653664 the initial user perception was that the countdown had stopped entirely.
(In reply to comment #14)
> They don't care about wall-clock time. They want to let users wait some time in
> order to encourage them to get a premium account. The concrete time span is
> arbitrary and the countdown is good enough if the steps vaguely resemble
> seconds.

> Let me emphasize again that it doesn't really matter whether it takes 60 or 80
> seconds. 2x is unfortunate but still seems acceptable for an edge case,
> especially if the user isn't looking at the counter.

Put another way: If you reported this kind of inaccuracy to the site owners, chances are that they'd just shrug their shoulders.
They'd just shrug their shoulders at the behavior this bug is filed on, I bet. Their business model effectively depends on people being unable to bypass the counter, after all, which switching tabs used to do.
(In reply to comment #16)
> They'd just shrug their shoulders at the behavior this bug is filed on, I bet.
> Their business model effectively depends on people being unable to bypass the
> counter, after all, which switching tabs used to do.

That's plausible as well, but it doesn't make this bug less problematic. From the user's perspective this is worse, as it means this new annoyance would remain as long as we support it. For us it's disadvantageous since not all browsers share this annoyance for the time being.
Sure; I'm not saying this is not a problem.  I'm just not convinced it outweighs my CPU usage from Firefox being 2% instead of 20% after Firefox finishes starting up...
(In reply to comment #18)
> Sure; I'm not saying this is not a problem.  I'm just not convinced it
> outweighs my CPU usage from Firefox being 2% instead of 20% after Firefox
> finishes starting up...

Can we estimate how the average user will benefit from this? Are these small wins for many sites, a large win for a site doing something particularly expensive, ...?
Both.  What it does is effectively turn off various animations, tickers, etc in background tabs.

This is a particularly big deal on mobile, obviously.
I understand what the potential cases are, but I wonder how widespread they are, e.g. what accounts for the 2% vs. 20% difference in your sample and how far it can be generalized.

For animations, I had the impression that requestAnimationFrame is the future anyway.
In my case a good bit of it is news sites and blogs (blogs are particularly bad about this sort of thing).

Note that any time my CPU usage goes above 50% when idle I try to find the relevant page (a blog or news site, always) and kill it.  So my 20% is actually lower than it would be for a typical user who might have opened some pages like that to read later.

> For animations, I had the impression that requestAnimationFrame is the future

Sure; 5 years from now I expect 70% of pages that should be using it to be using it...
Blogs seems unexpected, what exactly are they doing?
Several different things.  For example, ShareThis polls the location.hash as fast as it can last I checked, so any blog that includes the ShareThis widget will suck CPU.  Some of the other "like" and whatnot buttons have similar problems.  And then there's the ads...
Sorry for the noise. Moving back to tracking radar because this is a potential web-compat issue that is new to Firefox 5. (This is not an indication of a decision.)
tracking-firefox5: - → +
(In reply to comment #19)
> (In reply to comment #18)
> > Sure; I'm not saying this is not a problem.  I'm just not convinced it
> > outweighs my CPU usage from Firefox being 2% instead of 20% after Firefox
> > finishes starting up...
> 
> Can we estimate how the average user will benefit from this? Are these small
> wins for many sites, a large win for a site doing something particularly
> expensive, ...?

As an average user I have to say the answer is "not at all", maybe Cpu usage occasional drops a little ,but who will notice and who cares? Nonetheless I think the mobile device users might be interested and less likely they will download stuff from said sites. so why don't we only implement it on the mobile version?
And here is another thought: why don't we add a switch at about:config? this way everybody will be happy.
> As an average user

Just so we're clear, no one who's involved in this bug is an "average user".

> who will notice and who cares?

No one will notice the CPU usage.  Who will notice a laptop battery lasting an extra 30 minutes?  Pretty much any laptop user.

> And here is another thought: why don't we add a switch at about:config?

You mean like "dom.min_background_timeout_value"?  Good thing I can predict the future!
Actually I filed this bug that led me here
https://bugzilla.mozilla.org/show_bug.cgi?id=653664
When I play a flash video on Fx, the CPU usage is often 3 times higher than IE, but I still choose Fx mainly because of certain addons, what the hack,as long as it can properly function, but if not, that when I seek alternatives.

> You mean like "dom.min_background_timeout_value"?
What I meant was more like "dom.min_background_timeout_clamping" or something, only have two options: off and on.
> When I play a flash video on Fx, the CPU usage is often 3 times higher than IE

That's a bug, sure.

> only have two options: off and on.

You can get the same effect by just setting the background and foreground clamps to the same value, whatever value you prefer.
> You can get the same effect by just setting the background and foreground
> clamps to the same value, whatever value you prefer.

You mean you are actually planning on adding "dom.min_background_timeout_value"? that's wonderful, thanks.
I thought "Good thing I can predict the future!" was sarcastic, sorry I took it wrong.
(In reply to comment #30)
> > You can get the same effect by just setting the background and foreground
> > clamps to the same value, whatever value you prefer.
> 
> You mean you are actually planning on adding
> "dom.min_background_timeout_value"? that's wonderful, thanks.
> I thought "Good thing I can predict the future!" was sarcastic, sorry I took it
> wrong.

He means he already did. With the original feature.
> He means he already did. With the original feature.
Then problem has already solved, what are we arguing about? since "setting the background and foreground clamps to the same value" equals "turning it off".
Well, the question of default values is still open.
I believe that I have just run into a use case on a popular website, slashdot, where the experience is now sort of broken.

Slashdot uses some mechanism to prevent a user from commenting a second time immediately after submitting a first comment. 

I opened a reply comment in a new tab, commented and hit submit. I went back to my original tab (leaving that submitted comment page in a background tab) and read the rest of the comments for about 4 or 5 minutes. I attempted to submit a second reply but when I submitted my comment, slashdot said it had only been 18 seconds and blocked that comment from going through. I know it had been considerably longer than that and so I'm guessing it could be a result of this change. 

I haven't done any code inspection at slashdot (wouldn't know how) to see if that's what they're doing, so maybe I'm wrong but noting it here just in case I'm right.
>Well, the question of default values is still open.
Whatever you see fit, important thing is when "average users" encounter this problem, there is a solution.
Asa, was Slashdot complaining that it was only 18 seconds since you hit reply, or that it was only 18 seconds since you last commented?
Well, I can't reproduce any more so maybe I'm wrong. I looked at the code on a comment page before and after posting and there's a lot of js date stuff but only one settimeout that looks tied to the ad platform. I'm guessing that slashdot isn't affected here after all. Sorry for the confusion.
currently known to be affected: fileserve.com, bitshare.com, freakshare.com
General data:

freakshare.com uses a 100ms interval and waits for it to fire 600 times.

fileserve.com uses a nested 100ms timeout and waits 350 times (well, the exact wait is configurable, but it's 350 in the link in bug 653664).

I can't find a useful link to bitshare.com.

So one option would be to lower the background tab clamp to 100ms if we decide this is a really serious problem.
(In reply to comment #39)
> I can't find a useful link to bitshare.com.

http://bitshare.com/files/5uy1ygt6/Busty_Blonde_Private_Sex_Casting.rar.html

It uses a 100ms interval.
Case in point about ShareThis: bug 654399.
(In reply to comment #39)
> General data:
> 
> freakshare.com uses a 100ms interval and waits for it to fire 600 times.
> 
> fileserve.com uses a nested 100ms timeout and waits 350 times (well, the
> exact wait is configurable, but it's 350 in the link in bug 653664).
> 
> I can't find a useful link to bitshare.com.
> 
> So one option would be to lower the background tab clamp to 100ms if we
> decide this is a really serious problem.

Did the current (1000ms?) clamping come from anywhere in particular? Would we still get most of the win if we dropped it to 100ms, or even, say, 250ms so that we reduce the bustage?
> Did the current (1000ms?) clamping come from anywhere in particular?

My initial gut feeling was to go with 500ms, but then I switched it to 1000ms because that's what Chrome was doing and we might as well be compatible.  1000ms is also the refresh driver clamp we shipped with in Firefox 4, though that's not quite directly relevant here.

The 500ms number was just a swag, as I said.  The _ideal_ number, from a CPU usage and power consumption point of view, is infinite.  We just didn't want to do that because of site compat concerns where sites really do expect the timer to fire eventually.

> Would we still get most of the win if we dropped it to 100ms, or even, say,
> 250ms so that we reduce the bustage?

We'd probably get idle CPU usage into the several percent (instead of 30%) range, yes.  In the common case (i.e. everything except these filesharing sites as far as we can tell) we'd still be running a bunch of unnecessary script and using more CPU than we should, but maybe that's just a hit we have to take.  :(

Alon, what's the wakeup story on mobile here?  What would the 100ms or 250ms numbers look like for you there?
(In reply to comment #43)
> Alon, what's the wakeup story on mobile here?  What would the 100ms or 250ms
> numbers look like for you there?

Every single wakeup on mobile is painful. 100ms is very bad.

But this isn't just an issue for mobile, the exact same thing is relevant when using a laptop on its battery. It's less noticeable on laptops (which have lots of other needless timers running, unlike a phone), but it is. And it's even an issue on desktops, not for battery life but for cutting down on unneeded consumption, on hundreds of millions of machines things adds up.

I thought the decision to go with 1000ms, and to do the same as Chrome, was great, and I still think it's the best thing to do here. The affected websites are probably visited by non-average users, which are likely to use Firefox or Chrome, so making a stand exactly there is a good thing. We shouldn't dramatically decrease power efficiency across the board just for a few faulty websites, the websites should fix their bugs. (Yes, I realize they are motivated to do exactly the opposite here.)

But if Chrome relents and switches to 250ms or 100ms, then I don't know. We don't want to start having a competition to support faulty websites, where users seek out the browsers that compromise the most. It's best to have a unified front. For which reason I'd argue that keeping 1000ms is the right thing to do - we shouldn't be the party to break that front. (But if Chrome does, maybe we need to reconsider.)

In any case, as a workaround for non-average users, opening a new *window* with the relevant website in it would work, I think? (It'll never be considered a background tab then.) Perhaps an addon could be made for this sort of thing.
> opening a new *window* with the relevant website in it would work, I think? 

Yes.
> The affected
> websites are probably visited by non-average users, which are likely to use
> Firefox or Chrome, so making a stand exactly there is a good thing.

I don't see what this assumption is based on. These sites are linked to from all over the internet, they're essentially just places to upload random files to when you don't capable web space.

> We
> shouldn't dramatically decrease power efficiency across the board just for a
> few faulty websites, the websites should fix their bugs. (Yes, I realize
> they are motivated to do exactly the opposite here.)

See above, they weren't faulty until we changed the behavior under their feet. And as we've come to realize, blaming them probably wouldn't help our users anyway, so we can stop doing that. Who's fault it is is purely hypothetical at this point.
We've got a list of several sharing sites here. Can someone just email the webmasters at those sites and ask them to replace their current implementation with something better? Maybe we can even get someone from the tech evangelism team to whip up a simple countdown script that they can copy and paste?
  function doCountDown(desiredDelay) {
    var targetTime = new Date() + desiredDelay;
    var interval = setInterval(function() {
      var now = new Date();
      if (now >= targetTime) {
        clearInterval(interval);
        // Enable whatever download ui needs enabling or start the download
      } else {
        // Update the time remaining counter to show (targetTime - now) ms, in
        // whatever format you want.
      }
    }, 100);
  }
If I agree to locate the contacts at these websites and email with them about this alternative approach (and to do so for any other sites that show up in this bug report) can we set the "best" value we can think of here and move on?
We should mail them no matter what.  I really do think the value we set now is good; if we can get these sites updated, that would be wonderful.
A layman's question: am I to understand that any site showing countdown by tenths (or hundredths)of a second will have this problem? Actually it looks more "accurate" and fancy, you can't blame them for doing that. 
Is it possible to add something like "capability.policy.noscript.sites" "capability.policy.noscript.javascript.enabled" for an addon to work on, or is there a better way to add a whitelist?
(In reply to comment #51)
> A layman's question: am I to understand that any site showing countdown by
> tenths (or hundredths)of a second will have this problem?

No. If you use Date() and so forth to tell the time, you can get accurate countdowns down to milliseconds.

The problem is a website that requests a repeating timer to happen each X milliseconds, and expect that to actually happen like clockwork. Even without the throttling of background tabs, that is *not* likely to be a precise way to check for the passage of time, there is always noise there.
status-firefox5: --- → affected
Version: 5 Branch → Trunk
Thanks for the explanation, good to know.
I have contacted all three filesharing sites inolved (interestingly, bitshare and freakshare have contact forms that are identical, down to the grammar errors, except for the different captcha mechanisms and different stylesheets).

If anyone here is actually a paying customer (or heck, a customer of any kind) of any of those sites, I strongly urge you to contact them as well.
Actually paying customers don't have to wait, that's what you are paying for, that's why they might be reluctant to change.
Whiteboard: comment #50 should be the end of this
> currently known to be affected: fileserve.com, bitshare.com, freakshare.com

another user mentions "filesonic, netload, tuenti"
For what it's worth at least bitshare.com is looking into fixing this.

I'd be interested in knowing what the steps are to reproduce this with filesonic, netload, and tuenti... All seem to require a login to do anything.
I found a file hosted on filesonic, but it doesn't seem to be affected.

netload: http://netload.in/dateijCDV1fBZeh.htm

tuenti claims to be invitation-only and I couldn't find a public link to a file.
(In reply to comment #58)
> I found a file hosted on filesonic, but it doesn't seem to be affected.
> 
> netload: http://netload.in/dateijCDV1fBZeh.htm
> 
> tuenti claims to be invitation-only and I couldn't find a public link to a
> file.

Tuenti is a social network, like Facebook is. When the page is loading appears a progress bar, and due to this bug, when you change the active tab that progress is interrupted. The progress bar is visually similar to gmail. 
The problem is that Tuenti is a private social network and you need an invitation.
(In reply to comment #60)
> > tuenti claims to be invitation-only and I couldn't find a public link to a
> > file.

Can someone here help us find contact information for Tuenti so that we can notify them about our change and how they can fix their code?
(In reply to comment #61)
> (In reply to comment #60)
> > > tuenti claims to be invitation-only and I couldn't find a public link to a
> > > file.
> 
> Can someone here help us find contact information for Tuenti so that we can
> notify them about our change and how they can fix their code?

I can help. You can talk with tuenti developers sending a message with the option "press" in the page, in Spanish "prensa", but you can change the language.
Or you can probably talk with the crator of Tuenti in his twitter http://twitter.com/#!/zaryn
We won't be doing anything in our product for this, and it sounds like this is something that's resolving itself on the web, and that's what everyone wants. Marking this WONTFIX.
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: relnote
Resolution: --- → WONTFIX
Assignee: nobody → english-us
Status: RESOLVED → REOPENED
Component: DOM → English US
Product: Core → Tech Evangelism
QA Contact: general → english-us
Resolution: WONTFIX → ---
Version: Trunk → unspecified
Does slowing down ~2x at Google Guitar (e.g. http://www.google.com/webhp?hl=en&tune=IBBQIQkgVFCOUEIQRSjlEqEEEo4RCgFFKEESoBQQhFAqOEQJApQSjhEqGEIVBQISkgVFCOUEIRSCiQhEqEQUw4wCUkChCYBUUIRQShhEJKUMIlRAgjCKQUSEJIFRQjlHGIEAgJhKkRFBCJUgYoIRKkhFBKJEhIYFRAjlCGMIhggA) concern this bug? It happens when I play some melody and then switch to another tab.
so we should not update and stay with FF 4, cause this bug will from now on be a part of FF ?
(In reply to comment #65)
> so we should not update and stay with FF 4, cause this bug will from now on
> be a part of FF ?

Just wanted to make sure you saw the simple workaround mentioned above - opening these sites in a window as opposed to a tab.
> Does slowing down ~2x at Google Guitar

There seem to be some 500ms timeouts there, so it's possible, yes.
Several people have complained about not being able to load tuenti.com tabs in the background in Fx5: http://www.mozilla-hispano.org/foro/viewtopic.php?f=2&t=11381&start=10

I also found at least a couple of complaints in input.m.c related to this issue.

The guys at #mozilla-hispano say that some people have stopped using Fx in favor of Chrome where it does work.

How can we reach out to tuenti.com to see if they could do something about this?
juan, Chrome has the same behavior as us here.  So whatever is being reported about tuenti.com there is probably unrelated to this bug, unless they're running different code in Chrome and Gecko.
Yep, I see the same behavior while using Chrome. Either way, tuenti.com users have less than an ideal experience. Hopefully they can fix it.
> How can we reach out to tuenti.com to see if they could do something about this?

See comment 62.
(cc'ing Guillermo, who is a Tuenti.com developer)
We will look into it.
We have been informed that setting dom.min_background_timeout to 4 solves the problem. I can confirm that inactive tabs countdown scripts don't hang any more.

I hope this information helps.
thx for the infomation
Keywords: relnote
Is it still an issue?
Assignee: english-us → nobody
Component: English US → Desktop
It has been fixed.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 8 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.