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

Re: setTimeout error handling

From: <sird@rckc.at>
Date: Mon, 28 Mar 2011 17:55:42 -0600
Message-ID: <AANLkTin7njKqkRgNc4bkeaX5U0zOSqbCLETbOX7hGCLK@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: public-web-security@w3.org
If this is supposed to take IE quirks into consideration, then
execScript should be added to that list of forbidden functions.

-- Eduardo

On Mon, Mar 28, 2011 at 3:06 PM, Adam Barth <w3c@adambarth.com> 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 Monday, 28 March 2011 23:56:35 UTC

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