Make setTimeout()/setInterval() give a JavaScript strict warning when the first arg is a string (or other non-function object)




DOM: Core & HTML
12 years ago
10 years ago


(Reporter: Jesse Ruderman, Unassigned)


(Blocks: 1 bug)

Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



12 years ago
setTimeout with a string argument is bad style, a little slow, and can and has
lead to security holes.  I think it should be deprecated, starting by making it
a JavaScript strict warning (like for other dangerous scope things) or a
JavaScript console information message (like for document.getSelection()).  This
will help encourage Firefox and extension developers to use the function forms
of setTimeout, which are safer.

Related information:

Comment 1

12 years ago
would this be for chrome only, or for everyone?

Comment 2

12 years ago
I assume it would be for everyone (including Greasemonkey scripts and web
pages), like other JavaScript strict warnings.
Keywords: helpwanted

Comment 3

11 years ago
Created attachment 262204 [details] [diff] [review]
reporting a warning for all but functions in setTimeout and setInterval

Not sure how to do this as a strict-mode only warning.
Assignee: general → crowder
Attachment #262204 - Flags: review?


11 years ago
Attachment #262204 - Flags: review? → review?(jst)


11 years ago
Keywords: helpwanted
Summary: Make setTimeout(string, ...) give a JavaScript strict warning → Make setTimeout()/setInterval() give a JavaScript strict warning on non-function first argument


11 years ago
Summary: Make setTimeout()/setInterval() give a JavaScript strict warning on non-function first argument → Make setTimeout()/setInterval() give a JavaScript strict warning when the first arg is a string (or other non-function object)

Comment 4

11 years ago
I think "are considered dangerous" sounds better than "should be considered dangerous".  "Considered dangerous" might be too strong, though.

It would be great if the error message hinted at the correct syntax, or pointed to a web page describing how to use anonymous functions, closures, and extra arguments to setTimeout (SpiderMonkey only).  Perhaps "It is safer to call setTimeout with a function instead of a string; see"
Generating a normal error in the error console for every time setTimeout or setInterval is called with a string error seems too aggressive to me. There's a *lot* of code out there that does that, be it good or bad. I suspect that would simply flood the error console something horrible (way more so on some pages than others of course, i.e. imagine some sort of animation that's using string arguments to setInterval etc). I'd be ok with making this be a strict warning that's not shown to normal users for now, or if we'd limit these errors to one (or a couple) per page. Or something along those lines.

Comment 6

11 years ago
How do I determine within this code whether or not the calling code is running in strict mode or not?
Try grepping for STRICT in js*.c and go from there?


Comment 8

11 years ago
Non of the reporting functions in the jsapi allow for the strict flag (or any additional flags) to be set on a report, and JS_HAS_STRICT_OPTION and JS_HAS_OPTION are in jscntxt.h, not in jsapi, and I'm still not sure if that tells me anything interesting about the specific script being run when the setTimeout/setInterval DOM call happens at runtime.  Can you be more specific about what I'm grepping for, Brendan?

Comment 9

11 years ago
Created attachment 262351 [details] [diff] [review]
check cx for JSOPTION_STRICT

Maybe this is correct, but it still seems a little kludgy, and I don't see any other DOM code executing a check like this.
Attachment #262204 - Attachment is obsolete: true
Attachment #262204 - Flags: review?(jst)
JS_GetOptions, yeah. When inside js/src/*, use jscntxt.h. Outside, use jsapi.h.

This is not kludgey, it's optimized to avoid a warning all the time. But I'm with jst: we shouldn't warn more than once per page load. I'm also skeptical of our ability to deprecate anything. We withdrew the nag-strict-warning about with usage after hearing from developers who thought we were tilting at windmills, and at the expense of developers having to wade through console noise.

I think this bug should be WONTFIX. If the strict warning were limited to chrome contexts, perhaps... jst?


Comment 11

11 years ago
Dropping off my list until more info arrives.
Assignee: crowder → general


10 years ago
Blocks: 296661

Comment 12

10 years ago
Given no movement on this in a year, and no more feedback from jst, I'm with Brendan's comment 10.
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
Yeah, fine with me as well.
You need to log in before you can comment on or make changes to this bug.