[Qt] QRawWebView should notify when rendering is done, so that pixel results can be grabbed at the appropriate moment.
https://bugs.webkit.org/show_bug.cgi?id=90641

Reviewed by Jocelyn Turcotte.

Source/WebKit2:

Implement LayerTreeCoordinator::forceRepaint with logic equivalent to the one in
LayerTreeHostCA. If we flush the layers synchronously when forceRepaint is called,when
WKPageForceRepaint returns we are guaranteed to have an up-to-date image, as the visible
tiles are also synchronously updated.

* UIProcess/API/qt/tests/qrawwebview/tst_qrawwebview.cpp:
(WebView::WebView):
(WebView::viewNeedsDisplay):
(WebView::frameLoaded):
(WebView):
(WebView::onRepaintDone):
(WebView::finishForceRepaint):
(WebView::finishFirstLayoutForFrame):
(tst_qrawwebview::doNoBackground1):
(tst_qrawwebview::doNoBackground2):
(tst_qrawwebview::doNoBackground3):
(tst_qrawwebview::run):
    The test for QRawWebView has been updated to use the WebKit2 ForcePaint API prior to
    generating the pixel results. This has exposed a timing bug in the test - setting the
    transparentBackground property of a page has to be done before it's created. This has
    been fixed in the test.

* WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp:
(WebKit::LayerTreeCoordinator::forceRepaint):
(WebKit::LayerTreeCoordinator::performScheduledLayerFlush):
(WebKit):

Tools:

* MiniBrowser/qt/raw/View.h: Comment used old class name (WKView).
(View):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122340 268f45cc-cd09-0410-ab3c-d52691b4dbfc
jsc: Parse options before creating global data
https://bugs.webkit.org/show_bug.cgi?id=90975

Reviewed by Filip Pizlo.

This patch moves the options parsing in "jsc" before the creation
of the JSGlobalData, so that --useJIT=no has a chance to take
effect.

* jsc.cpp:
(CommandLine::parseArguments): Refactor to be a class, and take
argc and argv as constructor arguments.
(jscmain): Move arg parsing before JSGlobalData creation.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122341 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r116203): overflow sections don't have scrollbars
https://bugs.webkit.org/show_bug.cgi?id=90052

Reviewed by Simon Fraser.

This issue stems from RenderLayers with overlay scrollbars not being considered
self-painting.

After r120395 (follow-up of r116203), we ignore subtrees that have no self-painting layer for
painting. Normal scrollbars are painted by their renderer so they were properly painted. However
overlay scrollbars need to be painted by their RenderLayer as a separate phase (see bug 57057) so
they were not painted anymore. The fix is simple: make RenderLayer with overlay scrollbars
self-painting as they should have been in the first place.

Unfortunately no tests as I don't think we have a good way of testing overlay
scrollbars. Tested manually though on the super simple test case from the bug.

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::shouldBeSelfPaintingLayer):
Overlay scrollbars make the layer self-painting.

(WebCore::RenderLayer::updateScrollbarsAfterLayout):
Added a call to updateSelfPaintingLayer.

(WebCore::RenderLayer::styleChanged):
Moved the call to updateSelfPaintingLayer after recomputing the scrollbars to ensure proper behavior.
Added a comment underlining the reason.

(WebCore::RenderLayer::updateSelfPaintingLayer):
Renamed as it is now called during layout too.

* rendering/RenderLayer.h:
(RenderLayer): Updated after updateSelfPaintingLayer rename.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122342 268f45cc-cd09-0410-ab3c-d52691b4dbfc
RenderView layer is marked as fixed position container in the scrolling tree if page scale != 1
https://bugs.webkit.org/show_bug.cgi?id=89216

Patch by Sami Kyostila <skyostil@chromium.org> on 2012-07-11
Reviewed by Simon Fraser.

Render layers with CSS transforms should become containers for any fixed
positioned descendants. However, because this check is done with
RenderLayer::hasTransform(), we also end up marking the RenderLayer for the
RenderView as fixed position container if a non-identity page scale factor is
used. This is because page scale is applied as a transform for that layer.

