Don't need a JSNameScope for the callee name just for the debugger.
<https://webkit.org/b/128024>

Reviewed by Geoffrey Garen.

Currently, in the bytecode for a function, we push a JSNamedScope for
the name of the function when a debugger is attached. The name scope for
the function name is only needed for evals which can redefine the name
to resolve to something else, and can later delete the redefined name
which should revert the resolution of the name to the original function.
The debugger does not need this feature because it declares all new vars
in a temporary nested scope. Hence, we can remove the presence of the
debugger as a criteria for pushing the JSNameScope.

* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::resolveCallee):
(JSC::BytecodeGenerator::addCallee):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163210 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Expose creation and modification times for LocalStorage
https://bugs.webkit.org/show_bug.cgi?id=128018

Reviewed by Anders Carlsson.

Source/WebCore:

* WebCore.exp.in: Export FileSystem functions to get file times.

Source/WebKit2:

* UIProcess/API/C/WKKeyValueStorageManager.cpp:
(WKKeyValueStorageManagerGetOriginKey):
(WKKeyValueStorageManagerGetCreationTimeKey):
(WKKeyValueStorageManagerGetModificationTimeKey):
(WKKeyValueStorageManagerGetStorageDetailsByOrigin):
* UIProcess/API/C/WKKeyValueStorageManager.h:
* UIProcess/Storage/LocalStorageDatabaseTracker.cpp:
(WebKit::LocalStorageDatabaseTracker::origins):
(WebKit::LocalStorageDatabaseTracker::details):
* UIProcess/Storage/LocalStorageDatabaseTracker.h:
* UIProcess/Storage/StorageManager.cpp:
(WebKit::StorageManager::getStorageDetailsByOrigin):
(WebKit::StorageManager::getStorageDetailsByOriginInternal):
* UIProcess/Storage/StorageManager.h:
* UIProcess/WebKeyValueStorageManager.cpp:
(WebKit::WebKeyValueStorageManager::originKey):
(WebKit::WebKeyValueStorageManager::creationTimeKey):
(WebKit::WebKeyValueStorageManager::modificationTimeKey):
(WebKit::didGetKeyValueStorageOrigins):
(WebKit::didGetStorageDetailsByOrigin):
(WebKit::WebKeyValueStorageManager::getStorageDetailsByOrigin):
* UIProcess/WebKeyValueStorageManager.h:
* WebKit2.xcodeproj/project.pbxproj:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163212 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebKit Bot Watcher's Dashboard: Access restricted queue should only prompt for HTTP credentials once per page load
https://bugs.webkit.org/show_bug.cgi?id=127849

Reviewed by Alexey Proskuryakov.

Currently whenever the dashboard updates the status of a queue whose Buildbot requires authentication
it will cause a browser to prompt for credentials once per update until valid credentials are provided.
Instead we should keep track of Buildbots that respond with an HTTP 401 Unauthorized status code to avoid
subsequently querying them and hence cause a browser to prompt for credentials. Together with an optional
hint provided when instantiating a Buildbot object as to whether it requires authentication, we can make
the dashboard prompt for HTTP credentials exactly once per page load for each queue whose associated
Buildbot requires authentication.

Queues whose Buildbot wasn't authenticated will show in the dashboard as "unauthorized". Clicking on
this status message will cause the browser to prompt for credentials.

* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/Buildbot.js:
(Buildbot): Initialize instance variable authenticationStatus to Buildbot.AuthenticationStatus.Unauthenticated.
(Buildbot.prototype.get needsAuthentication): Added.
(Buildbot.prototype.get authenticationStatus): Added.
(Buildbot.prototype.get isAuthenticated): Added.
(Buildbot.prototype.set isAuthenticated): Added.
(Buildbot.prototype.updateQueues): Added.
* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BuildbotBuilderQueueView.js:
(BuildbotBuilderQueueView.prototype.update.appendBuilderQueueStatus): Modified to call
BuildbotQueueView.prototype._appendUnauthorizedLineView() to update the view and show status of the queue as
"unauthorized" if the Buildbot associated with the queue is either unauthenticated or was given invalid credentials.
* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BuildbotQueue.js:
(BuildbotQueue.prototype.update): Return immediately if the associated Buildbot requires authentication.
Additionally, if the JSON load fails with an HTTP 401 Unauthorized access error (say, credentials were
invalidated) then update the authentication status of the Buildbot to avoid subsequently prompting a
person for credentials the next time the queue update timer fires.
* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BuildbotQueueView.js:
(BuildbotQueueView): Register as a listener for event BuildbotQueue.Event.UnauthorizedAccess on each queue
so that the view can be updated to show status "unauthorized".
(BuildbotQueueView.prototype._appendUnauthorizedLineView): Added.
* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BuildbotTesterQueueView.js:
(BuildbotTesterQueueView.prototype.update.appendBuilderQueueStatus):
* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/StatusLineView.js: Added new status, StatusLineView.Status.Unauthorized.
* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Styles/StatusLineView.css:
(.status-line.unauthorized .bubble): Added.
(.status-line.unauthorized .bubble.pictogram): Added.
(.status-line.unauthorized .message): Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163213 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION: Crash in sanitizeStackForVMImpl when scrolling @ lifehacker.com.au
https://bugs.webkit.org/show_bug.cgi?id=128017

