Title: [254581] branches/safari-609-branch
Revision
254581
Author
alanc...@apple.com
Date
2020-01-15 11:14:21 -0800 (Wed, 15 Jan 2020)

Log Message

Cherry-pick r254042. rdar://problem/58549102

    Source/WebCore/PAL:
    DumpRenderTree doesn't always call updateRendering() when a test completes
    https://bugs.webkit.org/show_bug.cgi?id=205761

    Reviewed by Darin Adler.

    Add -[CATransaction synchronize].

    * pal/spi/cocoa/QuartzCoreSPI.h:

    Source/WebKit:
    DumpRenderTree doesn't always call updateRendering() when a test completes
    https://bugs.webkit.org/show_bug.cgi?id=205761

    Reviewed by Darin Adler.

    Use the QuartzCore SPI header.

    * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:

    Source/WebKitLegacy/mac:
    Fix a souce of WebKit1 test flakiness
    https://bugs.webkit.org/show_bug.cgi?id=205761

    Reviewed by Darin Adler.

    Some animation tests (and possibly many others) are flakey or broken in WK1 because
    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
    time.

    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
    and flushes a CATransaction.

    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
    changes, and WebCore changes that make more things happen with HTML event loop timing, this
    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
    WK2 is doing.

    * WebView/WebView.mm:
    (-[WebView _forceRepaintForTesting]):
    * WebView/WebViewPrivate.h:

    Tools:
    DumpRenderTree doesn't always call updateRendering() when a test completes
    https://bugs.webkit.org/show_bug.cgi?id=205761

    Reviewed by Darin Adler.

    Some animation tests (and possibly many others) are flakey or broken in WK1 because
    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
    time.

    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
    and flushes a CATransaction.

    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
    changes, and WebCore changes that make more things happen with HTML event loop timing, this
    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
    WK2 is doing.

    * DumpRenderTree/mac/DumpRenderTree.mm:
    (updateDisplay):
    * DumpRenderTree/mac/PixelDumpSupportMac.mm:

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

Modified Paths

Diff

Modified: branches/safari-609-branch/LayoutTests/platform/mac-wk1/TestExpectations (254580 => 254581)


--- branches/safari-609-branch/LayoutTests/platform/mac-wk1/TestExpectations	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/LayoutTests/platform/mac-wk1/TestExpectations	2020-01-15 19:14:21 UTC (rev 254581)
@@ -809,6 +809,7 @@
 
 # No support for reftest-wait in DRT.
 imported/w3c/web-platform-tests/html/semantics/forms/the-input-element/range-setattribute-value.html [ ImageOnlyFailure ]
+imported/w3c/web-platform-tests/css/css-display/display-none-inline-img.html [ ImageOnlyFailure ]
 
 # <rdar://problem/42625657> REGRESSION (Mojave): 12 fast/images tests timing out on WK1
 [ Mojave+ ] fast/images/animated-heics-draw.html [ Skip ]

Modified: branches/safari-609-branch/Source/WebCore/PAL/ChangeLog (254580 => 254581)


--- branches/safari-609-branch/Source/WebCore/PAL/ChangeLog	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebCore/PAL/ChangeLog	2020-01-15 19:14:21 UTC (rev 254581)
@@ -1,3 +1,86 @@
+2020-01-14  Alan Coon  <alanc...@apple.com>
+
+        Cherry-pick r254042. rdar://problem/58549102
+
+    Source/WebCore/PAL:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Add -[CATransaction synchronize].
+    
+    * pal/spi/cocoa/QuartzCoreSPI.h:
+    
+    Source/WebKit:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Use the QuartzCore SPI header.
+    
+    * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
+    
+    Source/WebKitLegacy/mac:
+    Fix a souce of WebKit1 test flakiness
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * WebView/WebView.mm:
+    (-[WebView _forceRepaintForTesting]):
+    * WebView/WebViewPrivate.h:
+    
+    Tools:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * DumpRenderTree/mac/DumpRenderTree.mm:
+    (updateDisplay):
+    * DumpRenderTree/mac/PixelDumpSupportMac.mm:
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@254042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    2020-01-05  Simon Fraser  <simon.fra...@apple.com>
+
+            DumpRenderTree doesn't always call updateRendering() when a test completes
+            https://bugs.webkit.org/show_bug.cgi?id=205761
+
+            Reviewed by Darin Adler.
+
+            Add -[CATransaction synchronize].
+
+            * pal/spi/cocoa/QuartzCoreSPI.h:
+
 2020-01-13  Alan Coon  <alanc...@apple.com>
 
         Cherry-pick r254257. rdar://problem/58530962