This breaks fixed position layers, because they become fixed relative to the
RenderView layer instead of outer scroll clip layer.

The fix is to avoid marking any root layers as fixed position containers.

No new test because the scrolling tree isn't currently testable.

* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateGraphicsLayerGeometry):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122343 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Use WEBKIT_IMPLEMENTATION == 1 for webkit_unit_tests
https://bugs.webkit.org/show_bug.cgi?id=90094

Reviewed by Adrienne Walker.

This patch adds the WEBKIT_IMPLEMENTATION = 1 define to
WebKitUnitTests.gyp. To get it to compile correctly, some string
and URL code was refactored and fixed, in particular GURL usage is
replaced with KURL usage.

* WebKit.gyp:
added WEBKIT_IMPLEMENTATION == 1 for unit test code when in shared library
added URLTestHelpers to exclusion in shared library build, because it depends on webkit_support

* WebKit.gypi:
added URLTestHelpers.h and .cpp to the build process

* WebKitUnitTests.gyp:
added WEBKIT_IMPLEMENTATION == 1 for unit test code when not in shared library.
note that in shared library build, RunAllTests.cpp does not have WEBKIT_IMPLEMENTATION == 1.

* public/WebDOMMessageEvent.h:
(WebKit::WebDOMMessageEvent::WebDOMMessageEvent):
* tests/AssociatedURLLoaderTest.cpp:
* tests/EventListenerTest.cpp:
* tests/FrameTestHelpers.cpp:
(WebKit::FrameTestHelpers::loadFrame):
* tests/FrameTestHelpers.h:
* tests/ListenerLeakTest.cpp:
(WebKit::ListenerLeakTest::RunTest):
* tests/PopupMenuTest.cpp:
* tests/RunAllTests.cpp:
* tests/URLTestHelpers.cpp: Added.
(URLTestHelpers):
(WebKit::URLTestHelpers::registerMockedURLFromBaseURL):
(WebKit::URLTestHelpers::registerMockedURLLoad):
* tests/URLTestHelpers.h: Copied from Source/WebKit/chromium/public/WebDOMMessageEvent.h.
(WebKit):
(URLTestHelpers):
(WebKit::URLTestHelpers::toKURL):
* tests/WebFrameTest.cpp:
* tests/WebPageNewSerializerTest.cpp:
* tests/WebPageSerializerTest.cpp:
* tests/WebViewTest.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122344 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTMLFormCollection::item and HTMLPropertiesCollection::item should share code
https://bugs.webkit.org/show_bug.cgi?id=90932

Reviewed by Anders Carlsson.

Merged HTMLFormCollection::item and HTMLPropertiesCollection::item as HTMLCollectionWithArrayStorage::item,
which can be merged into HTMLCollection::item in a follow up patch.

Also moved the call to invalidateCacheIfNeeded into HTMLCollection::updateNameCache() as done in
HTMLPropertiesCollection.

In addition, moved the early bail out for when the base element doesn't have itemscope attribute from individual
functions to updateRefElements so that HTMLCollectionWithArrayStorage::item doesn't need to have this check.