Reviewed by Filip Pizlo.

Moved the setting and saving of VM::stackPointerAtVMEntry and the corresponding stack limit
to JSLock and JSLock::DropAllLocks.  The saved data is now stored in per-thread in
WTFThreadData.

Source/JavaScriptCore: 

* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::DropAllLocks::DropAllLocks):
(JSC::JSLock::DropAllLocks::~DropAllLocks):
* runtime/JSLock.h:
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::~VMEntryScope):
* runtime/VMEntryScope.h:

Source/WTF: 

* wtf/WTFThreadData.cpp:
(WTF::WTFThreadData::WTFThreadData):
* wtf/WTFThreadData.h:
(WTF::WTFThreadData::savedStackPointerAtVMEntry):
(WTF::WTFThreadData::setSavedStackPointerAtVMEntry):
(WTF::WTFThreadData::savedLastStackTop):
(WTF::WTFThreadData::setSavedLastStackTop):
(WTF::WTFThreadData::savedReservedZoneSize):
(WTF::WTFThreadData::setSavedReservedZoneSize):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebKitTestRunner project doesn't show Mac as a valid destination architecture.

Make sure that SUPPORTED_PLATFORMS is defined in Base.xcconfig.

Also add BaseTarget.xcconfig to the project.

* WebKitTestRunner/Configurations/Base.xcconfig:
* WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163215 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Even when in fixed layout mode, some platforms need to do layout after a viewport change
https://bugs.webkit.org/show_bug.cgi?id=128003

Reviewed by Andreas Kling.

Re-land 163182 with a less aggresive check in visibleContentsResized() for
needing to layout.

iOS uses fixed layout mode in both WK1 and WK2, but lays out fixed position
elements relative to a variable viewport. This code assumed that fixed layout
implies a fixed viewport.

Fix by testing for useCustomFixedPositionLayoutRect() in the fixed layout case.

Also removed RenderView::hasCustomFixedPosition() which is no longer used.

* page/FrameView.cpp:
(WebCore::FrameView::shouldLayoutAfterViewportChange):
(WebCore::FrameView::visibleContentsResized):
* page/FrameView.h:
* rendering/RenderView.cpp:
* rendering/RenderView.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163216 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add session support to WebPlatformStrategies
https://bugs.webkit.org/show_bug.cgi?id=127926

Patch by Martin Hock <mhock@apple.com> on 2014-01-31
Reviewed by Alexey Proskuryakov.

* NetworkProcess/mac/RemoteNetworkingContext.mm:
(WebKit::RemoteNetworkingContext::ensurePrivateBrowsingSession):
* Shared/SessionTracker.cpp:
(WebKit::storageSessionToID):
(WebKit::SessionTracker::session):
(WebKit::SessionTracker::sessionID):
(WebKit::SessionTracker::setSession):
(WebKit::SessionTracker::destroySession):
* Shared/SessionTracker.h:
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::setSession):
* WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:
(WebKit::WebPlatformStrategies::cookiesForDOM):
(WebKit::WebPlatformStrategies::setCookiesFromDOM):
(WebKit::WebPlatformStrategies::cookiesEnabled):
(WebKit::WebPlatformStrategies::cookieRequestHeaderFieldValue):
(WebKit::WebPlatformStrategies::getRawCookies):
(WebKit::WebPlatformStrategies::deleteCookie):
* WebProcess/WebCoreSupport/mac/WebFrameNetworkingContext.mm:
(WebKit::WebFrameNetworkingContext::ensurePrivateBrowsingSession):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::setSessionID): Ensure the storage session exists.
* WebProcess/WebPage/WebPage.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163217 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[wk2] PlatformCALayerRemoteCustom doesn't work on iOS
https://bugs.webkit.org/show_bug.cgi?id=128025
<rdar://problem/15950271>

