SVGResources should use HashSet<AtomicString> instead of HashSet<AtomicStringImpl*>
https://bugs.webkit.org/show_bug.cgi?id=98683

Reviewed by Darin Adler.

Eric's notes:

SVGResources should use HashSet<AtomicString> instead of HashSet<AtomicStringImpl*>
They do basically the same thing, and the former is much more common (and less code). It's
also safe, on the off-chance that we're using AtomicStrings which might otherwise go away.

No new tests, refactoring.

* rendering/svg/SVGResources.cpp:
(WebCore::clipperFilterMaskerTags):
(WebCore::markerTags):
(WebCore::fillAndStrokeTags):
(WebCore::chainableResourceTags):
(WebCore::SVGResources::buildCachedResources):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130780 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Shadow builds are not working anymore.
https://bugs.webkit.org/show_bug.cgi?id=98785

Reviewed by Martin Robinson.

When setting WEBKITOUTPUTDIR the build was failing with a python
error : the os.execve expect three arguments. Also the condition
to check whether we build the GTK port with jhbuild or not was buggy
as it was always assuming an in source build. We can use now jhbuildutils
which has a convenient function to locate the directory where
the dependencies built with jhbuild are and take into account WEBKITOUTPUTDIR.
If the Dependencies path does not exist then the build was not done using
jhbuild so we can fallback to a regular build against system libraries.

* gtk/run-with-jhbuild:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130781 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] modify-up-on-rtl-wrapping-text.html fails on DRT
https://bugs.webkit.org/show_bug.cgi?id=50291

Patch by Tullio Lucena <tullio.lucena@openbossa.org> on 2012-10-09
Reviewed by Csaba Osztrogonác.

Unskipping editing/selection/modify-up-on-rtl-wrapping-text.html

* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130782 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=98457
ScrollingStateNodes should be referenced via IDs on 
RenderLayerBacking

Reviewed by Simon Fraser.

This patch associates all ScrollingStateNodes with a 
RenderLayerBacking via a HashMap from RenderLayerBackings to 
ScrollingStateNodes on ScrollingCoordinator. Prior to this patch, the 
root ScrollingStateNode was created immediately upon creation of the 
ScrollingCoordinator, and it was constantly re-used for every main 
FrameView. This doesn't work in the new model since that doesn't 
allow that ScrollingStateNode to have a definite association with a 
RenderLayerBacking. So this patch does also introduce some lifetime 
differences with the ScrollingStateNodes.

If a page is going into the page cache, we should clear the state 
tree. When the page is in the cache, we won't have access to the 
RenderLayerBacking, and we don't want to be doing anything with the 
ScrollingStateNodes anyway.
* dom/Document.cpp:
(WebCore::Document::setInPageCache):

When a page is restored from the page cache, call 
frameViewRootLayerDidChange() to re-create the state tree.
* loader/HistoryController.cpp:
(WebCore::HistoryController::restoreScrollPositionAndViewState):

This new FrameView function will return the scrollLayerID for a given FrameView.
* page/FrameView.cpp:
(WebCore::FrameView::scrollLayerID):
(WebCore):
* page/FrameView.h:
(FrameView):

There is a lot of unfortunate fiddling with the terrible 
if-defs in ScrollingCoordinator. I added a FIXME to the header
noting how we can avoid this in the future.
* page/scrolling/ScrollingCoordinator.cpp:

All of this code used to refer to the rootStateNode directly. 
Instead, now it looks up the proper ScrollingStateNode for the given 
FrameView in the HashMap.
(WebCore::ScrollingCoordinator::frameViewLayoutUpdated):
(WebCore::ScrollingCoordinator::frameViewWheelEventHandlerCountChanged):
(WebCore::ScrollingCoordinator::frameViewRootLayerDidChange):
(WebCore::ScrollingCoordinator::requestScrollPositionUpdate):
(WebCore::ScrollingCoordinator::updateMainFrameScrollLayerPosition):
(WebCore::ScrollingCoordinator::recomputeWheelEventHandlerCountForFrameView):
(WebCore::ScrollingCoordinator::setScrollLayerForNode):
(WebCore::ScrollingCoordinator::setNonFastScrollableRegionForNode):
(WebCore::ScrollingCoordinator::setScrollParametersForNode):
(WebCore::ScrollingCoordinator::setWheelEventHandlerCountForNode):