* html/HTMLCollection.cpp:
(WebCore::HTMLCollectionWithArrayStorage::item): Added. It's based on HTMLPropertiesCollection::item but it only
has the single loop (as supposed to nested loops) as HTMLFormCollection doesn't have multiple items per element
in the array unlike HTMLPropertiesCollection. In addition, offsetInArray (was i in HTMLPropertiesCollection::item) is
incremented in each itemAfter due to this semantic difference in each itemAfter.
(WebCore::HTMLCollection::updateNameCache):
(WebCore::HTMLCollection::hasNamedItem):
(WebCore::HTMLCollection::namedItems):
* html/HTMLCollection.h:
(HTMLCollectionWithArrayStorage):
(WebCore::HTMLCollectionWithArrayStorage::HTMLCollectionWithArrayStorage):
* html/HTMLFormCollection.cpp:
(WebCore::HTMLFormCollection::HTMLFormCollection):
(WebCore::HTMLFormCollection::calcLength): Merged numberOfFormControlElements since it was only called here.
(WebCore::HTMLFormCollection::itemAfter): Added. HTMLFormCollection has exactly one item per element in the array
so we increment the offset in each iteration. Note that when we're continuing a search, we need to increment
the offset in order to avoid returning the same item.
(WebCore::HTMLFormCollection::updateNameCache):
* html/HTMLFormCollection.h:
(HTMLFormCollection):
* html/HTMLPropertiesCollection.cpp:
(WebCore::HTMLPropertiesCollection::HTMLPropertiesCollection):
(WebCore::HTMLPropertiesCollection::updateRefElements): Set m_hasItemRefElements true upfront since we never fail to
update ref elements. Bail out as soon as we cleared the m_itemRefElements when the base element doesn't have itemscope
content attribute.
(WebCore::HTMLPropertiesCollection::itemAfter): Added. We reset previousItem to null because the existing itemAfter
requires previousItem be null when we're moving to a new entry in m_itemRefElements.
(WebCore::HTMLPropertiesCollection::calcLength):
(WebCore::HTMLPropertiesCollection::cacheFirstItem):
(WebCore::HTMLPropertiesCollection::updateNameCache): Merged findProperties since this was the only caller.
(WebCore::HTMLPropertiesCollection::names):
(WebCore::HTMLPropertiesCollection::namedItem):
(WebCore::HTMLPropertiesCollection::hasNamedItem):
* html/HTMLPropertiesCollection.h:
(HTMLPropertiesCollection): Made updateRefElements public as it's called in HTMLCollectionWithArrayStorage::item.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122345 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Gtk] allow building with css-filters
https://bugs.webkit.org/show_bug.cgi?id=90908

.:

Add support for css-filters in Source/WebCore/GNUmakefile.am
configure.ac

Patch by Arnaud Renevier <a.renevier@sisa.samsung.com> on 2012-07-11
Reviewed by Eric Seidel.

* configure.ac:

Source/WebCore:

Patch by Arnaud Renevier <a.renevier@sisa.samsung.com> on 2012-07-11
Reviewed by Eric Seidel.

Add support for css-filters in Source/WebCore/GNUmakefile.am
configure.ac

No functional change, so no new tests.

* GNUmakefile.am:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122346 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Simplify the copying of JSC ARMv7's LinkRecord
https://bugs.webkit.org/show_bug.cgi?id=90930

Patch by Benjamin Poulain <bpoulain@apple.com> on 2012-07-11
Reviewed by Filip Pizlo.

The class LinkRecord is used by value everywhere in ARMv7Assembler. The compiler uses
memmove() to move the objects.

The problem is memmove() is overkill for this object, moving the value can be done with
3 load-store. This patch adds an operator= to the class doing more efficient copying.
This reduces the link time by 19%.

* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::LinkRecord::LinkRecord):
(JSC::ARMv7Assembler::LinkRecord::operator=):
(JSC::ARMv7Assembler::LinkRecord::from):
(JSC::ARMv7Assembler::LinkRecord::setFrom):
(JSC::ARMv7Assembler::LinkRecord::to):
(JSC::ARMv7Assembler::LinkRecord::type):
(JSC::ARMv7Assembler::LinkRecord::linkType):
(JSC::ARMv7Assembler::LinkRecord::setLinkType):
(JSC::ARMv7Assembler::LinkRecord::condition):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122347 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed build fix, forgot to add URLTestHelpers.* when landing r122344

* tests/URLTestHelpers.cpp: Added.
(URLTestHelpers):
(WebKit::URLTestHelpers::registerMockedURLFromBaseURL):
(WebKit::URLTestHelpers::registerMockedURLLoad):
* tests/URLTestHelpers.h: Added.
(WebKit):
(URLTestHelpers):
(WebKit::URLTestHelpers::toKURL):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122348 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Gtk] fast/events/keydown-function-keys.html is failing
https://bugs.webkit.org/show_bug.cgi?id=90891

