bruant.d at gmail.com
Thu Aug 8 07:40:41 PDT 2013
Le 08/08/2013 16:03, Domenic Denicola a écrit :
>> 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)
> To me the answer always seemed obvious: use the slow-script dialog. What am I missing?
For a while loop or just too long running script, this dialog may break
your JS stack *anywhere*, stop at any instruction. It may not be always
easy to recover as it may break all sorts of invariants your code relies on.
It's exactly like OS thread pre-emption. But there is not really a
Let's say a spec requires window.asap to prompt a slow script dialog if
abused. I imagine that all or part of the event queue is flushed (this
needs to be standardized too). This also breaks program invariants in
all sorts of ways.
Let's make guesses. Let's say a browser decides that "script too slow"
dialog is poor UX and that it wouldn't be such a big deal to insert here
and there handling of click events... Suddenly, website X (that abuses
microtasks) runs better on browser Y than Z. This might encourage Z to
break the "microtask contract" as well. Once it's at it, Y, might just
add 4ms clamping because delaying a microtask sounds more friendly than
randomly breaking code invariants.
Small delays between (micro)task sounds like a local maximum it's hard
to get away from unfortunately :-(
>> That's what I suggested ("the implementation keeps track..."), isn't it?
>> Do we disagree?
> I assumed by "implementation" you meant "promise implementation," as in the quoted paragraph. I'd much rather have the browser implementation maintain it.
I meant "browser implementation", sorry for the confusion.
>> I agree and I want "window.asap" asap. But I have the same question about
>> misuse and battery. We need to tell implementors how they mitigate
>> misuses. Otherwise, they'll just fallback to clamping as they did with
> Why are implementers OK with giving us postMessage/MessageChannel but not setImmediate? Why are they OK with giving us MutationObservers/Object.observe but not "`window.asap`"?
I feel we just have to wait until these are abused and we'll see the
clamping solution coming back. Exactly like setImmediate would be forced
to if widely (and eventually mistakenly) used.
Maybe we can add the same feature with a different name every 5 years ? :-)
We need to randomly choose the name so that people don't prolyfill :-p
More information about the es-discuss