In WebKit Nightly Version 5.0.6 (5533.22.3, r92569), open the attachment and follow the instructions.
The next attachment will show what I see when I do so.
Created attachment 103184[details]
Load and follow instructions to see JavaScript console bug
This attachment didn't take the first time, so adding it now.
Created attachment 103185[details]
What I see when I follow the instructions on previous attachment
This screenshot seems to demonstrate that, when the JavaScript console is in a strict context and tries to evaluate an expression, it first surrounds the expression with a "with" statement and then tries to evaluate the resulting string in a strict context. This of course cannot work, since "with" is illegal in strict mode.
Confirmed that this bug is still occuring in the latest version of Safari (Version 5.1.3 (7534.53.10)) and in the latest Webkit Nightly build (r108593).
Comment on attachment 194361[details]
Proposed Change
View in context: https://bugs.webkit.org/attachment.cgi?id=194361&action=review
r=me
> Source/WebCore/ChangeLog:14
> + console to stay in strict mode. This also allows users to opt-into strict mode by prefixing
s/stay in/stay out of/ -- we're evaluating inside a strict mode function, but then injecting a non-strict function.
Comment on attachment 194361[details]
Proposed Change
View in context: https://bugs.webkit.org/attachment.cgi?id=194361&action=review> Source/WebCore/inspector/InjectedScriptSource.js:584
> var result = evalFunction.call(object, expression);
I think we should surround this case in an empty function expression. That way, the behavior of things like "var" won't change.
Created attachment 194368[details]
Archive of layout-test-results from webkit-ews-11
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: <class 'webkitpy.common.config.ports.MacWK2Port'> Platform: Mac OS X 10.8.2
Created attachment 194373[details]
Archive of layout-test-results from gce-cr-linux-06
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-06 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-3.3.8-gcg-201212281604-x86_64-with-GCEL-10.04-gcel_10.04
Created attachment 194454[details]
Archive of layout-test-results from webkit-ews-04
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04 Port: <class 'webkitpy.common.config.ports.MacPort'> Platform: Mac OS X 10.8.2
Created attachment 194725[details]
Archive of layout-test-results from gce-cr-linux-02 for chromium-linux-x86_64
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-02 Port: chromium-linux-x86_64 Platform: Linux-3.3.8-gcg-201212281604-x86_64-with-GCEL-10.04-gcel_10.04
Created attachment 194733[details]
Archive of layout-test-results from webkit-ews-05 for mac-future
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-future Platform: Mac OS X 10.8.2
Created attachment 194734[details]
Archive of layout-test-results from webkit-ews-09 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-09 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.2
Comment on attachment 194752[details]
Proposed Change (Take 4)
View in context: https://bugs.webkit.org/attachment.cgi?id=194752&action=review> Source/WebCore/inspector/InjectedScriptHost.h:109
> + bool evaluateReturnsEvalFunction() { return true; }
So far we were hiding all the differences like this behind Script* boundary. Also, could we instead introduce evaluateFunction getter that v8 will fail to return instead of this boolean flag? That way InjectedScriptSource will be compiler friendly.
(In reply to comment #27)
> (From update of attachment 194752[details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=194752&action=review
>
> > Source/WebCore/inspector/InjectedScriptHost.h:109
> > + bool evaluateReturnsEvalFunction() { return true; }
>
> So far we were hiding all the differences like this behind Script* boundary. Also, could we instead introduce evaluateFunction getter that v8 will fail to return instead of this boolean flag? That way InjectedScriptSource will be compiler friendly.
How is this not patch not compiler friendly?
I considered exposing evaluateFunction. But I didn't want both evaluate and evaluateFunction in the JSC path. We want to have only one way to evaluate.
Created attachment 195019[details]
The bug still happens on the latest Nightly (part 1)
I see that this bug is closed. But the attached screenshot shows that the latest Nightly still suffers from this bug.
Created attachment 195138[details]
Screenshot showing that the bug isn't fixed -- Part 1
(In reply to comment #34)
> WebKit r146855 was built on 26 March 2013 and is a 47.4 MB download.
>
> Give it a try now.
I just updated to the latest Nightly, which self-identifies as r146901 and 6.0.3 (8536.28.10, 537+). Attached is the first screenshot demonstrating that the bug still isn't fixed, but manifests differently. Second screenshot in next attachment
2011-08-07 13:31 PDT, Mark S. Miller
2011-08-07 13:34 PDT, Mark S. Miller
2011-08-07 13:42 PDT, Mark S. Miller
2012-02-23 11:16 PST, David Baumgold
2013-03-21 15:17 PDT, Timothy Hatcher
buildbot: commit-queue-
2013-03-21 15:57 PDT, Build Bot
2013-03-21 16:11 PDT, WebKit Review Bot
2013-03-21 23:39 PDT, Build Bot
2013-03-23 14:32 PDT, Timothy Hatcher
2013-03-23 18:16 PDT, WebKit Review Bot
2013-03-23 18:26 PDT, Timothy Hatcher
2013-03-23 21:11 PDT, Build Bot
2013-03-23 21:21 PDT, Build Bot
2013-03-24 08:00 PDT, Timothy Hatcher
2013-03-26 00:09 PDT, Mark S. Miller
2013-03-26 00:10 PDT, Mark S. Miller
2013-03-26 12:15 PDT, Mark S. Miller
2013-03-26 12:16 PDT, Mark S. Miller
2013-03-26 13:48 PDT, Timothy Hatcher
timothy: commit-queue-