Reviewed by Martin Robinson.

Work around the context menu being shown on F10 key being pressed by
unbiding the key when running tests in DumpRenderTree. The problem
appears when using a recent version of the xkeyboard-config package.

* DumpRenderTree/gtk/DumpRenderTree.cpp:
(setDefaultsToConsistentStateValuesForTesting):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122349 268f45cc-cd09-0410-ab3c-d52691b4dbfc
<http://webkit.org/b/90835> Teach bisect-builds to work with a Safari.app that has entitlements.

Reviewed by Dan Bernstein.

* Scripts/bisect-builds: Use safariPathFromSafariBundle to determine which binary within the application
should be invoked.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122350 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add a performance test for hit testing in SVG
https://bugs.webkit.org/show_bug.cgi?id=90811

Reviewed by Ryosuke Niwa.

The shape rendering code is changing a lot and I'd like a performance test to
make sure we don't regress, and to track our improvements.

Performance results in my Linux desktop:
    RESULT SVG: SvgHitTesting= 105.0 ms
    median= 103.5 ms, stdev= 4.60434577329 ms, min= 101.0 ms, max= 116.0 ms

    RESULT SVG: SvgHitTesting= 97.8 ms
    median= 96.5 ms, stdev= 2.67581763205 ms, min= 95.0 ms, max= 102.0 ms

    RESULT SVG: SvgHitTesting= 104.3 ms
    median= 104.0 ms, stdev= 1.41774468788 ms, min= 102.0 ms, max= 107.0 ms

    RESULT SVG: SvgHitTesting= 103.6 ms
    median= 103.5 ms, stdev= 1.2 ms, min= 102.0 ms, max= 106.0 ms

* SVG/SvgHitTesting.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122351 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add a Mountain Lion version of libWebKitSystemInterface.a.

Source/WebKit/mac:

Reviewed by John Sullivan.

* Configurations/DebugRelease.xcconfig: Look for the library under its expected name.

Source/WebKit2:

Reviewed by John Sullivan.

* Configurations/DebugRelease.xcconfig: Look for the library under its expected name.

Tools:

Reviewed by John Sullivan.

* Scripts/copy-webkitlibraries-to-product-directory: Include libWebKitSystemInterfaceMountainLion.a in the list of libraries to copy.

WebKitLibraries:

Update the WebKitSystemInterface header and binaries.

Reviewed by John Sullivan.

* WebKitSystemInterface.h:
* libWebKitSystemInterfaceLion.a:
* libWebKitSystemInterfaceMountainLion.a: Added.
* libWebKitSystemInterfaceSnowLeopard.a:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122352 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Clang build fix after r122345.
Also let XCode do its own thing.

* WebCore.xcodeproj/project.pbxproj:
* html/HTMLCollection.cpp:
(WebCore::HTMLCollectionWithArrayStorage::item):
* html/HTMLCollection.h:
(HTMLCollectionWithArrayStorage):
* html/HTMLFormCollection.cpp:
(WebCore::HTMLFormCollection::itemInArrayAfter):
* html/HTMLFormCollection.h:
(HTMLFormCollection):
* html/HTMLPropertiesCollection.cpp:
(WebCore::HTMLPropertiesCollection::itemInArrayAfter):
* html/HTMLPropertiesCollection.h:
(HTMLPropertiesCollection):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122353 268f45cc-cd09-0410-ab3c-d52691b4dbfc
TileCache layers have wrong border debug color
https://bugs.webkit.org/show_bug.cgi?id=90922

Reviewed by Simon Fraser.

Source/WebCore:

Commit r122152 updated the layer hierarchy when a tile
cache is being used by the view. As part of that, GraphicsLayerClient::shouldUseTileCache()
was changed to return false in some situations (the idea was that it
should only be called from the createGraphicsLayer method). However
there were two other call points: one that sets the debug colors on
borders, the other was a call that keeps the document background in sync.

