On 08/08/2013, at 15:55, David Bruant wrote: > This is not a "Trying to protect us from ourselves" situation. This is a > "browser trying to protect users from any sort of abuse" situation. For while > loops, they implemented the "script takes too long" dialog. For mistakenly > infinitely nested too short setTimeouts, they implemented 4ms clamping. > If browsers can't have mitigation strategies when features are abused, we > will run in the same situations than before. > > As a JS dev, I want the same features than you. Now, how do browsers make > sure this doesn't drain users battery in case of misuse? (I don't have an > answer yet)
I think that it can't be avoided. A program, in the middle a longish operation, *must* yield to the event loop to avoid events starvation and/or to force redraws, so there *must* be a way to do so, and it *must* be *fast* (without 4ms clampings). Yes, there are malicious sites and there are silly programmers to drain your batteries, but there are also 100% legit reasons to spin the event loop... I would put in the browsers a cpu hog/battery drain dial/indicator per page, so that the users could at least see it and act accordingly (they'll soon learn why that's important). I for one have already uninstalled lots of iPhone apps, just because they drained my batteries too fast. Also, the original "classic" MacOS had an EventAvail() call to let the program know if there were any events pending, in a program in a busy loop this helps decide whether it's time to yield or not. -- ( Jorge )(); _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
