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)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jruderman, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
1.35 KB,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 2•19 years ago
|
||
I assume it would be for everyone (including Greasemonkey scripts and web pages), like other JavaScript strict warnings.
Updated•19 years ago
|
Keywords: helpwanted
Comment 3•17 years ago
|
||
Not sure how to do this as a strict-mode only warning.
Updated•17 years ago
|
Attachment #262204 -
Flags: review? → review?(jst)
Updated•17 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
Reporter | ||
Updated•17 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)
Reporter | ||
Comment 4•17 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 mozilla.org/setTimeout/."
Comment 5•17 years ago
|
||
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•17 years ago
|
||
How do I determine within this code whether or not the calling code is running in strict mode or not?
Comment 7•17 years ago
|
||
Try grepping for STRICT in js*.c and go from there? /be
Comment 8•17 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•17 years ago
|
||
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)
Comment 10•17 years ago
|
||
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
Comment 11•17 years ago
|
||
Dropping off my list until more info arrives.
Assignee: crowder → general
Status: ASSIGNED → NEW
Comment 12•16 years ago
|
||
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
Comment 13•16 years ago
|
||
Yeah, fine with me as well.
You need to log in
before you can comment on or make changes to this bug.
Description
•