Closed Bug 302389 Opened 19 years ago Closed 16 years ago

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

Categories

(Core :: DOM: Core & HTML, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jruderman, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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:
http://www.squarefree.com/securitytips/mozilla-developers.html#eval
http://www.mozdev.org/pipermail/greasemonkey/2005-July/004445.html
http://jibbering.com/faq/faq_notes/misc.html#mtSetTI
would this be for chrome only, or for everyone?
I assume it would be for everyone (including Greasemonkey scripts and web
pages), like other JavaScript strict warnings.
Keywords: helpwanted
Not sure how to do this as a strict-mode only warning.
Assignee: general → crowder
Status: NEW → ASSIGNED
Attachment #262204 - Flags: review?
Attachment #262204 - Flags: review? → review?(jst)
Keywords: helpwanted
Summary: Make setTimeout(string, ...) give a JavaScript strict warning → Make setTimeout()/setInterval() give a JavaScript strict warning on non-function first argument
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)
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 mozilla.org/setTimeout/."
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.
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?

/be
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?
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?

/be
Dropping off my list until more info arrives.
Assignee: crowder → general
Status: ASSIGNED → NEW
Blocks: 296661
Given no movement on this in a year, and no more feedback from jst, I'm with Brendan's comment 10.
Status: NEW → RESOLVED
Closed: 16 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.