would this be for chrome only, or for everyone?
12 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.
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?
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.
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.
Given no movement on this in a year, and no more feedback from jst, I'm with Brendan's comment 10.
Yeah, fine with me as well.