On Sat, Mar 19, 2011 at 5:21 PM, Kyle Simpson <get...@gmail.com> wrote:
> * No clamping. Time runs as fast as the platform lets it run.
>>>> * The return value is not an integer but a unique unforgeable object for
>>>> canceling the event. No one without
>>>> that object can cancel that event.
>>>>
>>>
>>> This last point is something I was about to raise when starting to think
>>> about extending the Q API.
>>> setTimeout returns a number, so a malicious could loop through numbers
>>> and call clearTimeout on them. An
>>> unforgeable object sounds like the correct response to this issue. Have
>>> you considered wrapping
>>> setTimeout&friends in SES with this solution? It wouldn't break code
>>> which do not rely on the returned value
>>> being a number (but would break code which does, of course).
>>>
>>
>> Caja does exactly this. So far we haven't found any code that this
>> actually breaks. All uses we've encountered[1]
>> treat the return value of setTimeout/setInterval as simply something they
>> can remember and later pass to
>> clearTimeout/clearInterval.
>>
>> [1] That I'm aware of. Caja users should speak up if they've hit a
>> counter-example. Or anyone else that has seen
>> code in the wild that actually counts on these values being numbers.
>>
>
> I have a number of different projects where I've used timers (mostly
> intervals rather than timeouts), where the logic that I used relied on being
> able to tell if a value was falsy or not, to know if there's a timer
> attached to some variable (so that you only set the interval once, and not
> multiple times).
>
> So, for instance, a variable like foo = false`, when an interval is set,
> `foo = setInterval(...)`, and when that interval is cleared, I not only call
> `clearInterval(foo)` but I also call `foo = false` again to signal that the
> interval has been cleared (there is no `checkInterval(foo)` API to check
> this). Then, the next time I want to set the interval, I first check to see
> if `foo` is truthy or falsy, and only set if it's indeed falsy. So, all this
> is to say, I rely in those tests on whether the value is truthy or falsy.
> Not exactly relying on its data type, but it's important not to assume that
> noone ever checks those values -- in many cases, I do.
>
Hi Kyle, you're correct that this example is sufficiently close to be
worrisome. It is also at least amusing to note that switching to opaque
token objects would not break such code, since these tokens are truthy.
>
>
>
> --Kyle
>
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