Modified: branches/safari-609-branch/Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h (254580 => 254581)


--- branches/safari-609-branch/Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h	2020-01-15 19:14:21 UTC (rev 254581)
@@ -141,6 +141,7 @@
 @interface CATransaction ()
 + (void)addCommitHandler:(void(^)(void))block forPhase:(CATransactionPhase)phase;
 + (CATransactionPhase)currentPhase;
++ (void)synchronize;
 @end
 
 @interface CALayerHost : CALayer

Modified: branches/safari-609-branch/Source/WebKit/ChangeLog (254580 => 254581)


--- branches/safari-609-branch/Source/WebKit/ChangeLog	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebKit/ChangeLog	2020-01-15 19:14:21 UTC (rev 254581)
@@ -1,5 +1,88 @@
 2020-01-14  Alan Coon  <alanc...@apple.com>
 
+        Cherry-pick r254042. rdar://problem/58549102
+
+    Source/WebCore/PAL:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Add -[CATransaction synchronize].
+    
+    * pal/spi/cocoa/QuartzCoreSPI.h:
+    
+    Source/WebKit:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Use the QuartzCore SPI header.
+    
+    * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
+    
+    Source/WebKitLegacy/mac:
+    Fix a souce of WebKit1 test flakiness
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * WebView/WebView.mm:
+    (-[WebView _forceRepaintForTesting]):
+    * WebView/WebViewPrivate.h:
+    
+    Tools:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * DumpRenderTree/mac/DumpRenderTree.mm:
+    (updateDisplay):
+    * DumpRenderTree/mac/PixelDumpSupportMac.mm:
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@254042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    2020-01-05  Simon Fraser  <simon.fra...@apple.com>
+
+            DumpRenderTree doesn't always call updateRendering() when a test completes
+            https://bugs.webkit.org/show_bug.cgi?id=205761
+
+            Reviewed by Darin Adler.
+
+            Use the QuartzCore SPI header.
+
+            * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
+
+2020-01-14  Alan Coon  <alanc...@apple.com>
+
         Cherry-pick r254033. rdar://problem/58548645
 
     Reformat WebPage logging

Modified: branches/safari-609-branch/Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm (254580 => 254581)


--- branches/safari-609-branch/Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm	2020-01-15 19:14:21 UTC (rev 254581)
@@ -66,10 +66,6 @@
 #import <WebCore/ScrollingTree.h>
 #endif
 
