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)
Web Compatibility
Site Reports
Tracking
(firefox5+ wontfix)
RESOLVED
FIXED
People
(Reporter: dao, Unassigned)
References
()
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.
Reporter | ||
Updated•14 years ago
|
Version: Trunk → 5 Branch
![]() |
||
Comment 1•14 years ago
|
||
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...
Comment 3•14 years ago
|
||
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.
Reporter | ||
Updated•14 years ago
|
Summary: Higher setTimeout/setInterval clamping in inactive tabs breaks countdown script → Higher setTimeout/setInterval clamping in inactive tabs breaks countdown scripts
Comment 7•14 years ago
|
||
no top sites concerning us yet. also sites will have to modify not just for us but chrome as well.
Reporter | ||
Comment 8•14 years ago
|
||
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.
![]() |
||
Comment 9•14 years ago
|
||
> 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.
Reporter | ||
Comment 10•14 years ago
|
||
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.
![]() |
||
Comment 11•14 years ago
|
||
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.
Reporter | ||
Comment 12•14 years 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.
![]() |
||
Comment 13•14 years ago
|
||
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.
Reporter | ||
Comment 14•14 years ago
|
||
(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.
Reporter | ||
Comment 15•14 years ago
|
||
(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.
![]() |
||
Comment 16•14 years ago
|
||
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.
Reporter | ||
Comment 17•14 years ago
|
||
(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.
![]() |
||
Comment 18•14 years ago
|
||
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...
Reporter | ||
Comment 19•14 years ago
|
||
(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, ...?
![]() |
||
Comment 20•14 years ago
|
||
Both. What it does is effectively turn off various animations, tickers, etc in background tabs. This is a particularly big deal on mobile, obviously.
Reporter | ||
Comment 21•14 years ago
|
||
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.
![]() |
||
Comment 22•14 years ago
|
||
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...
![]() |
||
Comment 24•14 years ago
|
||
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...
Comment 25•14 years ago
|
||
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.)
Comment 26•14 years ago
|
||
(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.
![]() |
||
Comment 27•14 years ago
|
||
> 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!
Comment 28•14 years ago
|
||
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.
![]() |
||
Comment 29•14 years ago
|
||
> 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.
Comment 30•14 years ago
|
||
> 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.
Comment 31•14 years ago
|
||
(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.
Comment 32•14 years ago
|
||
> 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".
Comment 34•14 years ago
|
||
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.
Comment 35•14 years ago
|
||
>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.
![]() |
||
Comment 36•14 years ago
|
||
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?
Comment 37•14 years ago
|
||
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.
Reporter | ||
Comment 38•14 years ago
|
||
currently known to be affected: fileserve.com, bitshare.com, freakshare.com
![]() |
||
Comment 39•14 years ago
|
||
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.
Reporter | ||
Comment 40•14 years ago
|
||
(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.
Comment 42•14 years ago
|
||
(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?
![]() |
||
Comment 43•14 years ago
|
||
> 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?
Comment 44•14 years ago
|
||
(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.
![]() |
||
Comment 45•14 years ago
|
||
> opening a new *window* with the relevant website in it would work, I think?
Yes.
Reporter | ||
Comment 46•14 years ago
|
||
> 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.
Comment 47•14 years ago
|
||
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?
![]() |
||
Comment 48•14 years ago
|
||
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); }
Comment 49•14 years ago
|
||
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?
![]() |
||
Comment 50•14 years ago
|
||
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.
Comment 51•14 years ago
|
||
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?
Comment 52•14 years ago
|
||
(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.
![]() |
||
Updated•14 years ago
|
status-firefox5:
--- → affected
Version: 5 Branch → Trunk
![]() |
||
Comment 54•14 years ago
|
||
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.
Comment 55•14 years ago
|
||
Actually paying customers don't have to wait, that's what you are paying for, that's why they might be reluctant to change.
Updated•14 years ago
|
Whiteboard: comment #50 should be the end of this
Reporter | ||
Comment 56•14 years ago
|
||
> currently known to be affected: fileserve.com, bitshare.com, freakshare.com
another user mentions "filesonic, netload, tuenti"
![]() |
||
Comment 57•14 years ago
|
||
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.
Reporter | ||
Comment 58•14 years ago
|
||
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.
Comment 60•14 years ago
|
||
(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.
Comment 61•14 years ago
|
||
(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?
Comment 62•14 years ago
|
||
(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
Updated•13 years ago
|
Comment 63•13 years ago
|
||
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.
Reporter | ||
Updated•13 years ago
|
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
Comment 64•13 years ago
|
||
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.
Comment 65•13 years ago
|
||
so we should not update and stay with FF 4, cause this bug will from now on be a part of FF ?
Comment 66•13 years ago
|
||
(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.
![]() |
||
Comment 67•13 years ago
|
||
> Does slowing down ~2x at Google Guitar
There seem to be some 500ms timeouts there, so it's possible, yes.
Comment 68•13 years ago
|
||
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?
![]() |
||
Comment 69•13 years ago
|
||
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.
Comment 70•13 years ago
|
||
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.
![]() |
||
Comment 71•13 years ago
|
||
> How can we reach out to tuenti.com to see if they could do something about this? See comment 62.
Comment 74•13 years ago
|
||
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.
![]() |
||
Comment 76•10 years ago
|
||
Is it still an issue?
Assignee: english-us → nobody
Component: English US → Desktop
![]() |
||
Comment 77•8 years ago
|
||
It has been fixed.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 8 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•