Unreviewed. Add myself as a committer.

* Scripts/webkitpy/common/config/contributors.json:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166437 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: AXI: expose what elements get generic "clickable" status
https://bugs.webkit.org/show_bug.cgi?id=130721

Patch by James Craig <jcraig@apple.com> on 2014-03-28
Reviewed by Timothy Hatcher.

Source/WebCore:

Test: inspector-protocol/dom/getAccessibilityPropertiesForNode.html:
Test: inspector-protocol/dom/getAccessibilityPropertiesForNode_mouseEventNodeId.html

Expose ancestor element link to "Click Listener" or generic "Clickable: Yes" if current node has mouse handler.

Update AccessibilityNodeObject::mouseButtonListener() to optionally return body element if
    requested so that Web Inspector can display body event delegate handlers.

* accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::mouseButtonListener):
* accessibility/AccessibilityNodeObject.h:
* inspector/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::buildObjectForAccessibilityProperties):
* inspector/protocol/DOM.json:

Source/WebInspectorUI:

Expose ancestor element link to "Click Listener" or generic "Clickable: Yes" if current node has mouse handler.

* Localizations/en.lproj/localizedStrings.js: New "Mouse Event" string.
* UserInterface/Models/DOMNode.js: Added nodeId and mouseEventNodeId.
* UserInterface/Views/DOMNodeDetailsSidebarPanel.js: UI for new detail row.

LayoutTests:

Expose ancestor element link to "Click Listener" or generic "Clickable: Yes" if current node has mouse handler.

* inspector-protocol/dom/getAccessibilityPropertiesForNode-expected.txt:
* inspector-protocol/dom/getAccessibilityPropertiesForNode.html: Simple coverage of mouseEventNodeId.
* inspector-protocol/dom/getAccessibilityPropertiesForNode_mouseEventNodeId-expected.txt: Added.
* inspector-protocol/dom/getAccessibilityPropertiesForNode_mouseEventNodeId.html: Added. Full coverage.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166438 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: console.warn is showing as error instead of warning
https://bugs.webkit.org/show_bug.cgi?id=130921

Patch by Joseph Pecoraro <pecoraro@apple.com> on 2014-03-28
Reviewed by Timothy Hatcher.

Source/JavaScriptCore:

* runtime/ConsolePrototype.cpp:
(JSC::consoleProtoFuncWarn):
console.warn should be MessageLevel Warning, not Error.

Source/WebInspectorUI:

* UserInterface/Models/DefaultDashboard.js:
(WebInspector.DefaultDashboard.prototype._incrementConsoleMessageType):
Use our enums instead of hardcoded strings.

LayoutTests:

Add a test for console.log, warn, error, etc to make sure they get
to the frontend with the expected source and level.

* inspector-protocol/console/console-message-expected.txt: Added.
* inspector-protocol/console/console-message.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166439 268f45cc-cd09-0410-ab3c-d52691b4dbfc
mandreel throws a checksum error on 32-bit x86.
<https://webkit.org/b/125706>

Reviewed by Filip Pizlo.

The 32-bit DFG can emit code that loads double constants from its
CodeBlock's m_constantRegisters vector.  The emitted instruction will
embed the address of the constant from the vector's backing store.
Subsequently, while inserting new constants, the DFG may resize the
vector, thereby reallocating the backing store.  This renders the
previously embedded constant addresses stale.

The fix is to use a dedicated doubles constant pool stored in the DFG
CommonData instead.  This constant pool won't be reallocated, and
hence will not manifest this issue.

* dfg/DFGCommonData.h:
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::addressOfDoubleConstant):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addressOfDoubleConstant): Deleted.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166440 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Have the plugin process track visibility of it’s plugin and sleep when none
are visible.
Part of <rdar://problem/16061257> PluginProcess should AppNap when no plugins on active tab.
https://bugs.webkit.org/show_bug.cgi?id=130694

Reviewed by Anders Carlsson.

Currently AppSleep is enabled on the PluginProcess based on web page visibility.
Add visibility tracking to plugins and move the decision to AppSleep into the the
PluginProcess

* PluginProcess/PluginProcess.cpp:
(WebKit::PluginProcess::PluginProcess): Add a new activity for visible plugins
(WebKit::PluginProcess::pluginsForWebProcessDidBecomeVisible): take an activity
     assertion if any web processes have a visible plugin.
(WebKit::PluginProcess::pluginsForWebProcessDidBecomeHidden):
* PluginProcess/PluginProcess.h:
* PluginProcess/WebProcessConnection.cpp:
(WebKit::WebProcessConnection::removePluginControllerProxy): remove plugin from
    visible plugins when destroying it
(WebKit::WebProcessConnection::pluginDidBecomeVisible):
(WebKit::WebProcessConnection::pluginDidBecomeHidden): track which plugins are
    visible for each web process
* PluginProcess/WebProcessConnection.h:
* PluginProcess/mac/PluginControllerProxyMac.mm:
(WebKit::PluginControllerProxy::windowVisibilityChanged): notify WebProcessConnection
    when visibility changed.