Add a new method usingTileCache() that returns the current state. Also fix
a FIXME where the debug code always called into the client rather than
caching the value on the GraphicsLayer.

Test: compositing/document-background-color.html

* platform/graphics/GraphicsLayer.cpp:
(WebCore::GraphicsLayer::GraphicsLayer):
(WebCore::GraphicsLayer::updateDebugIndicators): check the local variable when
setting the debug colors.
* platform/graphics/GraphicsLayer.h:
(GraphicsLayer): new bool member variable m_usingTileCache.
* platform/graphics/GraphicsLayerClient.h:
(WebCore::GraphicsLayerClient::usingTileCache): new virtual method to query if
this client is actually using the tile cache.
* platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::GraphicsLayerCA): set the member variable m_usingTileCache
if the GraphicsLayerClient says we are.
* rendering/RenderLayerBacking.h:
(WebCore::RenderLayerBacking::usingTileCache):
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::documentBackgroundColorDidChange): call usingTileCache()
rather than shouldUseTileCache(), because the latter's value might not always reflect
the existence of a cache.

LayoutTests:

Make sure that the document background color is updated
when using a Tile Cache.

* compositing/document-background-color-expected.html: Added.
* compositing/document-background-color.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122354 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt][WK2] Test actual rendering results in API tests
https://bugs.webkit.org/show_bug.cgi?id=80609

Reviewed by Alexis Menard.

Added a very basic test to tst_QQuickWebView to make sure rendering actually occurs.

* UIProcess/API/qt/tests/qquickwebview/tst_qquickwebview.cpp:
(tst_QQuickWebView):
(tst_QQuickWebView::basicRenderingSanity):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122355 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add -Wtautological-compare and -Wsign-compare warning flags
https://bugs.webkit.org/show_bug.cgi?id=90994

Reviewed by Mark Rowe.

Source/JavaScriptCore:

* Configurations/Base.xcconfig:

Source/WebCore:

* Configurations/Base.xcconfig:

Source/WebKit/mac:

* Configurations/Base.xcconfig:

Source/WebKit2:

* Configurations/Base.xcconfig:

Source/WTF:

* Configurations/Base.xcconfig:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add MIPS convertibleLoadPtr and other functions
https://bugs.webkit.org/show_bug.cgi?id=90714

Patch by Chao-ying Fu <fu@mips.com> on 2012-07-11
Reviewed by Oliver Hunt.

* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::labelIgnoringWatchpoints):
(MIPSAssembler):
(JSC::MIPSAssembler::replaceWithLoad):
(JSC::MIPSAssembler::replaceWithAddressComputation):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::convertibleLoadPtr):
(MacroAssemblerMIPS):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122357 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Remove drag and drop API methods that are no longer used
https://bugs.webkit.org/show_bug.cgi?id=90996

Reviewed by Adam Barth.

Source/WebKit/chromium:

In r117327, we added a parameter for modifier keys to these methods.
Chromium has since switched to using the methods that require the
extra parameter so we can remove these methods.

* public/WebView.h:
(WebView):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::dragTargetDragEnter):
(WebKit::WebViewImpl::dragTargetDragOver):
* src/WebViewImpl.h:
(WebViewImpl):

Tools:

Migrate DRT to use the methods that take modifier keys.

* DumpRenderTree/chromium/EventSender.cpp:
(EventSender::doDragDrop):
(EventSender::doMouseUp):
(EventSender::doMouseMove):
(EventSender::beginDragWithFiles):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122358 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Enable LEGACY_VIEWPORT_ADAPTION
https://bugs.webkit.org/show_bug.cgi?id=90991

Reviewed by Tony Chang.

Source/WebKit/chromium:

Chromium wishes to support LEGACY_VIEWPORT_ADAPTION. I actually thought
this was enabled before, but the enable bit got lost in the shuffle.

* features.gypi:

LayoutTests:

These tests pass now that we've enabled this feature.

* platform/chromium/TestExpectations:


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