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 
cleaner way.

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
>> setTimeout.
> 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

David

Le 08/08/2013 16:03, Domenic Denicola a écrit :
> 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 
cleaner way.

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 :-(

> 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.

> 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 :