* UIProcess/WebContext.h:
* UIProcess/mac/WebContextMac.mm:  instead of tracking plugin app sleep state on the web pref.
    and visibility state, just use the web pref.
(WebKit::WebContext::updateProcessSuppressionState):
(WebKit::WebContext::processSuppressionPreferenceIsEnabledForAllContexts):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166441 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Notification handler for telling if audio hardware is active.
https://bugs.webkit.org/show_bug.cgi?id=130743

Reviewed by Jer Noble.

Not web-exposed so no easy way to test.

Listen to CoreAudio to see if audio hardware is active in the current process.

* WebCore.exp.in:
* WebCore.xcodeproj/project.pbxproj:
* platform/audio/AudioHardwareListener.cpp: Added.
(WebCore::AudioHardwareListener::create):
(WebCore::AudioHardwareListener::AudioHardwareListener):
* platform/audio/AudioHardwareListener.h: Added.
(WebCore::AudioHardwareListener::Client::~Client):
(WebCore::AudioHardwareListener::~AudioHardwareListener):
(WebCore::AudioHardwareListener::isHardwareActive):
* platform/audio/mac/AudioHardwareListenerMac.cpp: Added.
(WebCore::isAudioHardwareProcessRunning):
(WebCore::AudioHardwareListener::create):
(WebCore::AudioHardwareListenerMac::create):
(WebCore::AudioHardwareListenerMac::AudioHardwareListenerMac):
(WebCore::AudioHardwareListenerMac::~AudioHardwareListenerMac):
(WebCore::AudioHardwareListenerMac::setHardwareActive):
* platform/audio/mac/AudioHardwareListenerMac.h: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166442 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: Rename pluginDidEvaluate to better represent when it’s called.
Part of <rdar://problem/16061257> PluginProcess should AppNap when no plugins on active tab.

Reviewed by Anders Carlsson.

No new test because it’s just a name change.

* page/PageThrottler.h:
(WebCore::PageThrottler::pluginDidEvaluateWhileAudioIsPlaying):

Source/WebKit2: Stop waking up the web process in the background because of plugin activity.
Part of <rdar://problem/16061257> PluginProcess should AppNap when no plugins on active tab.

Reviewed by Anders Carlsson.

Plugin activity in the background can constantly wake up web processes.  This is only
necessary when audio is playing to support web apps like Pandora and youtube playing
in the background.  Use a new api in CoreAudio to see if there is audio playing in
the PluginProcess.

* PluginProcess/PluginProcess.cpp:
(WebKit::PluginProcess::PluginProcess): Add a AudioHardwareListener
(WebKit::PluginProcess::createWebProcessConnection): tell web process current state
(WebKit::PluginProcess::audioHardwareDidBecomeActive): respond to audio hardware notifications
(WebKit::PluginProcess::audioHardwareDidBecomeInactive):
* PluginProcess/PluginProcess.h:
* PluginProcess/WebProcessConnection.cpp: tell WebProcess when audio state in PluginProcess
     changes.
(WebKit::WebProcessConnection::audioHardwareDidBecomeActive):
(WebKit::WebProcessConnection::audioHardwareDidBecomeInactive):
* PluginProcess/WebProcessConnection.h:
* WebProcess/Plugins/Netscape/NPRuntimeObjectMap.cpp:
     Only invoke pageThrottler activity when playing audio
(WebKit::NPRuntimeObjectMap::evaluate):
* WebProcess/Plugins/Plugin.h: add function to get audio state
(WebKit::Plugin::audioIsPlayingInPluginProcess):
* WebProcess/Plugins/PluginProcessConnection.cpp: store audio state
(WebKit::PluginProcessConnection::PluginProcessConnection):
(WebKit::PluginProcessConnection::didReceiveMessage):
(WebKit::PluginProcessConnection::audioHardwareDidBecomeActive):
(WebKit::PluginProcessConnection::audioHardwareDidBecomeInactive):
* WebProcess/Plugins/PluginProcessConnection.h:
(WebKit::PluginProcessConnection::audioIsPlaying):
* WebProcess/Plugins/PluginProcessConnection.messages.in:
* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::audioIsPlayingInPluginProcess):
* WebProcess/Plugins/PluginProxy.h:
* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::audioIsPlayingInPluginProcess):
* WebProcess/Plugins/PluginView.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166443 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't prevent AppSleep from sync messages.
https://bugs.webkit.org/show_bug.cgi?id=130747.

Reviewed by Anders Carlsson.

We think sync messages only need to happen full throttle when the plugin is visible,
the user is interacting with the plugin, or audio is playing.  Since we already
take assertions for all these cases the assertion in sync messages doesn’t provide
any value.  Since it can keep the PluginProcess awake in other instances remove it.

* PluginProcess/WebProcessConnection.cpp:
(WebKit::WebProcessConnection::didReceiveSyncMessage):

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