W3C home > Mailing lists > Public > public-web-security@w3.org > March 2011

Re: setTimeout error handling

From: Brandon Sterne <bsterne@mozilla.com>
Date: Tue, 29 Mar 2011 14:35:00 -0700
Message-ID: <4D925084.40506@mozilla.com>
To: Adam Barth <w3c@adambarth.com>
CC: public-web-security@w3.org
I think returning a null handle and logging to the error console is an
excellent proposal and I've added it to the issue tracker.


On 03/28/2011 02:06 PM, Adam Barth wrote:
> Sorry for spamming the list with lots of questions.  I'm just emailing
> questions as they come up in the implementation.
> [[
> User-agents must prevent strings from being converted to ECMAScript
> code, including calls to:
> eval()
> new Function() constructor
> setTimeout() called with a String argument
> setInterval() called with a String argument
> ]]
> Suppose the page does call setTimeout with a string.  How should the
> user agent handle the error?
> For example, in Step 6 of
> http://www.whatwg.org/specs/web-apps/current-work/#dom-windowtimers-settimeout,
> the user agent is instructed to "Return handle".  Should that step
> occur or should we return a null handle?  Should setTimeout throw an
> exception?
> There are similar questions for the other functions that convert
> strings to code.
> Also, what about non-ECMAScript code?  For example, if the user agent
> supported VBScript as a scripting language (e.g., Internet Explorer),
> should the user agent prevent strings from being turned into that sort
> of code?
> Proposal: We should return a null handle from setTimeout and
> setInterval.  That lets the page detect the error would being so
> drastic as to throw an exception.  We could also log to the error
> console (and of course report via the reporting-uri) to make the error
> more visible to developers.
> Adam
Received on Tuesday, 29 March 2011 21:32:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC