Eager stack trace for error objects.
https://bugs.webkit.org/show_bug.cgi?id=118918

Source/JavaScriptCore:

Patch by Chris Curtis <chris_curtis@apple.com> on 2013-07-29
Reviewed by Geoffrey Garen.

Chrome and Firefox give error objects the stack property and we wanted to match
that functionality. This allows developers to see the stack without throwing an object.

* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
 For error objects that are not thrown as an exception, we pass the stackTrace in
 as a parameter. This allows the error object to have the stack property.

* interpreter/Interpreter.cpp:
(JSC::stackTraceAsString):
Helper function used to eliminate duplicate code.

(JSC::Interpreter::addStackTraceIfNecessary):
When an error object is created by the user the vm->exceptionStack is not set.
If the user throws this error object later the stack that is in the error object
may not be the correct stack for the throw, so when we set the vm->exception stack,
the stack property on the error object is set as well.

* runtime/ErrorConstructor.cpp:
(JSC::constructWithErrorConstructor):
(JSC::callErrorConstructor):
* runtime/NativeErrorConstructor.cpp:
(JSC::constructWithNativeErrorConstructor):
(JSC::callNativeErrorConstructor):
These functions indicate that the user created an error object. For all error objects
that the user explicitly creates, the topCallFrame is at a new frame created to
handle the user's call. In this case though, the error object needs the caller's
frame to create the stack trace correctly.

* interpreter/Interpreter.h:
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):

LayoutTests:

Patch by Chris Curtis <chris_curtis@apple.com> on 2013-07-29
Reviewed by Geoffrey Garen.

Added tests to ensure that the stack property was present at creation for all
error Objects. This test will fail without this patch.

* fast/js/script-tests/stack-at-creation-for-error-objects.js: Added.
(checkStack):
* fast/js/stack-at-creation-for-error-objects-expected.txt: Added.
* fast/js/stack-at-creation-for-error-objects.html: Added.

* inspector/console/console-format-expected.txt:
* inspector/console/console-format.html:
This test was modified by removing the error object from being evaluated. Prior to this patch
error objects did not have the stack property, so the stack information was not being
displayed. The stack trace includes a file path specific to the machine that is running
the test. The results would have differed from one computer to the next. There
is not an easy way to capture the error object to treat it differently. By removing
the error object there is no need to add extra code to treat it differently.
Also there are other tests inside inspector/console that test the  stack trace,
so the testing suite does not lose error testing by removing it.

The .stack property was added to the error objects at creation time.
* fast/js/exception-properties-expected.txt:
* fast/js/script-tests/exception-properties.js:

The column numbers are modified in the following test. When error objects are explicitly
invoked, the column number points to the beginning "(" instead of end ")".
Functionality between browsers do not match either. Firefox does not output column
numbers. Chrome points columns numbers to the beginning of the "new" call.

* fast/js/line-column-numbers-expected.txt:
* fast/js/stack-trace-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153457 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[wk2] Flush the WebProcess’ implicit transaction when using endDeferringViewInWindowChangesSync
https://bugs.webkit.org/show_bug.cgi?id=119225
<rdar://problem/14568841>

Reviewed by Simon Fraser.

Tell CoreAnimation to flush the implicit transaction before replying
when using endDeferringViewInWindowChangesSync, as that method's contract
is that the WebProcess is totally ready to be in-window when it returns.

* UIProcess/API/mac/WKView.mm:
(-[WKView endDeferringViewInWindowChanges]):
Adopt viewInWindowStateDidChange.

(-[WKView endDeferringViewInWindowChangesSync]):
Adopt viewInWindowStateDidChange, asking it to send a reply only if we're going to wait for one.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::viewInWindowStateDidChange):
(WebKit::WebPageProxy::viewStateDidChange):
Pull viewInWindowStateDidChange out of viewStateDidChange.
Request a reply from SetIsInWindow if we're told to.

* UIProcess/WebPageProxy.h: Add WantsReplyOrNot and viewInWindowStateDidChange.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didUpdateInWindowStateTimerFired):
Don't build this version on Mac, we'll have a WebPageMac version.

(WebKit::WebPage::setIsInWindow):
Only start the timer to send the didUpdateInWindowState reply if we're asked to.

* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in:
Add an argument to the SetIsInWindow message for whether the WebProcess
should inform the UIProcess when SetIsInWindow completes or not.

* WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::didUpdateInWindowStateTimerFired):
Tell CA to flush the implicit transaction before telling the UIProcess that
we're finished moving in-window.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153458 268f45cc-cd09-0410-ab3c-d52691b4dbfc