Refactor EventDispatcher, moving code to make actual changes easier to review later.
https://bugs.webkit.org/show_bug.cgi?id=93959

Reviewed by Dimitri Glazkov.

No new tests - no new functionality.

* dom/EventDispatcher.cpp:
(WebCore::EventDispatcher::dispatchScopedEvent):
(WebCore):
(WebCore::EventDispatcher::dispatchSimulatedClick):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125626 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: add tracing to IDBLevelDBBackingStore
https://bugs.webkit.org/show_bug.cgi?id=93914

Patch by Alec Flett <alecflett@chromium.org> on 2012-08-14
Reviewed by Tony Chang.

Add a bunch of trace events to the lower level
database layer, to separate database slowness
from core IDB slowness.

Also moving findKeyInIndex into IDBLevelDBBackingStore to
eventually make it const.

No new tests, just adding debug logging.

* Modules/indexeddb/IDBLevelDBBackingStore.cpp:
(WebCore::IDBLevelDBBackingStore::open):
(WebCore::IDBLevelDBBackingStore::deleteDatabase):
(WebCore::IDBLevelDBBackingStore::getObjectStores):
(WebCore::IDBLevelDBBackingStore::createObjectStore):
(WebCore::IDBLevelDBBackingStore::deleteObjectStore):
(WebCore::IDBLevelDBBackingStore::getObjectStoreRecord):
(WebCore):
(WebCore::IDBLevelDBBackingStore::putObjectStoreRecord):
(WebCore::IDBLevelDBBackingStore::clearObjectStore):
(WebCore::IDBLevelDBBackingStore::deleteObjectStoreRecord):
(WebCore::IDBLevelDBBackingStore::keyExistsInObjectStore):
(WebCore::IDBLevelDBBackingStore::getIndexes):
(WebCore::IDBLevelDBBackingStore::createIndex):
(WebCore::IDBLevelDBBackingStore::deleteIndex):
(WebCore::IDBLevelDBBackingStore::putIndexDataForRecord):
(WebCore::IDBLevelDBBackingStore::findKeyInIndex):
(WebCore::IDBLevelDBBackingStore::getPrimaryKeyViaIndex):
(WebCore::IDBLevelDBBackingStore::keyExistsInIndex):
(WebCore::IDBLevelDBBackingStore::openObjectStoreCursor):
(WebCore::IDBLevelDBBackingStore::openIndexKeyCursor):
(WebCore::IDBLevelDBBackingStore::openIndexCursor):
(WebCore::IDBLevelDBBackingStore::Transaction::commit):
(WebCore::IDBLevelDBBackingStore::Transaction::rollback):
* Modules/indexeddb/IDBLevelDBBackingStore.h:
(IDBLevelDBBackingStore):
* Modules/indexeddb/IDBObjectStoreBackendImpl.cpp:
(WebCore):
* Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::onAbort):
(WebCore::IDBTransaction::onComplete):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125627 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Fix some typos in MiniBrowser
https://bugs.webkit.org/show_bug.cgi?id=94047

Reviewed by Jon Honeycutt.

* MiniBrowser/mac/AppDelegate.m:
(didReceiveMessageFromInjectedBundle): (-[BrowserAppDelegate init]):
* MiniBrowser/mac/WebBundle/WebBundleMain.m:
(didReceiveMessage):
(WKBundleInitialize):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125628 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders][Chromium] Filters area applied twice when CustomFilterOperation is in the list
https://bugs.webkit.org/show_bug.cgi?id=93900

Reviewed by James Robinson.

Source/WebCore:

Whenever the platform cannot render a shader in hardware it will fallback to software.
In such cases, the platform should remove any old filters applied, so that the filters do not apply twice.

Test: css3/filters/custom/filter-fallback-to-software.html

* platform/graphics/chromium/GraphicsLayerChromium.cpp:
(WebCore::GraphicsLayerChromium::setFilters):

LayoutTests:

Added a test that first applies a blur and then switches to a CSS Shader plus a blur.
The test was failing on Chromium by not removing the old blur filter from the platform layer.

* css3/filters/custom/filter-fallback-to-software-expected.html: Added.
* css3/filters/custom/filter-fallback-to-software.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125629 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Handle the XPath / (root) operator correctly for nodes that aren't attached to the document.
https://bugs.webkit.org/show_bug.cgi?id=36427

Reviewed by Abhishek Arya.

Source/WebCore:

We now behave the same as Firefox 14.
The consensus seems to be that the XPath spec is ambiguous for the case of detached nodes, and that using the fragment root is more intuitive than the document root for the case of detached nodes.
For example, http://www.w3.org/TR/xpath/ section 2 "Location Paths" is only clear for attached nodes: "A / by itself selects the root node of the document containing the context node. If it is followed by a relative location path, then the location path selects the set of nodes that would be selected by the relative location path relative to the root node of the document containing the context node."

Test: fast/xpath/xpath-detached-nodes.html

* xml/XPathPath.cpp:
(WebCore::XPath::LocationPath::evaluate): Jump to the root of the detached subtree instead of the parent document if the node isn't attached to the document.

LayoutTests:

* fast/xpath/xpath-detached-nodes-expected.txt: Added.
* fast/xpath/xpath-detached-nodes.html: Added.


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