Reviewed by Simon Fraser.

* Platform/mac/LayerHostingContext.h:
* Platform/mac/LayerHostingContext.mm:
(WebKit::LayerHostingContext::createForPort):
(WebKit::LayerHostingContext::createForExternalHostingProcess):
Use the new macro name (in a lot of places).
Rename LayerHostingContext::createForWindowServer() to createForExternalHostingProcess().
Don't use WKCAContextMakeRemoteForWindowServer on iOS, just use the CAContext
SPI directly. We don't want our CAContext to be hit tested because it's purely
presentational.

* UIProcess/API/ios/PageClientImplIOS.h:
iOS always hosts layers in an external process.

* PluginProcess/mac/PluginControllerProxyMac.mm:
(WebKit::PluginControllerProxy::updateLayerHostingContext):
* Shared/LayerTreeContext.h:
* UIProcess/API/mac/PageClientImpl.mm:
(WebKit::PageClientImpl::viewLayerHostingMode):
* UIProcess/PageClient.h:
(WebKit::PageClient::viewLayerHostingMode):
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::WebPageProxy):
(WebKit::WebPageProxy::viewStateDidChange):
* WebProcess/Plugins/Netscape/NetscapePlugin.cpp:
(WebKit::NetscapePlugin::NetscapePlugin):
* WebProcess/Plugins/Netscape/mac/NetscapePluginMac.mm:
(WebKit::NetscapePlugin::compositingRenderServerPort):
* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::setLayerHostingMode):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::reinitializeWebPage):
* WebProcess/WebPage/mac/PlatformCALayerRemoteCustom.mm:
(PlatformCALayerRemoteCustom::PlatformCALayerRemoteCustom):
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::updateLayerHostingContext):
Use enum class for LayerHostingMode and rename the members to InProcess and OutOfProcess.

* Plugins/Hosted/WebHostedNetscapePluginView.mm:
(-[WebHostedNetscapePluginView windowHostsLayersInWindowServer]):
Use the new macro name.

* wtf/Platform.h:
Rename HAVE_LAYER_HOSTING_IN_WINDOW_SERVER to HAVE_OUT_OF_PROCESS_LAYER_HOSTING
and make it true on iOS.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163218 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update test results for a new DOM URL test (we now pass more).

* fast/dom/DOMURL/invalid-url-getters-expected.txt:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163220 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix iOS build.

