DumpRenderTree generates white snapshots on some platforms
https://bugs.webkit.org/show_bug.cgi?id=132026
<rdar://problem/16679363>

Reviewed by Simon Fraser.

* DumpRenderTree/mac/Configurations/DumpRenderTree.xcconfig:
Link DRT against QuartzCore.

* DumpRenderTree/mac/PixelDumpSupportMac.mm:
(createBitmapContextFromWebView):
Force CoreAnimation to synchronously update layers in a more explicit
way that doesn't depend on AppKit behavior. This is very similar to what
WebKitTestRunner does (indirectly) during its force repaint.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167687 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rollout r156635 since the old behavior was intentional.


Source/WebCore: 
* page/EventHandler.cpp:
(WebCore::EventHandler::selectCursor):

LayoutTests: 
* editing/caret/selection-with-caret-type-progress-expected.txt: Removed.
* editing/caret/selection-with-caret-type-progress.html: Removed.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167688 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r157328): popover to check into flight ba.com dismisses instantly when focusing form
https://bugs.webkit.org/show_bug.cgi?id=131949

Reviewed by Darin Adler.

Source/WebCore:
The regression was caused by two bugs:
1. The event didn't stop propagating itself even when it should.
   If the related target is same as the event origin, the event propagation should stop when the event reaches
   the root of the related target's tree scope. Otherwise, it should stop when it reaches the related target.

2. Mouse event's related target exposed nodes inside a user-agent shadow DOM when the related target appeared
   inside the origin.

Fixed the bugs by re-introducing path shrinkage algorithm removed in r157328 into EventPath::setRelatedTarget
and adding an algorithm to determine the least common ancestor of the related target and the current target
in moveToParentOrShadowHost. The latter algorithm doesn't match the shadow DOM specification:
http://www.w3.org/TR/2013/WD-shadow-dom-20130514/
but it's good enough in terms of the Web exposed behavior as we don't support author defined insertion points.

Test: fast/events/shadow-event-path.html

* dom/EventDispatcher.cpp:
(WebCore::EventRelatedNodeResolver::moveToParentOrShadowHost):
(WebCore::EventRelatedNodeResolver::findHostOfTreeScopeInTargetTreeScope): Added.
(WebCore::EventDispatcher::dispatchEvent):
(WebCore::EventPath::setRelatedTarget):

LayoutTests:
Add a test that dumps the event target and the related target of every mouse event
when dispatched inside an input element inside a details element.

This catches the regression as well as other bugs I encountered while fixing the bug.

We need a WK2 specific results because WK1 mac results contain an extra fake mouse move event.

* fast/events/shadow-event-path-expected.txt: Added.
* fast/events/shadow-event-path.html: Added.
* platform/mac-wk2/fast/events/shadow-event-expected.txt: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167689 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: iOS hit-testing does not work when page is zoomed
https://bugs.webkit.org/show_bug.cgi?id=132013

Reviewed by Simon Fraser.

Implement accessibilityHitTest so that the point can be converted correctly.

* WebProcess/WebPage/WKAccessibilityWebPageObjectIOS.mm:
(-[WKAccessibilityWebPageObject accessibilityHitTest:]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167690 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DumpRenderTree generates black snapshots on some platforms
https://bugs.webkit.org/show_bug.cgi?id=132029
<rdar://problem/16679363>

Reviewed by Simon Fraser.

* DumpRenderTree/mac/PixelDumpSupportMac.mm:
(createBitmapContextFromWebView):
DRT checks with the WebView to determine whether it can use the window's
backing store directly or (because of compositing) needs to take a WindowServer
snapshot. However, on some platforms and in some situations, the window can
be layer backed without the WebView necessarily currently being composited.
We should check with the window in addition to the WebView before going
ahead and using its backing store.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167691 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DFG::Worklist should acquire the m_lock before iterating DFG plans.
<https://webkit.org/b/132032>

Reviewed by Filip Pizlo.

Currently, there's a rightToRun mechanism that ensures that no compilation
threads are running when the GC is iterating through the DFG worklists.
However, this does not prevent a Worker thread from doing a DFG compilation
and modifying the plans in the worklists thereby invalidating the plan
iterator that the GC is using.  This patch fixes the issue by acquiring
the worklist m_lock before iterating the worklist plans.

This issue was uncovered by running the fast/workers layout tests with
COLLECT_ON_EVERY_ALLOCATION enabled.

* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::visitChildren):



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