-@interface CATransaction (Details)
-+ (void)synchronize;
-@end
-
 namespace WebKit {
 using namespace WebCore;
 

Modified: branches/safari-609-branch/Source/WebKitLegacy/mac/ChangeLog (254580 => 254581)


--- branches/safari-609-branch/Source/WebKitLegacy/mac/ChangeLog	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebKitLegacy/mac/ChangeLog	2020-01-15 19:14:21 UTC (rev 254581)
@@ -1,3 +1,99 @@
+2020-01-14  Alan Coon  <alanc...@apple.com>
+
+        Cherry-pick r254042. rdar://problem/58549102
+
+    Source/WebCore/PAL:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Add -[CATransaction synchronize].
+    
+    * pal/spi/cocoa/QuartzCoreSPI.h:
+    
+    Source/WebKit:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Use the QuartzCore SPI header.
+    
+    * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
+    
+    Source/WebKitLegacy/mac:
+    Fix a souce of WebKit1 test flakiness
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * WebView/WebView.mm:
+    (-[WebView _forceRepaintForTesting]):
+    * WebView/WebViewPrivate.h:
+    
+    Tools:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * DumpRenderTree/mac/DumpRenderTree.mm:
+    (updateDisplay):
+    * DumpRenderTree/mac/PixelDumpSupportMac.mm:
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@254042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    2020-01-05  Simon Fraser  <simon.fra...@apple.com>
+
+            Fix a souce of WebKit1 test flakiness
+            https://bugs.webkit.org/show_bug.cgi?id=205761
+
+            Reviewed by Darin Adler.
+
+            Some animation tests (and possibly many others) are flakey or broken in WK1 because
+            there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+            time.
+
+            WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+            and flushes a CATransaction.
+
+            In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+            and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+            changes, and WebCore changes that make more things happen with HTML event loop timing, this
+            approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+            WK2 is doing.
+
+            * WebView/WebView.mm:
+            (-[WebView _forceRepaintForTesting]):
+            * WebView/WebViewPrivate.h:
+
 2020-01-03  Yusuke Suzuki  <ysuz...@apple.com>
 
         Put more WebCore/WebKit JS objects into IsoSubspace

Modified: branches/safari-609-branch/Source/WebKitLegacy/mac/WebView/WebView.mm (254580 => 254581)


--- branches/safari-609-branch/Source/WebKitLegacy/mac/WebView/WebView.mm	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebKitLegacy/mac/WebView/WebView.mm	2020-01-15 19:14:21 UTC (rev 254581)
@@ -232,6 +232,7 @@
 #import <pal/spi/cocoa/NSTouchBarSPI.h>
 #import <pal/spi/cocoa/NSURLDownloadSPI.h>
 #import <pal/spi/cocoa/NSURLFileTypeMappingsSPI.h>
+#import <pal/spi/cocoa/QuartzCoreSPI.h>
 #import <pal/spi/mac/NSResponderSPI.h>
 #import <pal/spi/mac/NSSpellCheckerSPI.h>
 #import <pal/spi/mac/NSViewSPI.h>
@@ -4768,6 +4769,19 @@
     viewGroup->userContentController().removeAllUserContent();
 }
 