* TestWebKitAPI/Configurations/Base.xcconfig:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163221 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Attempt to fix Production Dashboard after <http://trac.webkit.org/changeset/163213>
(https://bugs.webkit.org/show_bug.cgi?id=127849)

Reviewed by David Farler.

Pass credentials when querying build bot iteration.

* BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BuildbotIteration.js:
(BuildbotIteration.prototype.update):
(BuildbotIteration.prototype.loadLayoutTestResults):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163222 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Avoid eagerly creating the JSActivation when the debugger is attached.
<https://webkit.org/b/127910>

Reviewed by Oliver Hunt.

Octane scores for this patch:
    baseline w/o WebInspector: 11621
    patched  w/o WebInspector: 11801
    baseline w/ WebInspector:  3295
    patched  w/ WebInspector:  7070   2.1x improvement

1. Because debugger can potentially create a closure from any call frame,
   we need every function to allocate an activation register and check for
   the need to tear off the activation (if needed) on return.

   However, we do not need to eagerly create the activation object.
   This patch implements the optimization to defer creation of the
   activation object until we actually need it i.e. when:

   1. We encounter a "eval", "with", or "catch" statement.
   2. We've paused in the debugger, and called DebuggerCallFrame::scope().

2. The UnlinkedCodeBlock provides a needsFullScopeChain flag that is used
   to indicate whether the linked CodeBlock will need an activation
   object or not. Under normal circumstances, needsFullScopeChain and
   needsActivation are synonymous. However, with a debugger attached, we
   want the CodeBlock to always allocate an activationRegister even if
   it does not need a "full scope chain".

   Hence, we apply the following definitions to the "flags":

   1. UnlinkedCodeBlock::needsFullScopeChain() - this flag indicates that
      the parser discovered JS artifacts (e.g. use of "eval", "with", etc.)
      that requires an activation.

      BytecodeGenerator's destinationForAssignResult() and leftHandSideNeedsCopy()
      checks needsFullScopeChain().

   2. UnlinkedCodeBlock::hasActivationRegister() - this flag indicates that
      an activation register was created for the UnlinkedCodeBlock either
      because it needsFullScopeChain() or because the debugger is attached.

   3. CodeBlock::needsActivation() reflects UnlinkedCodeBlock's
      hasActivationRegister().

3. Introduced BytecodeGenerator::emitPushFunctionNameScope() and
   BytecodeGenerator::emitPushCatchScope() because the JSNameScope
   pushed for a function name cannot be popped unlike the JSNameScope
   pushed for a "catch". Hence, we have 2 functions to handle the 2 cases
   differently.

4. Removed DebuggerCallFrame::evaluateWithCallFrame() and require that all
   debugger evaluations go through the DebuggerCallFrame::evaluate(). This
   ensures that debugger evaluations require a DebuggerCallFrame.

   DebuggerCallFrame::evaluateWithCallFrame() was used previously because
   we didn't want to instantiate a DebuggerCallFrame on every debug hook
   callback. However, we now only call the debug hooks when needed, and
   this no longer poses a performance problem.

   In addition, when the debug hook does an eval to test a breakpoint
   condition, it is incorrect to evaluate it without a DebuggerCallFrame
   anyway.

5. Added some utility functions to the CallFrame to make it easier to work
   with the activation register in the frame (if present). These utility
   functions should only be called if the CodeBlock::needsActivation() is
   true (which indicates the presence of the activation register). The
   utlity functions are:

   1. CallFrame::hasActivation()
      - checks if the frame's activation object has been created.

   2. CallFrame::activation()
      - returns the frame's activation object.

   3. CallFrame::uncheckedActivation()
      - returns the JSValue in the frame's activation register. May be null.

   4. CallFrame::setActivation()
      - sets the frame's activation object.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
- added symbollic dumping of ResolveMode and ResolveType values for some
  bytecodes.
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::activationRegister):
(JSC::CodeBlock::uncheckedActivationRegister):
(JSC::CodeBlock::needsActivation):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::needsFullScopeChain):
(JSC::UnlinkedCodeBlock::hasActivationRegister):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::resolveCallee):
(JSC::BytecodeGenerator::createActivationIfNecessary):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::emitPushCatchScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
* debugger/Debugger.cpp:
(JSC::Debugger::hasBreakpoint):
(JSC::Debugger::pauseIfNeeded):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::scope):
(JSC::DebuggerCallFrame::evaluate):
* debugger/DebuggerCallFrame.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGGraph.h:
- Removed an unused function DFGGraph::needsActivation().
* interpreter/CallFrame.cpp:
(JSC::CallFrame::activation):
(JSC::CallFrame::setActivation):
* interpreter/CallFrame.h:
(JSC::ExecState::hasActivation):
(JSC::ExecState::registers):
* interpreter/CallFrameInlines.h:
(JSC::CallFrame::uncheckedActivation):
* interpreter/Interpreter.cpp:
(JSC::unwindCallFrame):
(JSC::Interpreter::unwind):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):

* runtime/JSScope.cpp:
* runtime/JSScope.h:
(JSC::resolveModeName):
(JSC::resolveTypeName):
- utility functions for decoding names of the ResolveMode and ResolveType.
  These are used in CodeBlock::dumpBytecode().



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163223 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DFG->FTL tier-up shouldn't assume that LoopHints stay at the tops of loops
https://bugs.webkit.org/show_bug.cgi?id=128030

Reviewed by Oliver Hunt.
        
Remove a bogus assertion. The only thing that matters is that the LoopHint had at one
point in time been at the top of a loop header, and that it is now at the top of a
basic block. But the basic block that it's at the top of now doesn't have to be the
same as the loop header that it once was the top of.

* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* tests/stress/tier-up-in-loop-with-cfg-simplification.js: Added.
(foo):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163224 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-01-31  Oliver Hunt  <oliver@apple.com>

        Rollout r163195 and related patches

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