83267 2012-04-05 04:48:02 -0700 Web Inspector: [JSC] "SyntaxError: 'with' statements are not valid in strict mode" when debugging strict mode script 2013-03-21 15:03:53 -0700 1 1 1 Unclassified WebKit Web Inspector (Deprecated) 528+ (Nightly build) Mac (Intel) OS X 10.6 RESOLVED DUPLICATE 65829 InRadar P2 Normal --- 0 matt.cg webkit-unassigned apavlov bweinstein gavin joepeck keishi loislo mark.lam oliver o.smestad pfeldman pmuellr pom rik spam timothy yeecheng.chin+webkit yurys oldest_to_newest 596480 0 matt.cg 2012-04-05 04:48:02 -0700 Steps to reproduce: 1) Write a script with the "strict mode" flag at the top 2) Insert a breakpoint in your script and run something that will trigger a pause on that breakpoint 3) Open the console and attempt to evaluate something while execution is paused e.g. type 'this' and hit enter What should happen: The entered script should be evaluated. What happens instead: A SyntaxError with the message "'with' statements are not valid in strict mode" is thrown. 605004 1 timothy 2012-04-18 12:55:07 -0700 <rdar://problem/11271238> 678161 2 gavin 2012-07-25 09:48:11 -0700 If there is a Radar bug for this, is it safe to say that the status is confirmed? This is a really bad problem, especially when attempting to debug new problems introduced specifically by Safari 6.0: http://meta.stackoverflow.com/questions/134611/safari-is-asking-if-i-want-to-leave-the-page-when-saving-my-edits 742232 3 timothy 2012-10-15 11:43:23 -0700 *** Bug 99305 has been marked as a duplicate of this bug. *** 742936 4 yurys 2012-10-16 01:18:55 -0700 Works fine in tip of tree Chromium and 23.0.1271.26 (Official Build 160934) beta. 745121 5 yeecheng.chin+webkit 2012-10-18 03:18:13 -0700 Hi, is there a reason this bug is still unconfirmed, let alone fixed? It's a pretty simple, very easy to reproduce bug, and significantly discourages developers from developing strict mode code on Safari. Basically in the inspector console, there's a hidden object "window.console._commandLineAPI" that provides some console functionality like "$", "clear" etc. There's a function called evaluateOnCallFrame (defined in InjectedScriptSource.js) that the console tries to call to wrap whatever code it's calling in a with statement to wrap around the command line api object so those functions appear on the global scope. The with statement is obviously not legal in strict mode hence the exception. I took at look at Chrome and couldn't figure out what they are doing differently but running code in console under strict mode does work, unlike Safari. My suggestion is either: 1) Don't execute code under strict mode when in the inspector console. This is a one line fix in DebuggerCallFrame::evaluate. Basically instead of passing along the intended strict mode setting, just pass false to EvalExecutable::create. This is kind of a hack as the console won't be giving you the correct results (e.g. error when you try to call arguments.callee), but at least the console will work! 2) Find some better ways to wrap the command line API. I'm not sure what Chrome does, but maybe we do can something like the following instead of using a with statement to wrap? (function() { var $ = window.console._commandLineAPI.$; var $$ = window.console._commandLineAPI.$$; var clear = window.console._commandLineAPI.clear; ... // The actual code the console is trying to run // This has an issue of masking out the global variables and other stack variables but there are ways to get around that )(); Either way I think it's better to get something working than the console being plain broken under strict mode! 787193 6 o.smestad 2012-12-10 04:24:51 -0800 This seems to be a duplicate of: https://bugs.webkit.org/show_bug.cgi?id=65829 793978 7 spam 2012-12-18 13:16:19 -0800 How is this still not fixed? It appears to be a duplicate of: https://bugs.webkit.org/show_bug.cgi?id=65829 that dates back to over a year ago. I cannot debug anything in Safari as a result of this bug. It's embarrassing. Can we please prioritize this? 860759 8 timothy 2013-03-21 15:03:53 -0700 *** This bug has been marked as a duplicate of bug 65829 ***