Returns the existing ScrollingStateNode for a given FrameView by 
looking it up in the HashMap.
(WebCore::ScrollingCoordinator::stateNodeForFrameView):

This is called when a RenderLayerBacking is destroyed. At that time, 
its associated ScrollingStateNode is destroyed.
(WebCore::ScrollingCoordinator::detachFromStateTree):

clearStateTree() clears the HashMap and destroys all of the nodes in 
the current state tree.
(WebCore::ScrollingCoordinator::clearStateTree):

Creates a new root state node for the given FrameView.
(WebCore::ScrollingCoordinator::ensureRootStateNodeForFrameView):

Some new functions for the new node stuff.
* page/scrolling/ScrollingCoordinator.h:
* page/scrolling/ScrollingCoordinatorNone.cpp:
(WebCore::ScrollingCoordinator::setShouldUpdateScrollLayerPositionOnMainThread):
(WebCore::ScrollingCoordinator::supportsFixedPositionLayers):
(WebCore::ScrollingCoordinator::setLayerIsContainerForFixedPositionLayers):
(WebCore::ScrollingCoordinator::setLayerIsFixedToContainerLayer):
(WebCore::ScrollingCoordinator::scrollableAreaScrollLayerDidChange):
(WebCore::ScrollingCoordinator::detachFromStateTree):
(WebCore::ScrollingCoordinator::clearStateTree):
(WebCore::ScrollingCoordinator::ensureRootStateNodeForFrameView):
(WebCore::setScrollParameters):
(WebCore::setWheelEventHandlerCount):

New remove functions are used when the sate tree is cleared and when 
a RenderLayerBacking is destroyed.
* page/scrolling/ScrollingStateNode.cpp:
(WebCore::ScrollingStateNode::removeChild):
(WebCore):
* page/scrolling/ScrollingStateNode.h:
(WebCore::ScrollingStateNode::isScrollingStateScrollingNode):
(ScrollingStateNode):
(WebCore::ScrollingStateNode::parent):

New convenience function for casting to ScrollingStateScrollingNodes.
* page/scrolling/ScrollingStateScrollingNode.h:
(WebCore::toScrollingStateScrollingNode):
(WebCore):

No longer automatically create a root node upon creation of the 
ScrollingStateTree. We now want to wait to create the root node until 
we have a RenderLayerBacking to associate it with.
* page/scrolling/ScrollingStateTree.cpp:
(WebCore::ScrollingStateTree::ScrollingStateTree):
(WebCore::ScrollingStateTree::removeNode):
(WebCore):
* page/scrolling/ScrollingStateTree.h:
(WebCore::ScrollingStateTree::setRootStateNode):
(ScrollingStateTree):

RenderLayerBacking has a new data member called m_scrollLayerID. If 
this RenderLayerBacking is represented in the scrolling tree, then 
the ID with be unique and non-zero. 
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::RenderLayerBacking):
(WebCore::RenderLayerBacking::~RenderLayerBacking):
(WebCore::generateScrollLayerID):
(WebCore):
(WebCore::RenderLayerBacking::attachToScrollingCoordinator):
(WebCore::RenderLayerBacking::detachFromScrollingCoordinator):
* rendering/RenderLayerBacking.h:
(RenderLayerBacking):
(WebCore::RenderLayerBacking::scrollLayerID):

Move the call to ScrollingCooridinator::frameViewRootLayerDidChange() 
from RenderLayerCompositor::attachRootLayer() to 
RenderLayerCompositor:: updateBacking(). The problem with the old call 
site is that there is no backing at that time, so we are trying to set 
state on the root scrolling state node before we have enough 
information to create that node and add it to the HashMap.
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateBacking):
(WebCore::RenderLayerCompositor::attachRootLayer):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130783 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed Chromium gardening.

* platform/chromium/TestExpectations:
Fix new-run-webkit-tests --lint-test-files after r130778.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130784 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Revert change to TestExpectations in http://trac.webkit.org/changeset/130779.
These tests still give the wrong results.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130785 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Note that this test is flaky.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130786 268f45cc-cd09-0410-ab3c-d52691b4dbfc
RTL: selection.modify("move", "forward", "line") when cursor is at start of a line does not move down a line
https://bugs.webkit.org/show_bug.cgi?id=51517

Patch by Tullio Lucena <tullio.lucena@openbossa.org> on 2012-10-09
Reviewed by Caio Marcelo de Oliveira Filho.

Unskipping a test that is passing, with testfonts change in https://gitorious.org/qtwebkit/testfonts/merge_requests/1

* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130787 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Need implement isWordTextBreak for QT, and WinCE for visual word movement functionality
https://bugs.webkit.org/show_bug.cgi?id=81136

Patch by Tullio Lucena <tullio.lucena@openbossa.org> on 2012-10-09
Reviewed by Caio Marcelo de Oliveira Filho.

Uskipping tests that are passing after the merge https://gitorious.org/qtwebkit/testfonts/merge_requests/1

* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130788 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix the order of the statements in my previous build fix.

Reviewed by Gustavo Noronha Silva.

My previous build build fix for ResourceHandleSoup ordered the assignment
of the local ResourceHandleInternal incorrectly. Instead of being before
both assertions, it should be interspersed among them.

* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::createSoupMessageForHandleAndRequest):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130789 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't duplicated build numbers when merging flakiness dashboard JSON
https://bugs.webkit.org/show_bug.cgi?id=98812

Reviewed by Dirk Pranke.

In general, build numbers are not unique, but we should basically never
get the same build number uploaded twice in a row. This is a workaround
for https://bugs.webkit.org/show_bug.cgi?id=97643, which frequently hits this
because we update results_small.json and timeout updating results.json and then
we retry the whole request.

* TestResultServer/model/jsonresults.py:
(JsonResults.merge):
* TestResultServer/model/jsonresults_unittest.py:
(JsonResultsTest.test_merge_duplicate_build_number):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130790 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: open-in-upgradeneeded layout test
https://bugs.webkit.org/show_bug.cgi?id=95912

Reviewed by Tony Chang.

* storage/indexeddb/intversion-open-in-upgradeneeded-expected.txt: Added.
* storage/indexeddb/intversion-open-in-upgradeneeded.html: Added.
* storage/indexeddb/resources/intversion-open-in-upgradeneeded.js: Added.
(test):
(deleteSuccess):
(upgradeNeeded1.transaction.oncomplete):
(upgradeNeeded1):
(openSuccess1):
(onVersionChange):
(onBlocked):
(upgradeNeeded2):
(openSuccess2):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130791 268f45cc-cd09-0410-ab3c-d52691b4dbfc
XvfbDriver unit test is flaky on Linux builders
https://bugs.webkit.org/show_bug.cgi?id=98346

Reviewed by Adam Barth.

Temporarily skip the XvfbDriver test case that tests
the display number of the next free display. The test
is flaky on Linux builders.

* Scripts/webkitpy/layout_tests/port/xvfbdriver_unittest.py:
(XvfbDriverTest.disabled_test_next_free_display):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130792 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Don't run perf/mouse-event on debug builds

Unreviewed, expectations change.

We don't normally run any perf tests on a debug build, but this
one was getting run due to an improperly scoped expectation
overriding the wontfix rule.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: Overflowing key generator should throw ConstraintError
https://bugs.webkit.org/show_bug.cgi?id=98807

Reviewed by Tony Chang.

Source/WebCore:

After the WebKit implementation landed throwing DataError, public-webapps
consensus was that the exception thrown should be ConstraintError. Trivial
change, and we pass one more W3C test submission.

Test: storage/indexeddb/key-generator.html

* Modules/indexeddb/IDBObjectStoreBackendImpl.cpp:
(WebCore::IDBObjectStoreBackendImpl::putInternal):

LayoutTests:

Verify that overflowing key generator throws ConstraintError.

* storage/indexeddb/key-generator-expected.txt:
* storage/indexeddb/resources/key-generator.js:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130794 268f45cc-cd09-0410-ab3c-d52691b4dbfc
MarkupAccumulator should optimally handle 8 bit Strings
https://bugs.webkit.org/show_bug.cgi?id=98224

Reviewed by Ryosuke Niwa.

Updated appendCharactersReplacingEntities to take a string, offset and length and process 8 or 16 bit
data as appropriate.  Also made it a member function of MarkupAccumulator.

No new tests, behavior covered by existing tests.

* editing/MarkupAccumulator.cpp:
(WebCore::MarkupAccumulator::appendCharactersReplacingEntities):
(WebCore::MarkupAccumulator::appendAttributeValue):
(WebCore::MarkupAccumulator::appendNodeValue):
* editing/MarkupAccumulator.h:
(MarkupAccumulator):
* editing/markup.cpp:
(WebCore::StyledMarkupAccumulator::appendText):
(WebCore::urlToMarkup):


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