+- (void)_forceRepaintForTesting
+{
+#if PLATFORM(IOS_FAMILY)
+    // Ensure fixed positions layers are where they should be.
+    [self _synchronizeCustomFixedPositionLayoutRect];
+#endif
+
+    [self _viewWillDrawInternal];
+    [self _flushCompositingChanges];
+    [CATransaction flush];
+    [CATransaction synchronize];
+}
+
 - (BOOL)allowsNewCSSAnimationsWhileSuspended
 {
     auto* frame = core([self mainFrame]);

Modified: branches/safari-609-branch/Source/WebKitLegacy/mac/WebView/WebViewPrivate.h (254580 => 254581)


--- branches/safari-609-branch/Source/WebKitLegacy/mac/WebView/WebViewPrivate.h	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Source/WebKitLegacy/mac/WebView/WebViewPrivate.h	2020-01-15 19:14:21 UTC (rev 254581)
@@ -817,6 +817,7 @@
 
 // SPI for DumpRenderTree
 + (void)_setLoadResourcesSerially:(BOOL)serialize;
+- (void)_forceRepaintForTesting;
 
 /*!
     @method cssAnimationsSuspended

Modified: branches/safari-609-branch/Tools/ChangeLog (254580 => 254581)


--- branches/safari-609-branch/Tools/ChangeLog	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Tools/ChangeLog	2020-01-15 19:14:21 UTC (rev 254581)
@@ -1,3 +1,99 @@
+2020-01-14  Alan Coon  <alanc...@apple.com>
+
+        Cherry-pick r254042. rdar://problem/58549102
+
+    Source/WebCore/PAL:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Add -[CATransaction synchronize].
+    
+    * pal/spi/cocoa/QuartzCoreSPI.h:
+    
+    Source/WebKit:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Use the QuartzCore SPI header.
+    
+    * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
+    
+    Source/WebKitLegacy/mac:
+    Fix a souce of WebKit1 test flakiness
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * WebView/WebView.mm:
+    (-[WebView _forceRepaintForTesting]):
+    * WebView/WebViewPrivate.h:
+    
+    Tools:
+    DumpRenderTree doesn't always call updateRendering() when a test completes
+    https://bugs.webkit.org/show_bug.cgi?id=205761
+    
+    Reviewed by Darin Adler.
+    
+    Some animation tests (and possibly many others) are flakey or broken in WK1 because
+    there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+    time.
+    
+    WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+    and flushes a CATransaction.
+    
+    In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+    and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+    changes, and WebCore changes that make more things happen with HTML event loop timing, this
+    approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+    WK2 is doing.
+    
+    * DumpRenderTree/mac/DumpRenderTree.mm:
+    (updateDisplay):
+    * DumpRenderTree/mac/PixelDumpSupportMac.mm:
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@254042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    2020-01-05  Simon Fraser  <simon.fra...@apple.com>
+
+            DumpRenderTree doesn't always call updateRendering() when a test completes
+            https://bugs.webkit.org/show_bug.cgi?id=205761
+
+            Reviewed by Darin Adler.
+
+            Some animation tests (and possibly many others) are flakey or broken in WK1 because
+            there was no code to guarantee that Page::updateRendering() was called at notifyDone()
+            time.
+
+            WK2 calls DrawingArea::forceRepaint(), which does updateRendering(), flushes layers,
+            and flushes a CATransaction.
+
+            In WK1, we historically relied in AppKit to call -viewWillDraw on WebView and/or WebHTMLView,
+            and just called [webView display] to make this happen. However, with layer backing, AppKit behavior
+            changes, and WebCore changes that make more things happen with HTML event loop timing, this
+            approach no longer works. The fix is to add WebView SPI, _forceRepaintForTesting, which emulates what
+            WK2 is doing.
+
+            * DumpRenderTree/mac/DumpRenderTree.mm:
+            (updateDisplay):
+            * DumpRenderTree/mac/PixelDumpSupportMac.mm:
+
 2020-01-13  Alan Coon  <alanc...@apple.com>
 
         Cherry-pick r254440. rdar://problem/58530962

Modified: branches/safari-609-branch/Tools/DumpRenderTree/mac/DumpRenderTree.mm (254580 => 254581)


--- branches/safari-609-branch/Tools/DumpRenderTree/mac/DumpRenderTree.mm	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Tools/DumpRenderTree/mac/DumpRenderTree.mm	2020-01-15 19:14:21 UTC (rev 254581)
@@ -89,6 +89,7 @@
 #import <WebKit/WebPreferencesPrivate.h>
 #import <WebKit/WebResourceLoadDelegate.h>
 #import <WebKit/WebStorageManagerPrivate.h>
+#import <WebKit/WebView.h>
 #import <WebKit/WebViewPrivate.h>
 #import <getopt.h>
 #import <wtf/Assertions.h>
@@ -1721,6 +1722,7 @@
     [gDrtWindow layoutTilesNow];
     [webView _flushCompositingChanges];
 #else
+    [webView _forceRepaintForTesting];
     if ([webView _isUsingAcceleratedCompositing])
         [webView display];
     else

Modified: branches/safari-609-branch/Tools/DumpRenderTree/mac/PixelDumpSupportMac.mm (254580 => 254581)


--- branches/safari-609-branch/Tools/DumpRenderTree/mac/PixelDumpSupportMac.mm	2020-01-15 19:14:14 UTC (rev 254580)
+++ branches/safari-609-branch/Tools/DumpRenderTree/mac/PixelDumpSupportMac.mm	2020-01-15 19:14:21 UTC (rev 254581)
@@ -37,6 +37,7 @@
 #import <CoreGraphics/CGBitmapContext.h>
 #import <QuartzCore/QuartzCore.h>
 #import <pal/spi/cg/CoreGraphicsSPI.h>
+#import <pal/spi/cocoa/QuartzCoreSPI.h>
 #import <wtf/Assertions.h>
 #import <wtf/RefPtr.h>
 
@@ -46,10 +47,6 @@
 #import <WebKit/WebKit.h>
 #import <WebKit/WebViewPrivate.h>
 
-@interface CATransaction ()
-+ (void)synchronize;
-@end
-
 @interface WebView ()
 - (BOOL)_flushCompositingChanges;
 @end
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to