[webkit-changes] [WebKit/WebKit] deaa47: Fix build with stricter C warnings

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: deaa47fe6ecc1573fb4801446bb932b836a9d350
  
https://github.com/WebKit/WebKit/commit/deaa47fe6ecc1573fb4801446bb932b836a9d350
  Author: Simon Fraser 
  Date:   2022-10-05 (Wed, 05 Oct 2022)

  Changed paths:
M 
Source/ThirdParty/libwebrtc/Source/third_party/libsrtp/crypto/kernel/crypto_kernel.c
M Source/ThirdParty/libwebrtc/Source/third_party/libsrtp/crypto/kernel/err.c
M Source/ThirdParty/libwebrtc/Source/third_party/libsrtp/srtp/srtp.c
M Source/ThirdParty/libwebrtc/Source/third_party/pffft/src/pffft.c
M 
Source/ThirdParty/libwebrtc/Source/third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_pcb.c
M 
Source/ThirdParty/libwebrtc/Source/third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_sysctl.c
M Source/bmalloc/libpas/src/libpas/pas_large_sharing_pool.c
M 
Source/bmalloc/libpas/src/libpas/pas_probabilistic_guard_malloc_allocator.c
M Source/bmalloc/libpas/src/libpas/pas_thread_local_cache.c
M Source/bmalloc/libpas/src/libpas/pas_thread_local_cache_layout.c
M Source/bmalloc/libpas/src/libpas/pas_utils.c

  Log Message:
  ---
  Fix build with stricter C warnings
https://bugs.webkit.org/show_bug.cgi?id=246133
rdar://100835228

Unreviewed build fixes.

* 
Source/ThirdParty/libwebrtc/Source/third_party/libsrtp/crypto/kernel/crypto_kernel.c:
(srtp_crypto_kernel_status):
(srtp_crypto_kernel_list_debug_modules):
(srtp_crypto_kernel_shutdown):
* Source/ThirdParty/libwebrtc/Source/third_party/libsrtp/crypto/kernel/err.c:
(srtp_err_reporting_init):
* Source/ThirdParty/libwebrtc/Source/third_party/libsrtp/srtp/srtp.c:
(srtp_get_version_string):
(srtp_get_version):
(srtp_init):
(srtp_shutdown):
* Source/ThirdParty/libwebrtc/Source/third_party/pffft/src/pffft.c:
(validate_pffft_simd):
(pffft_simd_size):
* 
Source/ThirdParty/libwebrtc/Source/third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_pcb.c:
* 
Source/ThirdParty/libwebrtc/Source/third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_sysctl.c:
(sctp_init_sysctls):
* Source/bmalloc/libpas/src/libpas/pas_large_sharing_pool.c:
(boot_tree):
* Source/bmalloc/libpas/src/libpas/pas_probabilistic_guard_malloc_allocator.c:
(pas_probabilistic_guard_malloc_get_free_virtual_memory):
(pas_probabilistic_guard_malloc_get_free_wasted_memory):
* Source/bmalloc/libpas/src/libpas/pas_thread_local_cache.c:
(scavenger_thread_suspend_data_create):
* Source/bmalloc/libpas/src/libpas/pas_thread_local_cache_layout.c:
(pas_thread_local_cache_layout_get_last_node):
* Source/bmalloc/libpas/src/libpas/pas_utils.c:
(pas_panic_on_out_of_memory_error):

Canonical link: https://commits.webkit.org/255208@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 263b32: Have the DrawingAreaProxy control `delegatesScroll...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 263b327294f3c5e15fe23efd03d499cde6284569
  
https://github.com/WebKit/WebKit/commit/263b327294f3c5e15fe23efd03d499cde6284569
  Author: Simon Fraser 
  Date:   2022-10-10 (Mon, 10 Oct 2022)

  Changed paths:
M Source/WebKit/UIProcess/API/mac/WKContentViewMac.mm
M Source/WebKit/UIProcess/DrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WKContentView.mm

  Log Message:
  ---
  Have the DrawingAreaProxy control `delegatesScrolling` in the UI process
https://bugs.webkit.org/show_bug.cgi?id=246243
rdar://100924685

Reviewed by Chris Dumez.

Move the notion of `delegatesScrolling` from WebPageProxy to DrawingAreaProxy, 
since this is presentation-related.
This was only actually used in RemoteLayerTreeDrawingAreaProxy to control the 
indicator position, but future patches will make more use of it.

Also have the DrawingAreaProxy be the factory for the 
RemoteScrollingCoordinatorProxy.

* Source/WebKit/UIProcess/API/mac/WKContentViewMac.mm:
(-[WKContentView initWithFrame:page:]): No need to call 
setDelegatesScrolling(); this is derived from the DrawingAreaProxy.
* Source/WebKit/UIProcess/DrawingAreaProxy.h:
(WebKit::DrawingAreaProxy::usesDelegatedScrolling const):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::createScrollingCoordinatorProxy 
const):
(WebKit::RemoteLayerTreeDrawingAreaProxy::indicatorLocation const): 
RemoteLayerTreeDrawingAreaProxy always uses delegated scrolling so remove the 
condition.
(WebKit::RemoteLayerTreeDrawingAreaProxy::updateDebugIndicator): Ditto
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::setDrawingArea):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView _commonInitializationWithProcessPool:configuration:]): No need 
to call setDelegatesScrolling(); this is derived from the DrawingAreaProxy.

Canonical link: https://commits.webkit.org/255356@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] cfc548: Turn 'delegates scrolling' into an enum

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: cfc548338e845e58f76d89f9af85bdd1b85ab657
  
https://github.com/WebKit/WebKit/commit/cfc548338e845e58f76d89f9af85bdd1b85ab657
  Author: Simon Fraser 
  Date:   2022-10-11 (Tue, 11 Oct 2022)

  Changed paths:
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
M Source/WebCore/platform/ScrollView.cpp
M Source/WebCore/platform/ScrollView.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/testing/Internals.cpp
M Source/WebKit/UIProcess/DrawingAreaProxy.cpp
M Source/WebKit/UIProcess/DrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebPage/DrawingArea.cpp
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h
M Source/WebKitLegacy/mac/WebCoreSupport/WebFrameLoaderClient.mm

  Log Message:
  ---
  Turn 'delegates scrolling' into an enum
https://bugs.webkit.org/show_bug.cgi?id=246299
rdar://100995741

Reviewed by Tim Horton.

'delegatesScrolling' currently assumes that whatever is taking over scrolling 
provides scrollbars.
With UI-side compositing on macOS, we want to continue to have WebCore create 
scrollbars, so this
bool needs to be more fine-grained.

This change converts the bool into an enum class with three values: 
NotDelegated,
DelegatedToNativeScrollView, DelegatedToWebKit. Most code continues to work as 
before
by testing mode != NotDelegated, but we use DelegatedToWebKit to control 
whether scrollbars
are created.

Both DrawingArea, and DrawingAreaProxy have delegatedScrollingMode(), and 
RemoteLayerTreeDrawingArea*
override the default to return `DelegatedToNativeScrollView`. A future subclass 
will use
`DelegatedToWebKit`.

* Source/WebCore/page/FrameView.cpp:
(WebCore::FrameView::delegatedScrollingModeDidChange):
(WebCore::FrameView::delegatesScrollingDidChange): Deleted.
* Source/WebCore/page/FrameView.h:
* Source/WebCore/platform/ScrollView.cpp:
(WebCore::ScrollView::setDelegatedScrollingMode):
(WebCore::ScrollView::managesScrollbars const):
(WebCore::ScrollView::setDelegatesScrolling): Deleted.
* Source/WebCore/platform/ScrollView.h:
(WebCore::ScrollView::delegatedScrollingMode const):
(WebCore::ScrollView::delegatesScrolling const):
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresScrollLayer const):
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::setDelegatesScrolling):
* Source/WebKit/UIProcess/DrawingAreaProxy.cpp:
(WebKit::DrawingAreaProxy::delegatedScrollingMode const):
* Source/WebKit/UIProcess/DrawingAreaProxy.h:
(WebKit::DrawingAreaProxy::usesDelegatedScrolling const): Deleted.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::delegatedScrollingMode const):
* Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::transitionToCommittedForNewPage):
* Source/WebKit/WebProcess/WebPage/DrawingArea.cpp:
(WebKit::DrawingArea::delegatedScrollingMode const):
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::supportsAsyncScrolling const):
(WebKit::DrawingArea::usesDelegatedScrolling const): Deleted.
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h:
* 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::delegatedScrollingMode const):
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h:
* Source/WebKitLegacy/mac/WebCoreSupport/WebFrameLoaderClient.mm:
(WebFrameLoaderClient::transitionToCommittedForNewPage):

Canonical link: https://commits.webkit.org/255382@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1e3571: Fix the TestWebKitAPI build

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1e35717fd27f15190bb4f5287be1c3eb531fa6a3
  
https://github.com/WebKit/WebKit/commit/1e35717fd27f15190bb4f5287be1c3eb531fa6a3
  Author: Simon Fraser 
  Date:   2022-10-11 (Tue, 11 Oct 2022)

  Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm

  Log Message:
  ---
  Fix the TestWebKitAPI build
https://bugs.webkit.org/show_bug.cgi?id=246360
rdar://101046614

Unreviewed build fix.

Need to import TestNavigationDelegate.h.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm:

Canonical link: https://commits.webkit.org/255397@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 21ff04: Have DisplayLink use IPC::Connection::UniqueID, ra...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 21ff04706f4f15f6d82110254309d225306dcd5b
  
https://github.com/WebKit/WebKit/commit/21ff04706f4f15f6d82110254309d225306dcd5b
  Author: Simon Fraser 
  Date:   2022-10-11 (Tue, 11 Oct 2022)

  Changed paths:
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/UIProcess/WebProcessPool.h
M Source/WebKit/UIProcess/mac/DisplayLink.cpp
M Source/WebKit/UIProcess/mac/DisplayLink.h

  Log Message:
  ---
  Have DisplayLink use IPC::Connection::UniqueID, rather than IPC::Connection
https://bugs.webkit.org/show_bug.cgi?id=246320
rdar://101014516

Reviewed by Chris Dumez.

DisplayLink doesn't need to know anything about the details of IPC::Connection;
it just needs a unique identifier to use as a hash key, so change it to use
IPC::Connection::UniqueID.

Also make a collection class to hold the set of DisplayLinks, so it's easier
to move them out of WebProcessPool at some point.

* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::nominalFramesPerSecondForDisplay):
(WebKit::WebProcessPool::startDisplayLink):
(WebKit::WebProcessPool::stopDisplayLink):
(WebKit::WebProcessPool::stopDisplayLinks):
(WebKit::WebProcessPool::setDisplayLinkPreferredFramesPerSecond):
(WebKit::WebProcessPool::setDisplayLinkForDisplayWantsFullSpeedUpdates):
* Source/WebKit/UIProcess/WebProcessPool.h:
* Source/WebKit/UIProcess/mac/DisplayLink.cpp:
(WebKit::DisplayLink::addObserver):
(WebKit::DisplayLink::removeObserver):
(WebKit::DisplayLink::removeObservers):
(WebKit::DisplayLink::removeInfoForConnectionIfPossible):
(WebKit::DisplayLink::incrementFullSpeedRequestClientCount):
(WebKit::DisplayLink::decrementFullSpeedRequestClientCount):
(WebKit::DisplayLink::setPreferredFramesPerSecond):
(WebKit::DisplayLinkCollection::displayLinkForDisplay const):
(WebKit::DisplayLinkCollection::add):
* Source/WebKit/UIProcess/mac/DisplayLink.h:
(WebKit::DisplayLinkCollection::displayLinks const):

Canonical link: https://commits.webkit.org/255404@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3abb69: Add RemoteLayerTreeDrawingAreaMac, RemoteLayerTree...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3abb691bf7d83e6730ed76a80b4b2286ae0d0e89
  
https://github.com/WebKit/WebKit/commit/3abb691bf7d83e6730ed76a80b4b2286ae0d0e89
  Author: Simon Fraser 
  Date:   2022-10-11 (Tue, 11 Oct 2022)

  Changed paths:
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
A 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
A 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
A 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
A 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebPage/DrawingArea.cpp
A Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.h
A Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.mm

  Log Message:
  ---
  Add RemoteLayerTreeDrawingAreaMac, RemoteLayerTreeDrawingAreaProxyMac and 
RemoteScrollingCoordinatorProxyMac
https://bugs.webkit.org/show_bug.cgi?id=246363
rdar://101048413

Reviewed by Tim Horton.

Add 'Mac' subclasses to RemoteLayerTreeDrawingArea{Proxy}, and 
RemoteScrollingCoordinatorProx, which will
handle macOS-specific code for UI-side compositing.

* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
 Added.
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
 Added.
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::RemoteLayerTreeDrawingAreaProxyMac):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::delegatedScrollingMode const):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::createScrollingCoordinatorProxy 
const):
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h:
 Added.
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
 Added.
(WebKit::RemoteScrollingCoordinatorProxyMac::RemoteScrollingCoordinatorProxyMac):
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::createDrawingAreaProxy):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/WebPage/DrawingArea.cpp:
(WebKit::DrawingArea::create):
* Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.h: Added.
* Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.mm: Added.
(WebKit::RemoteLayerTreeDrawingAreaMac::RemoteLayerTreeDrawingAreaMac):
(WebKit::RemoteLayerTreeDrawingAreaMac::delegatedScrollingMode const):

Canonical link: https://commits.webkit.org/255411@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8cf25e: Add RemoteLayerTreeDrawingAreaProxyIOS

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8cf25e21bf554b6f1849c2da1b5fcdc0b99b541c
  
https://github.com/WebKit/WebKit/commit/8cf25e21bf554b6f1849c2da1b5fcdc0b99b541c
  Author: Simon Fraser 
  Date:   2022-10-13 (Thu, 13 Oct 2022)

  Changed paths:
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
A 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.h
A 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M Source/WebKit/UIProcess/ios/WKContentView.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  ---
  Add RemoteLayerTreeDrawingAreaProxyIOS
https://bugs.webkit.org/show_bug.cgi?id=246439
rdar://101109019

Reviewed by Tim Horton.

Add RemoteLayerTreeDrawingAreaProxyIOS and move the WKOneShotDisplayLinkHandler 
code into it.

Remove another #ifdef by overriding didChangeViewExposedRect()
in RemoteLayerTreeDrawingAreaProxyMac.

* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
(WebKit::RemoteLayerTreeDrawingAreaProxy::scheduleDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxy::pauseDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxy::setPreferredFramesPerSecond):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::RemoteLayerTreeDrawingAreaProxy):
(WebKit::RemoteLayerTreeDrawingAreaProxy::~RemoteLayerTreeDrawingAreaProxy):
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
(WebKit::RemoteLayerTreeDrawingAreaProxy::didRefreshDisplay):
(-[WKOneShotDisplayLinkHandler initWithDrawingAreaProxy:]): Deleted.
(-[WKOneShotDisplayLinkHandler dealloc]): Deleted.
(-[WKOneShotDisplayLinkHandler setPreferredFramesPerSecond:]): Deleted.
(-[WKOneShotDisplayLinkHandler displayLinkFired:]): Deleted.
(-[WKOneShotDisplayLinkHandler timerFired]): Deleted.
(-[WKOneShotDisplayLinkHandler invalidate]): Deleted.
(-[WKOneShotDisplayLinkHandler schedule]): Deleted.
(-[WKOneShotDisplayLinkHandler pause]): Deleted.
(WebKit::RemoteLayerTreeDrawingAreaProxy::delegatedScrollingMode const): 
Deleted.
(WebKit::RemoteLayerTreeDrawingAreaProxy::displayLinkHandler): Deleted.
(WebKit::RemoteLayerTreeDrawingAreaProxy::setPreferredFramesPerSecond): Deleted.
(WebKit::RemoteLayerTreeDrawingAreaProxy::didChangeViewExposedRect): Deleted.
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.h:
 Copied from 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h.
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm:
 Added.
(-[WKOneShotDisplayLinkHandler initWithDrawingAreaProxy:]):
(-[WKOneShotDisplayLinkHandler dealloc]):
(-[WKOneShotDisplayLinkHandler setPreferredFramesPerSecond:]):
(-[WKOneShotDisplayLinkHandler displayLinkFired:]):
(-[WKOneShotDisplayLinkHandler timerFired]):
(-[WKOneShotDisplayLinkHandler invalidate]):
(-[WKOneShotDisplayLinkHandler schedule]):
(-[WKOneShotDisplayLinkHandler pause]):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::RemoteLayerTreeDrawingAreaProxyIOS):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::~RemoteLayerTreeDrawingAreaProxyIOS):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::delegatedScrollingMode const):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::displayLinkHandler):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::setPreferredFramesPerSecond):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::scheduleDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::pauseDisplayLink):
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::didChangeViewExposedRect):
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView _createDrawingAreaProxy:]): Create a 
RemoteLayerTreeDrawingAreaProxyIOS.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:

Canonical link: https://commits.webkit.org/255484@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 78ad3a: Hook up temporary timer-based displayDidRefresh in...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 78ad3a86bab5f481ce06414ade4e68b97e8eb9c2
  
https://github.com/WebKit/WebKit/commit/78ad3a86bab5f481ce06414ade4e68b97e8eb9c2
  Author: Simon Fraser 
  Date:   2022-10-14 (Fri, 14 Oct 2022)

  Changed paths:
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm

  Log Message:
  ---
  Hook up temporary timer-based displayDidRefresh in 
RemoteLayerTreeDrawingAreaProxyMac
https://bugs.webkit.org/show_bug.cgi?id=246531


Reviewed by Tim Horton.

Hook up a timer in RemoteLayerTreeDrawingAreaProxyMac to drive display refresh 
as an
interim solution until DisplayLink is hooked up.

* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::RemoteLayerTreeDrawingAreaProxyMac):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::scheduleDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::pauseDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::displayLinkTimerFired):

Canonical link: https://commits.webkit.org/255547@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f306cd: Make basic scrolling work with ui-side compositing...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f306cd3129105493472bc6d46832ee32a81ca072
  
https://github.com/WebKit/WebKit/commit/f306cd3129105493472bc6d46832ee32a81ca072
  Author: Simon Fraser 
  Date:   2022-10-17 (Mon, 17 Oct 2022)

  Changed paths:
M 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm

  Log Message:
  ---
  Make basic scrolling work with ui-side compositing on macOS
https://bugs.webkit.org/show_bug.cgi?id=246640


Reviewed by Tim Horton.

We already send wheel events to the scrolling tree, but there was no layer 
movement
because we never changed layer positions; this is because with web process 
scrolling
there is coordination with the main thread in the form of scroll 
synchronization.

So add code to manually update layer positions with UI-side compositing. This 
will
be refined as we bring up a scrolling thread in the UI process.

* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::handleWheelEvent):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTree const):
(WebKit::RemoteScrollingCoordinatorProxy::didReceiveWheelEvent):
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
(WebKit::RemoteScrollingCoordinatorProxyMac::didReceiveWheelEvent):

Canonical link: https://commits.webkit.org/255643@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 22dc64: Introduce platform-specific subclasses of RemoteSc...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 22dc6498963e547b90ff34d67b7635c1ef2acb59
  
https://github.com/WebKit/WebKit/commit/22dc6498963e547b90ff34d67b7635c1ef2acb59
  Author: Simon Fraser 
  Date:   2022-10-21 (Fri, 21 Oct 2022)

  Changed paths:
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h
A Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingTreeIOS.cpp
A Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingTreeIOS.h
A Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.cpp
A Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h
M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  ---
  Introduce platform-specific subclasses of RemoteScrollingTree
https://bugs.webkit.org/show_bug.cgi?id=246834
rdar://101405405

Reviewed by Tim Horton.

Add RemoteScrollingTreeIOS and RemoteScrollingTreeMac.

* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp:
(WebKit::RemoteScrollingTree::createScrollingTreeNode):
(WebKit::RemoteScrollingTree::create): Deleted.
(WebKit::RemoteScrollingTree::handleWheelEventPhase): Deleted.
(WebKit::RemoteScrollingTree::scrollingTreeNodeWillStartPanGesture): Deleted.
(WebKit::RemoteScrollingTree::scrollingTreeNodeWillStartScroll): Deleted.
(WebKit::RemoteScrollingTree::scrollingTreeNodeDidEndScroll): Deleted.
(WebKit::RemoteScrollingTree::handleMouseEvent): Deleted.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h:
(WebKit::RemoteScrollingTree::handleMouseEvent):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingTreeIOS.cpp: Added.
(WebKit::RemoteScrollingTree::create):
(WebKit::RemoteScrollingTreeIOS::RemoteScrollingTreeIOS):
(WebKit::RemoteScrollingTreeIOS::scrollingTreeNodeWillStartPanGesture):
(WebKit::RemoteScrollingTreeIOS::scrollingTreeNodeWillStartScroll):
(WebKit::RemoteScrollingTreeIOS::scrollingTreeNodeDidEndScroll):
(WebKit::RemoteScrollingTreeIOS::createScrollingTreeNode):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingTreeIOS.h: Added.
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.cpp: Added.
(WebKit::RemoteScrollingTree::create):
(WebKit::RemoteScrollingTreeMac::RemoteScrollingTreeMac):
(WebKit::RemoteScrollingTreeMac::handleWheelEventPhase):
(WebKit::RemoteScrollingTreeMac::createScrollingTreeNode):
(WebKit::RemoteScrollingTreeMac::handleMouseEvent):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h: Copied 
from Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:

Canonical link: https://commits.webkit.org/255843@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ec3a1f: Send `windowScreenDidChange` to the DrawingAreaProxy

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ec3a1f77af5b7c0815937ca4e82d3e050f49ac21
  
https://github.com/WebKit/WebKit/commit/ec3a1f77af5b7c0815937ca4e82d3e050f49ac21
  Author: Simon Fraser 
  Date:   2022-10-22 (Sat, 22 Oct 2022)

  Changed paths:
M Source/WebKit/UIProcess/DrawingAreaProxy.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h

  Log Message:
  ---
  Send `windowScreenDidChange` to the DrawingAreaProxy
https://bugs.webkit.org/show_bug.cgi?id=246778
rdar://101357455

Reviewed by Tim Horton.

Mac's DrawingAreaProxy is going to want to hear about windowScreenDidChange
in the near future.

* Source/WebKit/UIProcess/DrawingAreaProxy.h:
(WebKit::DrawingAreaProxy::windowScreenDidChange):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::windowScreenDidChange):
* Source/WebKit/UIProcess/WebPageProxy.h:

Canonical link: https://commits.webkit.org/255880@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6ee106: Rename some functions related to display refresh

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6ee1068d110acc9c299bf3e017a3ef192e4157a4
  
https://github.com/WebKit/WebKit/commit/6ee1068d110acc9c299bf3e017a3ef192e4157a4
  Author: Simon Fraser 
  Date:   2022-10-22 (Sat, 22 Oct 2022)

  Changed paths:
M 
Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M Source/WebKit/UIProcess/wc/DrawingAreaProxyWC.cpp
M 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
M 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.h
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
M Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.cpp
M Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h

  Log Message:
  ---
  Rename some functions related to display refresh
https://bugs.webkit.org/show_bug.cgi?id=246897
rdar://101451193

Reviewed by Ryosuke Niwa.

DrawingArea::didUpdate() -> DrawingArea::displayDidRefresh()
This is the primary driver of web process "displayDidRefresh" in the 
RemoteLayerTree
world; it was called DrawingArea::didUpdate() because, for a long commit, 
we did call it
to indicate that the last one has completed. But it's more common behavior 
is the
display refresh signal from the UI process.

RemoteLayerTreeDisplayRefreshMonitor::didUpdateLayers() -> 
RemoteLayerTreeDisplayRefreshMonitor::triggerDisplayDidRefresh()
Similar to above, this only meant "did update layers" in the "missed 
commit" scenario.
Normally it just means "trigger DisplayRefreshMonitor::displayDidRefresh".
I made triggerDisplayDidRefresh() private to make it clear that the 
friended RemoteLayerTreeDrawingArea
should be the only caller.

WKOneShotDisplayLinkHandler -> WKDisplayLinkHandler
It isn't one-shot.

RemoteLayerTreeDrawingAreaProxy::scheduleDisplayLink/pauseDisplayLink -> 
RemoteLayerTreeDrawingAreaProxy::scheduleDisplayRefreshCallbacks/pauseDisplayRefreshCallbacks
On macOS (which has additional needs for a display link in the UI process 
in addition to just
notifying the web process) this doesn't directly correspond with 
starting/pausing a DisplayLink.

I did not attempt to unify displayDidRefresh/didRefreshDisplay, both of which 
we use.

* 
Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:
(WebKit::DrawingAreaProxyCoordinatedGraphics::update):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
(WebKit::RemoteLayerTreeDrawingAreaProxy::scheduleDisplayRefreshCallbacks):
(WebKit::RemoteLayerTreeDrawingAreaProxy::pauseDisplayRefreshCallbacks):
(WebKit::RemoteLayerTreeDrawingAreaProxy::scheduleDisplayLink): Deleted.
(WebKit::RemoteLayerTreeDrawingAreaProxy::pauseDisplayLink): Deleted.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
(WebKit::RemoteLayerTreeDrawingAreaProxy::didRefreshDisplay):
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::displayLinkHandler):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::scheduleDisplayRefreshCallbacks):
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::pauseDisplayRefreshCallbacks):
(-[WKOneShotDisplayLinkHandler initWithDrawingAreaProxy:]): Deleted.
(-[WKOneShotDisplayLinkHandler dealloc]): Deleted.
(-[WKOneShotDisplayLinkHandler setPreferredFramesPerSecond:]): Deleted.
(-[WKOneShotDisplayLinkHandler displayLinkFired:]): Deleted.
(-[WKOneShotDisplayLinkHandler timerFired]): Deleted.
(-[WKOneShotDisplayLinkHandler invalidate]): Deleted.
(-[WKOneShotDisplayLinkHandler schedule]): Deleted.
(-[WKOneShotDisplayLinkHandler pause]): Deleted.
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::scheduleDisplayLink): Deleted.
(WebKit::RemoteLayerTr

[webkit-changes] [WebKit/WebKit] 524513: With macOS UI-side compositing, point-mapping in S...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5245130a89305c2bfa17d07f6f843e1073ccac6e
  
https://github.com/WebKit/WebKit/commit/5245130a89305c2bfa17d07f6f843e1073ccac6e
  Author: Simon Fraser 
  Date:   2022-10-24 (Mon, 24 Oct 2022)

  Changed paths:
M Source/WebCore/platform/ScrollView.cpp
M Source/WebCore/platform/ScrollView.h

  Log Message:
  ---
  With macOS UI-side compositing, point-mapping in ScrollView should map 
through the scroll position
https://bugs.webkit.org/show_bug.cgi?id=246910
rdar://101468086

Reviewed by Tim Horton.

with macOS UI-side compositing, we'll continue to map coordinates through the
ScrollView's scroll position (and top content inset), as we do with web process
compositing. So the coordinate mapping functions in ScrollView should only
return early in the "scrolling handled by native view" case.

* Source/WebCore/platform/ScrollView.cpp:
(WebCore::ScrollView::setScrollPosition):
(WebCore::ScrollView::viewToContents const):
(WebCore::ScrollView::contentsToView const):
(WebCore::ScrollView::rootViewToTotalContents const):
* Source/WebCore/platform/ScrollView.h:
(WebCore::ScrollView::delegatesScrollingToNativeView const):

Canonical link: https://commits.webkit.org/255928@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] dd9846: Make programmatic scrolls work with macOS UI-side ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dd98466d9224ffcddac229571808009244d0df3c
  
https://github.com/WebKit/WebKit/commit/dd98466d9224ffcddac229571808009244d0df3c
  Author: Simon Fraser 
  Date:   2022-10-25 (Tue, 25 Oct 2022)

  Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm

  Log Message:
  ---
  Make programmatic scrolls work with macOS UI-side compositing
https://bugs.webkit.org/show_bug.cgi?id=246990
rdar://101529255

Reviewed by Tim Horton.

On iOS, where main frame scrolling is handled via the main UIScrollView, we had 
special behavior
in RemoteLayerTreeDrawingAreaProxy::commitLayerTree() to save any main frame 
requested
scrolls found during the scrolling tree commit, and apply them via 
WebPageProxy::requestScroll().

We don't need this on macOS, where requested scrolls on the main frame are 
handled exactly as they
are for subscrollers, so override scrollingTreeNodeRequestsScroll() to do 
nothing and return false.

* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
(WebKit::RemoteScrollingCoordinatorProxyMac::scrollingTreeNodeRequestsScroll):

Canonical link: https://commits.webkit.org/255965@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 0ca300: Prepare DisplayLink to support UI-side compositing

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0ca300a709eed3e70130a5e13cab0e5b5887b9b6
  
https://github.com/WebKit/WebKit/commit/0ca300a709eed3e70130a5e13cab0e5b5887b9b6
  Author: Simon Fraser 
  Date:   2022-10-25 (Tue, 25 Oct 2022)

  Changed paths:
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Source/WebKit/UIProcess/mac/DisplayLink.cpp
M Source/WebKit/UIProcess/mac/DisplayLink.h
A Source/WebKit/UIProcess/mac/DisplayLinkProcessProxyClient.cpp
A Source/WebKit/UIProcess/mac/DisplayLinkProcessProxyClient.h
M Source/WebKit/UIProcess/mac/WebProcessProxyMac.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm

  Log Message:
  ---
  Prepare DisplayLink to support UI-side compositing
https://bugs.webkit.org/show_bug.cgi?id=246694
rdar://101296426

Reviewed by Chris Dumez.

The DisplayLink class has clients (currently denoted by 
IPC::Connection::UniqueID), and each client
has a collection of DisplayLinkObserverID, whose values are only unique in that 
context of that client.
In addition, each client has some extra state in the form of "wants full speed 
updates" which is used
for 120Hz scrolling animations and event handling.

With UI-side compositing, we'll need a client in the UI process. So replace 
IPC::Connection::UniqueID
with a Client class. For web process clients, DisplayLinkProcessProxyClient 
implements DisplayLink::Client,
and handles the IPC to the web process. WebProcessProxy owns an instance of 
DisplayLinkProcessProxyClient.
Getting WebProcessProxy's IPC connection isn't thread-safe, so we cache the 
IPC::Connection on
the main thread. DisplayLink::Client is accessed via a thread-safe CheckedPtr<> 
to catch lifetime
issues.

* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::startDisplayLink):
(WebKit::WebProcessPool::stopDisplayLink):
(WebKit::WebProcessPool::stopDisplayLinks):
(WebKit::WebProcessPool::setDisplayLinkPreferredFramesPerSecond):
(WebKit::WebProcessPool::setDisplayLinkForDisplayWantsFullSpeedUpdates):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::updateDisplayLinkFrequency):
(WebKit::WebPageProxy::windowScreenDidChange):
* Source/WebKit/UIProcess/WebProcessPool.h:
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::~WebProcessProxy):
(WebKit::WebProcessProxy::connectionWillOpen):
(WebKit::WebProcessProxy::processWillShutDown):
* Source/WebKit/UIProcess/WebProcessProxy.h:
(WebKit::WebProcessProxy::displayLinkClient):
* Source/WebKit/UIProcess/mac/DisplayLink.cpp:
(WebKit::DisplayLink::addObserver):
(WebKit::DisplayLink::removeObserver):
(WebKit::DisplayLink::removeClient):
(WebKit::DisplayLink::removeInfoForClientIfUnused):
(WebKit::DisplayLink::incrementFullSpeedRequestClientCount):
(WebKit::DisplayLink::decrementFullSpeedRequestClientCount):
(WebKit::DisplayLink::setObserverPreferredFramesPerSecond):
(WebKit::DisplayLink::notifyObserversDisplayWasRefreshed):
(WebKit::DisplayLink::removeObservers): Deleted.
(WebKit::DisplayLink::removeInfoForConnectionIfPossible): Deleted.
(WebKit::DisplayLink::setPreferredFramesPerSecond): Deleted.
* Source/WebKit/UIProcess/mac/DisplayLink.h:
(WebKit::DisplayLink::displayID const):
(WebKit::DisplayLink::setShouldSendIPCOnBackgroundQueue): Deleted.
* Source/WebKit/UIProcess/mac/DisplayLinkProcessProxyClient.cpp: Added.
(WebKit::DisplayLinkProcessProxyClient::setConnection):
(WebKit::DisplayLinkProcessProxyClient::displayLinkFired):
* Source/WebKit/UIProcess/mac/DisplayLinkProcessProxyClient.h: Added.
* Source/WebKit/UIProcess/mac/WebProcessProxyMac.mm:
(WebKit::WebProcessProxy::startDisplayLink):
(WebKit::WebProcessProxy::stopDisplayLink):
(WebKit::WebProcessProxy::setDisplayLinkPreferredFramesPerSecond):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm:
(WebKit::RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback):

Canonical link: https://commits.webkit.org/255970@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5c7651: Clean up code related to how TiledCoreAnimationDra...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5c7651583d44479b0fca3344e7bed756889ca8bd
  
https://github.com/WebKit/WebKit/commit/5c7651583d44479b0fca3344e7bed756889ca8bd
  Author: Simon Fraser 
  Date:   2022-10-26 (Wed, 26 Oct 2022)

  Changed paths:
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreeTransaction.mm
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm

  Log Message:
  ---
  Clean up code related to how TiledCoreAnimationDrawingArea gets layers for 
zooming and shadow
https://bugs.webkit.org/show_bug.cgi?id=247047
rdar://101575253

Reviewed by Antti Koivisto.

TiledCoreAnimationDrawingArea shouldn't be in the business of groveling around 
in
RenderView, RenderLayers and RenderLayerBackings for specific layers, so have
FrameView vend those layers as GraphicsLayers.

* Source/WebCore/page/FrameView.cpp:
(WebCore::FrameView::graphicsLayerForPageScale):
(WebCore::FrameView::graphicsLayerForTransientZoomShadow):
* Source/WebCore/page/FrameView.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreeTransaction.mm:
(WebKit::RemoteLayerTreeTransaction::dump const): Use WTFLogAlways() not 
fprintf().
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::updateDebugInfoLayer):
(WebKit::TiledCoreAnimationDrawingArea::layerForTransientZoom const):
(WebKit::TiledCoreAnimationDrawingArea::shadowLayerForTransientZoom const):
(WebKit::TiledCoreAnimationDrawingArea::adjustTransientZoom):

Canonical link: https://commits.webkit.org/256026@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 972d19: Drive macOS RemoteLayerTreeDrawingAreaProxy update...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 972d19fa6e3366d294c4a2735c8d931d8f41f0d2
  
https://github.com/WebKit/WebKit/commit/972d19fa6e3366d294c4a2735c8d931d8f41f0d2
  Author: Simon Fraser 
  Date:   2022-10-31 (Mon, 31 Oct 2022)

  Changed paths:
M Source/WebCore/page/scrolling/ScrollingTree.cpp
M Source/WebCore/page/scrolling/ScrollingTree.h
M Source/WebCore/page/scrolling/ThreadedScrollingTree.cpp
M Source/WebCore/page/scrolling/ThreadedScrollingTree.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebProcessPool.h
M Source/WebKit/UIProcess/mac/DisplayLink.h

  Log Message:
  ---
  Drive macOS RemoteLayerTreeDrawingAreaProxy updates from a DisplayLink
https://bugs.webkit.org/show_bug.cgi?id=247222
rdar://101704617

Reviewed by Tim Horton.

Replace the timer-based `displayDidRefresh` updates in 
RemoteLayerTreeDrawingAreaProxyMac with ones
driven from a DisplayLink.

RemoteLayerTreeDrawingAreaProxyMac owns a RemoteLayerTreeDisplayLinkClient, 
which receives `displayLinkFired()`
off the main thread; this bounces to the main thread, looking up the target 
DrawingAreaProxy via a WebPageProxyIdentifier
(to avoid the need to use WeakPtr across threads, or extend object lifetime). 
RemoteLayerTreeDrawingAreaProxyMac
uses m_displayRefreshObserverID to identify its primary observer, used to drive 
displayDidRefresh() which ultimately
drives rendering updates.

RemoteLayerTreeDrawingAreaProxyMac has a second observer identified with 
m_fullSpeedUpdateObserverID which
is only active when the scrolling tree has animations (e.g. rubber-banding); 
this observer will request
120Hz on capable displays. Future changes will ensure that 120Hz updates get 
filtered out of the rendering
update pipeline as appropriate. (This avoids use of 
DisplayLink::{increment,decrement}FullSpeedRequestClientCount
used for web process compositing, which was a mistake.)

RemoteLayerTreeDrawingAreaProxyMac::windowScreenDidChange() has to respond by 
unregistering
observers on the DisplayLink for the old display, and re-registering them for 
the new one.

`serviceScrollAnimations()` is moved from ThreadedScrollingTree to 
ScrollingTree so we can call
it from RemoteScrollingCoordinatorProxy. RemoteScrollingCoordinatorProxyMac 
also needs an override
so we actually apply layer positions after the scroll animations run.

`hasNodeWithAnimatedScrollChanged` is hooked up as the signal to start/stop the 
m_fullSpeedUpdateObserverID.

WebPageProxy::displayId() is renamed to WebPageProxy::displayID().

* Source/WebCore/page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::serviceScrollAnimations):
* Source/WebCore/page/scrolling/ScrollingTree.h:
(WebCore::ScrollingTree::displayDidRefresh):
* Source/WebCore/page/scrolling/ThreadedScrollingTree.cpp:
(WebCore::ThreadedScrollingTree::serviceScrollAnimations): Deleted.
* Source/WebCore/page/scrolling/ThreadedScrollingTree.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
(WebKit::RemoteLayerTreeDrawingAreaProxy::setDisplayLinkWantsFullSpeedUpdates):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::displayDidRefresh):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::hasNodeWithAnimatedScrollChanged):
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm:
(-[WKDisplayLinkHandler initWithDrawingAreaProxy:]):
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDisplayLinkClient::displayLinkFired):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::RemoteLayerTreeDrawingAreaProxyMac):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::~RemoteLayerTreeDrawingAreaProxyMac):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::exisingDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::ensureDisplayLink):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::removeObserver

[webkit-changes] [WebKit/WebKit] 742f3d: compositing/iframes/border-radius-composited-frame...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 742f3d602a1d04c948c60b75e2ba418263a475df
  
https://github.com/WebKit/WebKit/commit/742f3d602a1d04c948c60b75e2ba418263a475df
  Author: Simon Fraser 
  Date:   2022-10-31 (Mon, 31 Oct 2022)

  Changed paths:
M LayoutTests/compositing/iframes/border-radius-composited-frame.html
M LayoutTests/platform/mac/TestExpectations

  Log Message:
  ---
  compositing/iframes/border-radius-composited-frame.html fails sometimes
https://bugs.webkit.org/show_bug.cgi?id=247300
rdar://80333071

Unreviewed test gardening.

Add some tiny pixel tolerance for this test.

* LayoutTests/compositing/iframes/border-radius-composited-frame.html:
* LayoutTests/platform/mac/TestExpectations:

Canonical link: https://commits.webkit.org/256184@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5172b1: Crash trying to scroll a main frame PDF with UI-si...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5172b1f269aa0858f847212a28a0ba9d608f78b4
  
https://github.com/WebKit/WebKit/commit/5172b1f269aa0858f847212a28a0ba9d608f78b4
  Author: Simon Fraser 
  Date:   2022-11-01 (Tue, 01 Nov 2022)

  Changed paths:
M Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp

  Log Message:
  ---
  Crash trying to scroll a main frame PDF with UI-side compositing on macOS.
https://bugs.webkit.org/show_bug.cgi?id=247302
rdar://101786249

Reviewed by Tim Horton.

Null check the scrolling tree before stuffing it into a map (with UI-side 
compositing
and PDF it can be null).

* Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp:
(WebKit::EventDispatcher::addScrollingTreeForPage):

Canonical link: https://commits.webkit.org/256199@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c91af3: REGRESSION (STP): Animating image inside clipping ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c91af32319e79e687c345bf10927febf64d42476
  
https://github.com/WebKit/WebKit/commit/c91af32319e79e687c345bf10927febf64d42476
  Author: Simon Fraser 
  Date:   2022-11-01 (Tue, 01 Nov 2022)

  Changed paths:
A 
LayoutTests/compositing/clipping/clip-stack-hidden-and-radius-expected.html
A LayoutTests/compositing/clipping/clip-stack-hidden-and-radius.html
M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  ---
  REGRESSION (STP): Animating image inside clipping border-radius ignores 
overflow hidden
https://bugs.webkit.org/show_bug.cgi?id=245769
rdar://100514998

Reviewed by Alan Baradlay.

When composited layers are clipped by non-stacking-context ancestors, we build 
an "ancestor clipping stack"
to represent those clips. Contiguous sets of non-scrollable, non-radius clips 
can be collapsed into
a single entry as the intersection of the clip rects, which is what 
`pushNonScrollableClip()` does
in `RenderLayerCompositor::computeAncestorClippingStack()`.

While walking up the ancestor chain, if we encounter a clip-with-radius or 
overflow:scroll,
we need to push any pending non-scrollable clip, but the border-radius clause 
here failed
to do that, resulting in an incorrect attempt to push a clip with an infinite 
rect at
the end.

Fix by ensuring that the `hasBorderRadius()` clause calls 
`pushNonScrollableClip()` just as
the `hasCompositedScrollableOverflow()` one does.

* LayoutTests/compositing/clipping/clip-stack-hidden-and-radius-expected.html: 
Added.
* LayoutTests/compositing/clipping/clip-stack-hidden-and-radius.html: Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeAncestorClippingStack const):

Canonical link: https://commits.webkit.org/256202@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2bce58: IOSurface size limit in the web content process is...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2bce581d4f1001372d65013669aacbab23958371
  
https://github.com/WebKit/WebKit/commit/2bce581d4f1001372d65013669aacbab23958371
  Author: Simon Fraser 
  Date:   2022-11-05 (Sat, 05 Nov 2022)

  Changed paths:
M Source/WebCore/platform/graphics/IntSize.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm

  Log Message:
  ---
  IOSurface size limit in the web content process is too small, only 1024x1024
https://bugs.webkit.org/show_bug.cgi?id=247036
rdar://101569224

Reviewed by Tim Horton.

Have Cocoa platforms always call IOSurfaceGetPropertyMaximum() in the UI 
process to send to the web
process, rather than only doing so when DOM rendering in the GPU process is 
enabled (always true on iOS).
This was conditionalized in the past due to an iOS launch time regression, but 
we ate that regression
when we enabled DOM rendering by default.

Remove the iOS #ifdef that simply hardcoded the max surface sizes and use the 
value from the UI process.
Only use the hardcoded values as fallback (this can happen if a WKWebView 
client inadvertently has a
sandbox that makes the IOSurface calls fail).

On iOS platforms, we clamp the maximum IOSurface size to 8K (see 
rdar://101936907).

* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::fallbackMaxSurfaceDimension):
(WebCore::computeMaximumSurfaceSize):
(WebCore::maxSurfaceDimensionCA): Deleted.
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformInitializeWebProcess):
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):

Canonical link: https://commits.webkit.org/256359@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e618b6: Create RemoteScrollingCoordinatorProxyIOS

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e618b68f1b6a688be17db4c3b2b23de8f940bf45
  
https://github.com/WebKit/WebKit/commit/e618b68f1b6a688be17db4c3b2b23de8f940bf45
  Author: Simon Fraser 
  Date:   2022-11-05 (Sat, 05 Nov 2022)

  Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm
A 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  ---
  Create RemoteScrollingCoordinatorProxyIOS
https://bugs.webkit.org/show_bug.cgi?id=247518
rdar://101987258

Reviewed by Sam Weinig.

macOS subclassed RemoteScrollingCoordinatorProxy into 
RemoteScrollingCoordinatorProxyMac, so do the same
for iOS. This cleans up some #ifdeffed code.

The RemoteLayerTreeDrawingAreaProxy subclasses instantiate the correct type of 
RemoteScrollingCoordinatorProxy.

Define SPECIALIZE_TYPE_TRAITS so we can use downcast<> etc but have the 
predicate be compile-time.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView scrollViewWillBeginDragging:]):
(-[WKWebView scrollViewWillEndDragging:withVelocity:targetContentOffset:]):
(-[WKWebView _updateVisibleContentRects]):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::createScrollingCoordinatorProxy 
const): Deleted.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::layerTreeHost const):
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTreeNodeDidScroll):
(WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers): Deleted.
(WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations):
 Deleted.
(WebKit::RemoteScrollingCoordinatorProxy::activeTouchActionsForTouchIdentifier 
const): Deleted.
(WebKit::RemoteScrollingCoordinatorProxy::setTouchActionsForTouchIdentifier): 
Deleted.
(WebKit::RemoteScrollingCoordinatorProxy::clearTouchActionsForTouchIdentifier): 
Deleted.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::isRemoteScrollingCoordinatorProxyIOS 
const):
(WebKit::RemoteScrollingCoordinatorProxy::isRemoteScrollingCoordinatorProxyMac 
const):
(WebKit::RemoteScrollingCoordinatorProxy::propagatesMainFrameScrolls const):
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTreeNodeWillStartPanGesture):
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTreeNodeWillStartScroll):
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTreeNodeDidEndScroll):
(WebKit::RemoteScrollingCoordinatorProxy::setRootNodeIsInUserScroll):
(WebKit::RemoteScrollingCoordinatorProxy::setPropagatesMainFrameScrolls): 
Deleted.
(WebKit::RemoteScrollingCoordinatorProxy::fixedScrollingNodeLayerIDs const): 
Deleted.
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyIOS::createScrollingCoordinatorProxy 
const):
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.h:
 Added.
* 
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxyIOS::RemoteScrollingCoordinatorProxyIOS):
(WebKit::RemoteScrollingCoordinatorProxyIOS::activeTouchActionsForTouchIdentifier
 const):
(WebKit::RemoteScrollingCoordinatorProxyIOS::setTouchActionsForTouchIdentifier):
(WebKit::RemoteScrollingCoordinatorProxyIOS::clearTouchActionsForTouchIdentifier):
(WebKit::RemoteScrollingCoordinatorProxyIOS::scrollViewForScrollingNodeID 
const):
(WebKit::RemoteScrollingCoordinatorProxyIOS::removeFixedScrollingNodeLayerIDs):
(WebKit::RemoteScrollingCoordinatorProxyIOS::connectStateNodeLayers):
(WebKit::RemoteScrollingCoordinatorProxyIOS::currentLayoutViewport const):
(

[webkit-changes] [WebKit/WebKit] 68c7f6: Make RemoteScrollingTreeMac a .mm file

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 68c7f6ba4fee7075d8d896cac660fa929edb0415
  
https://github.com/WebKit/WebKit/commit/68c7f6ba4fee7075d8d896cac660fa929edb0415
  Author: Simon Fraser 
  Date:   2022-11-07 (Mon, 07 Nov 2022)

  Changed paths:
M Source/WebKit/SourcesCocoa.txt
R Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.cpp
A Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  ---
  Make RemoteScrollingTreeMac a .mm file
https://bugs.webkit.org/show_bug.cgi?id=247540

Reviewed by Sam Weinig.

Make RemoteScrollingTreeMac an Objective-C++ file (it will need to access 
CALayers later).

* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm: 
Renamed from 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.cpp.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:

Canonical link: https://commits.webkit.org/256407@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 962e90: Send ScrollingStateNode::asyncFrameOrOverflowScrol...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 962e90285327a10fb85e208d93439e4beb87521c
  
https://github.com/WebKit/WebKit/commit/962e90285327a10fb85e208d93439e4beb87521c
  Author: Simon Fraser 
  Date:   2022-11-07 (Mon, 07 Nov 2022)

  Changed paths:
M Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h
M 
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp

  Log Message:
  ---
  Send ScrollingStateNode::asyncFrameOrOverflowScrollingEnabled to the UI 
process
https://bugs.webkit.org/show_bug.cgi?id=247539

Reviewed by Antti Koivisto and Wenson Hsieh.

Scrolling tree code needs to consult asyncFrameOrOverflowScrollingEnabled in the
UI process so always encode/decode it.

* Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h:
* 
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
(ArgumentCoder::encode):
(ArgumentCoder::decode):

Canonical link: https://commits.webkit.org/256415@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9c7cd2: Use the correct colorspace for page layers when DO...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9c7cd20eac416ae96ff58b60cbe6ce671125395b
  
https://github.com/WebKit/WebKit/commit/9c7cd20eac416ae96ff58b60cbe6ce671125395b
  Author: Simon Fraser 
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
M 
Source/WebKit/Shared/RemoteLayerTree/RemoteLayerWithRemoteRenderingBackingStoreCollection.mm

  Log Message:
  ---
  Use the correct colorspace for page layers when DOM Rendering in GPU Process 
is enabled
https://bugs.webkit.org/show_bug.cgi?id=247601
rdar://102071086

Reviewed by Tim Horton.

Followup after 256361@main, which omitted a change in 
`RemoteLayerWithRemoteRenderingBackingStoreCollection::allocateBufferForBackingStore()`
which is necessary to pass the correct colorspace when creating buffers for 
page layers, when "DOM Rendering in GPU Process" is enabled.

* 
Source/WebKit/Shared/RemoteLayerTree/RemoteLayerWithRemoteRenderingBackingStoreCollection.mm:
(WebKit::RemoteLayerWithRemoteRenderingBackingStoreCollection::allocateBufferForBackingStore):

Canonical link: https://commits.webkit.org/256454@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c96806: Always push the colorspace into IOSurface metadata

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c968064ecdab458363753d6d6e4df0a63042076b
  
https://github.com/WebKit/WebKit/commit/c968064ecdab458363753d6d6e4df0a63042076b
  Author: Simon Fraser 
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
M Source/WebCore/platform/graphics/cocoa/GraphicsContextGLCocoa.mm
M Source/WebCore/platform/graphics/cocoa/IOSurface.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm

  Log Message:
  ---
  Always push the colorspace into IOSurface metadata
https://bugs.webkit.org/show_bug.cgi?id=247603
rdar://102074507

Reviewed by Tim Horton.

The colorspace argument to IOSurface constructors is currently only used by the 
CGContext creation
code, except for WebGL which pushes it into IOSurface metadata.

With UI-side compositing on macOS, it's important that the IOSurface colorspace 
information
survives the trip between processes, so we might as well always push it into 
IOSurface
metadata.

* Source/WebCore/platform/graphics/cocoa/GraphicsContextGLCocoa.mm:
(WebCore::GraphicsContextGLCocoa::allocateAndBindDisplayBufferBacking):
* Source/WebCore/platform/graphics/cocoa/IOSurface.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::IOSurface::IOSurface):
(WebCore::IOSurface::setColorSpaceProperty):
(WebCore::IOSurface::migrateColorSpaceToProperties): Deleted.

Canonical link: https://commits.webkit.org/256477@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f32cd1: With UI-side compositing enabled, some layout test...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f32cd174bbce9016b6789f19276d6fb13a12acac
  
https://github.com/WebKit/WebKit/commit/f32cd174bbce9016b6789f19276d6fb13a12acac
  Author: Simon Fraser 
  Date:   2022-11-10 (Thu, 10 Nov 2022)

  Changed paths:
M 
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp

  Log Message:
  ---
  With UI-side compositing enabled, some layout tests assert in 
WTF::isValidOptionSet(optionSet) encoding ScrollingStateNode::Property
https://bugs.webkit.org/show_bug.cgi?id=247764
rdar://102214098

Reviewed by Cameron McCormack.

Include the new `ScrollingStateNode::Property::KeyboardScrollData` value in
`EnumTraits`.

* 
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:

Canonical link: https://commits.webkit.org/256549@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 82e591: With UI-side compositing, many tests hit ASSERT(m_...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 82e5917868fa066744774abe4e292959f375fd02
  
https://github.com/WebKit/WebKit/commit/82e5917868fa066744774abe4e292959f375fd02
  Author: Simon Fraser 
  Date:   2022-11-11 (Fri, 11 Nov 2022)

  Changed paths:
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp
M Source/WebKit/WebProcess/WebPage/EventDispatcher.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm

  Log Message:
  ---
  With UI-side compositing, many tests hit 
ASSERT(m_scrollingTrees.contains(webPage->identifier()));
https://bugs.webkit.org/show_bug.cgi?id=247766
rdar://102214322

Reviewed by Cameron McCormack.

With UI-side compositing, the web process ScrollingCoordinator doesn't have a 
ScrollingTree,
so the assertion in `EventDispatcher::removeScrollingTreeForPage()` is wrong.

To fix this, delegate the registration and unregistration of the scrolling tree
to the DrawingArea. Then DrawingArea subclasses that have a WebContent process 
scrolling
tree can do the registration/unregistration (currently 
TiledCoreAnimationDrawingArea and
DrawingAreaCoordinatedGraphics).

Make the WebPage argument to the EventDispatcher functions be a reference.

* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::registerScrollingTree):
(WebKit::DrawingArea::unregisterScrollingTree):
* Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp:
(WebKit::EventDispatcher::addScrollingTreeForPage):
(WebKit::EventDispatcher::removeScrollingTreeForPage):
* Source/WebKit/WebProcess/WebPage/EventDispatcher.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::m_appHighlightsVisible):
(WebKit::WebPage::close):
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h:
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::registerScrollingTree):
(WebKit::TiledCoreAnimationDrawingArea::unregisterScrollingTree):

Canonical link: https://commits.webkit.org/256571@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8d6cca: Clarify the usage of the colorspace on IOSurface

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8d6ccacd0fbbb0dcc0719e096fc77bbaaa12976d
  
https://github.com/WebKit/WebKit/commit/8d6ccacd0fbbb0dcc0719e096fc77bbaaa12976d
  Author: Simon Fraser 
  Date:   2022-11-11 (Fri, 11 Nov 2022)

  Changed paths:
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebCore/platform/graphics/cocoa/IOSurface.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm
M Source/WebCore/platform/xr/PlatformXR.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm
M 
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBackend.cpp
M Source/WebKit/WebProcess/GPU/webrtc/SharedVideoFrame.cpp

  Log Message:
  ---
  Clarify the usage of the colorspace on IOSurface
https://bugs.webkit.org/show_bug.cgi?id=247776
rdar://102221177

Reviewed by Tim Horton.

The colorspace argument to `IOSurface::createFromSendRight()` was ambiguous; it 
would set `m_colorSpace`, but that
doesn't affect any metadata in the IOSurface; it's only used when drawing to 
that IOSurface. `createFromSurface()`
had a similar issue.

So remove the colorspace argument from `createFromSendRight()` and make 
`m_colorSpace` a `std::optional<>`;
this will remain unset unless one of the functions that requires a colorspace 
is called, at which point we'll
try to get the colorspace from the IOSurface metadata, falling back to sRGB.

`createFromSurface()` takes an optional DestinationColorSpace; this will 
replace the colorspace in the
IOSurface metadata (if any); if unset, we'll fetch the colorspace from the 
IOSurface metadata.

* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::setContents):
* Source/WebCore/platform/graphics/cocoa/IOSurface.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::IOSurface::createFromSendRight):
(WebCore::IOSurface::createFromSurface):
(WebCore::IOSurface::IOSurface):
(WebCore::IOSurface::createCompatibleBitmap):
(WebCore::IOSurface::ensurePlatformContext):
(WebCore::IOSurface::colorSpace):
(WebCore::IOSurface::setColorSpaceProperty):
(WebCore::IOSurface::ensureColorSpace):
(WebCore::IOSurface::surfaceColorSpace const):
* Source/WebCore/platform/xr/PlatformXR.h:
(PlatformXR::Device::FrameData::LayerData::decode):
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:
(WebKit::RemoteLayerBackingStore::applyBackingStoreToLayer):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm:
(WebKit::recursivelyMapIOSurfaceBackingStore):
* 
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBackend.cpp:
(WebKit::ImageBufferShareableMappedIOSurfaceBackend::create):
* Source/WebKit/WebProcess/GPU/webrtc/SharedVideoFrame.cpp:
(WebKit::SharedVideoFrameReader::readBuffer):

Canonical link: https://commits.webkit.org/256576@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 854716: Elements with `position: sticky` jitter inside a c...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 854716970c0750581f75ee43bb91578d9ac52451
  
https://github.com/WebKit/WebKit/commit/854716970c0750581f75ee43bb91578d9ac52451
  Author: Simon Fraser 
  Date:   2022-11-13 (Sun, 13 Nov 2022)

  Changed paths:
A 
LayoutTests/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt
A LayoutTests/compositing/clipping/sticky-inside-overflow-x-clip.html
A 
LayoutTests/platform/gtk/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt
A 
LayoutTests/platform/ios-wk2/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt
A 
LayoutTests/platform/mac-wk1/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt
M Source/WebCore/platform/graphics/LayoutRect.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  ---
  Elements with `position: sticky` jitter inside a container with `overflow-x: 
clip;`
https://bugs.webkit.org/show_bug.cgi?id=247130
rdar://101645570

Reviewed by Alan Baradlay.

`overflow:clip` on just one axis can output a clip rect which is infinite in 
just
x or y. In that case, we'd create a clipping layer with large floating point
geometry values which, when moved around by the scrolling tree, had low 
precision
resulting in visible stutters.

Fix by shrinking the infinite rect values by a factor of 16, which is sufficient
to provide enough device pixel precision for 3x displays.

* LayoutTests/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt: 
Added.
* LayoutTests/compositing/clipping/sticky-inside-overflow-x-clip.html: Added.
* 
LayoutTests/platform/gtk/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt:
 Added.
* 
LayoutTests/platform/ios-wk2/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt:
 Added.
* 
LayoutTests/platform/mac-wk1/compositing/clipping/sticky-inside-overflow-x-clip-expected.txt:
 Added.
* Source/WebCore/platform/graphics/LayoutRect.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeAncestorClippingStack const):

Canonical link: https://commits.webkit.org/256618@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 242980: REGRESSION (253809@main): Comment field on Engadge...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 24298004617128b4ce925aadf2af229de18deb7a
  
https://github.com/WebKit/WebKit/commit/24298004617128b4ce925aadf2af229de18deb7a
  Author: Simon Fraser 
  Date:   2022-11-13 (Sun, 13 Nov 2022)

  Changed paths:
A 
LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/composited-in-offscreen-fixed-expected.txt
A 
LayoutTests/scrollingcoordinator/scrolling-tree/composited-in-offscreen-fixed-expected.txt
A 
LayoutTests/scrollingcoordinator/scrolling-tree/composited-in-offscreen-fixed.html
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroll-coordinated-inside-fixed-expected.txt
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroll-coordinated-inside-fixed.html
M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  ---
  REGRESSION (253809@main): Comment field on Engadget.com exhibits stutters 
while scrolling
https://bugs.webkit.org/show_bug.cgi?id=247837
rdar://102066231

Reviewed by Alan Baradlay.

Various sites (khanacademy.org, comments on engadget.com) showed incorrectly 
scroll-coordinated elements,
typically positioned nodes inside overflow:scroll inside position:fixed. On 
some other sites, we'd hit an
assertion in 
RenderLayerCompositor::updateScrollingNodeForViewportConstrainedRole().

In all cases, we were trying to treat a layer that was some descendant of a 
position:fixed layer as if it
were the fixed layer itself, because of a logic error in 253809@main. The code 
in
`RenderLayerCompositor::isViewportConstrainedFixedOrStickyLayer()` needs to 
return early if the layer is
not both position:fixed, and behaving as fixed (i.e. no transformed ancestor).

Added two layout tests, both of which hit the assertion, and one of which 
showed incorrect scrolling
behavior.

* 
LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/composited-in-offscreen-fixed-expected.txt:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/composited-in-offscreen-fixed-expected.txt:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/composited-in-offscreen-fixed.html:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroll-coordinated-inside-fixed-expected.txt:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroll-coordinated-inside-fixed.html:
 Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::isViewportConstrainedFixedOrStickyLayer const):

Canonical link: https://commits.webkit.org/256619@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e1044d: Avoid some repaints in RenderElement::repaintAfter...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e1044db535ada573a7d99b80c08ea0351a7cc92b
  
https://github.com/WebKit/WebKit/commit/e1044db535ada573a7d99b80c08ea0351a7cc92b
  Author: Simon Fraser 
  Date:   2023-11-07 (Tue, 07 Nov 2023)

  Changed paths:
M LayoutTests/fast/box-shadow/shadow-repaint-expected.txt
M 
LayoutTests/fast/css-grid-layout/grid-element-change-columns-repaint-expected.txt
M 
LayoutTests/fast/css-grid-layout/grid-element-change-rows-repaint-expected.txt
M 
LayoutTests/fast/css-grid-layout/grid-item-change-column-repaint-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-change-row-repaint-expected.txt
M LayoutTests/fast/repaint/align-items-overflow-change-expected.txt
M LayoutTests/fast/repaint/border-radius-repaint-2-expected.txt
M LayoutTests/fast/repaint/focus-ring-repaint-expected.txt
M LayoutTests/fast/repaint/justify-items-change-expected.txt
M LayoutTests/fast/repaint/justify-items-legacy-change-expected.txt
M LayoutTests/fast/repaint/justify-items-overflow-change-expected.txt
M LayoutTests/fast/repaint/justify-self-change-expected.txt
M LayoutTests/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt
M LayoutTests/fast/repaint/reflection-table-layout-expected.txt
M LayoutTests/fast/repaint/repaint-float-only-and-moves-expected.txt
M LayoutTests/fast/repaint/text-content-shrinks-repaint-expected.txt
M LayoutTests/fast/repaint/text-content-shrinks-repaint.html
M LayoutTests/fast/repaint/transform-table-layout-expected.txt
A LayoutTests/platform/ios-wk2/fast/box-shadow/shadow-repaint-expected.txt
M LayoutTests/platform/ios-wk2/fast/repaint/focus-ring-repaint-expected.txt
M 
LayoutTests/platform/ios-wk2/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt
A 
LayoutTests/platform/ios-wk2/fast/repaint/text-content-shrinks-repaint-expected.txt
M LayoutTests/platform/ios/fast/repaint/border-radius-repaint-2-expected.txt
M 
LayoutTests/platform/mac-ventura-wk2/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt
M 
LayoutTests/platform/mac-wk1/fast/repaint/border-radius-repaint-2-expected.txt
A 
LayoutTests/platform/mac-wk1/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt
R 
LayoutTests/platform/mac-wk2/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt
M Source/WebCore/rendering/RenderElement.cpp

  Log Message:
  ---
  Avoid some repaints in RenderElement::repaintAfterLayoutIfNeeded()
https://bugs.webkit.org/show_bug.cgi?id=264275
rdar://118014812

Reviewed by Alan Baradlay.

In RenderElement::repaintAfterLayoutIfNeeded(), we repaint both the old and the 
new clippedOverflowRect in the
`fullRepaint` code path. But these rectangles might overlap; we only need to 
repaint both if one does not
contain the other. The `contains` checks also take care of the equality check.

* 
LayoutTests/fast/css-grid-layout/grid-element-change-columns-repaint-expected.txt:
* 
LayoutTests/fast/css-grid-layout/grid-element-change-rows-repaint-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-change-column-repaint-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-change-row-repaint-expected.txt:
* LayoutTests/fast/repaint/align-items-overflow-change-expected.txt:
* LayoutTests/fast/repaint/border-radius-repaint-2-expected.txt:
* LayoutTests/fast/repaint/focus-ring-repaint-expected.txt:
* LayoutTests/fast/repaint/justify-items-change-expected.txt:
* LayoutTests/fast/repaint/justify-items-legacy-change-expected.txt:
* LayoutTests/fast/repaint/justify-items-overflow-change-expected.txt:
* LayoutTests/fast/repaint/justify-self-change-expected.txt:
* LayoutTests/fast/repaint/reflection-table-layout-expected.txt:
* LayoutTests/fast/repaint/repaint-float-only-and-moves-expected.txt:
* LayoutTests/fast/repaint/text-content-shrinks-repaint-expected.txt:
* LayoutTests/fast/repaint/text-content-shrinks-repaint.html:
* LayoutTests/fast/repaint/transform-table-layout-expected.txt:
* LayoutTests/platform/ios-wk2/fast/repaint/focus-ring-repaint-expected.txt:
* 
LayoutTests/platform/ios-wk2/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt:
* 
LayoutTests/platform/ios-wk2/fast/repaint/text-content-shrinks-repaint-expected.txt:
 Copied from LayoutTests/fast/repaint/text-content-shrinks-repaint-expected.txt.
* LayoutTests/platform/ios/fast/repaint/border-radius-repaint-2-expected.txt:
* 
LayoutTests/platform/mac-wk1/fast/repaint/border-radius-repaint-2-expected.txt:
* 
LayoutTests/platform/mac-wk2/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt:
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::repaintAfterLayoutIfNeeded):

Canonical link: https://commits.webkit.org/270370@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 34b59c: RemoteDisplayListRecorder should lazily allocate a...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 34b59cbee7578992a6965ad17fa0633e95d516a5
  
https://github.com/WebKit/WebKit/commit/34b59cbee7578992a6965ad17fa0633e95d516a5
  Author: Simon Fraser 
  Date:   2023-11-08 (Wed, 08 Nov 2023)

  Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.cpp
M Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.h

  Log Message:
  ---
  RemoteDisplayListRecorder should lazily allocate a SharedVideoFrameReader
https://bugs.webkit.org/show_bug.cgi?id=262380
rdar://116586176

Reviewed by Youenn Fablet and Eric Carlson.

Only a small subset of RemoteDisplayListRecorder instances need a 
SharedVideoFrameReader,
and making one has some overhead because of the semaphore, so allocate lazily.

* Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.cpp:
(WebKit::RemoteDisplayListRecorder::RemoteDisplayListRecorder):
(WebKit::RemoteDisplayListRecorder::sharedVideoFrameReader):
(WebKit::RemoteDisplayListRecorder::paintVideoFrame):
(WebKit::RemoteDisplayListRecorder::setSharedVideoFrameSemaphore):
(WebKit::RemoteDisplayListRecorder::setSharedVideoFrameMemory):
(): Deleted.
* Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.h:

Canonical link: https://commits.webkit.org/270404@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e6d379: Move the selfNeedsLayout() check out of RenderElem...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e6d3796b1e083a1d5368fb8af04c28d30dec6f28
  
https://github.com/WebKit/WebKit/commit/e6d3796b1e083a1d5368fb8af04c28d30dec6f28
  Author: Simon Fraser 
  Date:   2023-11-08 (Wed, 08 Nov 2023)

  Changed paths:
M Source/WebCore/rendering/LayoutRepainter.cpp
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/RenderElement.h
M Source/WebCore/rendering/RenderLayer.cpp

  Log Message:
  ---
  Move the selfNeedsLayout() check out of 
RenderElement::repaintAfterLayoutIfNeeded()
https://bugs.webkit.org/show_bug.cgi?id=264434
rdar://118138171

Reviewed by Alan Baradlay.

It's surprising that `RenderElement::repaintAfterLayoutIfNeeded()` consults 
selfNeedsLayout(), because why would we have different
behavior for renderers that get laid out but don't have the "self" bit set? 
This code was added in 9388@main to reduce repainting.
Also, there are callers of `repaintAfterLayoutIfNeeded()` outside of layout; 
namely RenderLayer.

So, for clarify, move the `selfNeedsLayout()` check to 
`LayoutRepainter::repaintAfterLayout()`, where it makes more sense to
check layout bits.

* Source/WebCore/rendering/LayoutRepainter.cpp:
(WebCore::LayoutRepainter::repaintAfterLayout):
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::repaintAfterLayoutIfNeeded):
* Source/WebCore/rendering/RenderElement.h:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::recursiveUpdateLayerPositions):

Canonical link: https://commits.webkit.org/270412@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b08a0c: Make RenderLayer's RepaintStatus a enum class

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b08a0ce3562014798d15b108b650ae86128e9142
  
https://github.com/WebKit/WebKit/commit/b08a0ce3562014798d15b108b650ae86128e9142
  Author: Simon Fraser 
  Date:   2023-11-08 (Wed, 08 Nov 2023)

  Changed paths:
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerModelObject.cpp
M Source/WebCore/rendering/RenderObject.cpp

  Log Message:
  ---
  Make RenderLayer's RepaintStatus a enum class
https://bugs.webkit.org/show_bug.cgi?id=264377
rdar://118092077

Reviewed by Alan Baradlay.

The `if (m_repaintStatus & NeedsFullRepaint)` was confusing and subtle; make it 
explicitly check
for both NeedsFullRepaint and NeedsFullRepaintForPositionedMovementLayout, and 
make the enum
an enum class.

We can also use an enum in the bitfield, and initialize it now.

* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::RenderLayer):
(WebCore::RenderLayer::removeOnlyThisLayer):
(WebCore::RenderLayer::recursiveUpdateLayerPositions):
(WebCore::RenderLayer::shouldRepaintAfterLayout const):
* Source/WebCore/rendering/RenderLayer.h:
(WebCore::RenderLayer::repaintStatus const):
(WebCore::RenderLayer::needsFullRepaint const):
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::styleDidChange):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::setLayerNeedsFullRepaint):
(WebCore::RenderObject::setLayerNeedsFullRepaintForPositionedMovementLayout):

Canonical link: https://commits.webkit.org/270413@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9dc96c: Simplify repainting logic in RenderLayer::recursiv...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9dc96cf594dd31247f37fa53d3cd000471be0882
  
https://github.com/WebKit/WebKit/commit/9dc96cf594dd31247f37fa53d3cd000471be0882
  Author: Simon Fraser 
  Date:   2023-11-09 (Thu, 09 Nov 2023)

  Changed paths:
M 
LayoutTests/fast/repaint/hidpi-box-with-subpixel-height-inflates-expected.txt
M Source/WebCore/rendering/RenderLayer.cpp

  Log Message:
  ---
  Simplify repainting logic in RenderLayer::recursiveUpdateLayerPositions()
https://bugs.webkit.org/show_bug.cgi?id=264461
rdar://118151709

Reviewed by Alan Baradlay.

The `NeedsFullRepaint` case previously duplicate some logic that exists in 
`RenderElement::repaintAfterLayoutIfNeeded()`,
which is that if we're doing a full repaint, we just need to paint the 
clippedOverflowRects.

This logic was optimized in 270370@main to turn two repaints into one 
sometimes, and we can re-use it here. We know
that in the RequiresFullRepaint::Yes case, 
`RenderElement::repaintAfterLayoutIfNeeded()` only consults the 
clippedOverflowRects,
so we can fold this logic with the second `shouldRepaintAfterLayout()` clause. 
It's fine to pass empty oldRects if we didn't
have any.

`repaintAfterLayoutIfNeeded()` does the check for printing, so we can remove 
that. Also the comment duplicates comments
in that function too, so remove it.

* LayoutTests/fast/repaint/hidpi-box-with-subpixel-height-inflates-expected.txt:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::recursiveUpdateLayerPositions):
(WebCore::RenderLayer::shouldRepaintAfterLayout const):

Canonical link: https://commits.webkit.org/270454@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 674f44: Avoid computing containerForRepaint() for non-self...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 674f44ebcb7a271e1361f7235a0f7f06e1edca0c
  
https://github.com/WebKit/WebKit/commit/674f44ebcb7a271e1361f7235a0f7f06e1edca0c
  Author: Simon Fraser 
  Date:   2023-11-09 (Thu, 09 Nov 2023)

  Changed paths:
M Source/WebCore/rendering/RenderLayer.cpp

  Log Message:
  ---
  Avoid computing containerForRepaint() for non-self-painting layers
https://bugs.webkit.org/show_bug.cgi?id=264504
rdar://118186580

Reviewed by Alan Baradlay.

In RenderLayer::recursiveUpdateLayerPositions(), a non-self-painting layer will 
just clear the clip rects,
so doesn't need to compute the repaintContainer (which is an ancestor tree 
walk, so not free).

So factor some code into a lambda so we can early return, which allows for some 
simplification.

* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::recursiveUpdateLayerPositions):

Canonical link: https://commits.webkit.org/270476@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3f9353: Fix the build after 270501@main

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3f93530e90eaae4a439d218da637fdb2b56cd2dd
  
https://github.com/WebKit/WebKit/commit/3f93530e90eaae4a439d218da637fdb2b56cd2dd
  Author: Simon Fraser 
  Date:   2023-11-09 (Thu, 09 Nov 2023)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  Fix the build after 270501@main
https://bugs.webkit.org/show_bug.cgi?id=264548
rdar://118216881

Unreviewed build fix.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:

Canonical link: https://commits.webkit.org/270504@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d24752: Make LayerRepaintRects internal to RenderLayer

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d24752c38292065d9216c2adbd11a6f60f2b750c
  
https://github.com/WebKit/WebKit/commit/d24752c38292065d9216c2adbd11a6f60f2b750c
  Author: Simon Fraser 
  Date:   2023-11-10 (Fri, 10 Nov 2023)

  Changed paths:
M Source/WebCore/rendering/LegacyLineLayout.cpp
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerModelObject.cpp
M Source/WebCore/rendering/RenderLayerModelObject.h
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp

  Log Message:
  ---
  Make LayerRepaintRects internal to RenderLayer
https://bugs.webkit.org/show_bug.cgi?id=264530
rdar://118203951

Reviewed by Chris Dumez.

There are two call sites that make use of RenderLayer's cached repaint rects, 
but
they both use only the clippedOverflowRect, not the outlineBoundsRect, so we can
hide RepaintRects inside of RenderLayer, and only expose the 
cachedClippedOverflowRect()
to those two clients.

* Source/WebCore/rendering/LegacyLineLayout.cpp:
(WebCore::LegacyLineLayout::layoutRunsAndFloats):
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::cachedClippedOverflowRect const):
(WebCore::RenderLayer::setRepaintRects):
(WebCore::RenderLayer::shouldRepaintAfterLayout const):
* Source/WebCore/rendering/RenderLayer.h:
(WebCore::RenderLayer::repaintRects const):
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::styleDidChange):
(WebCore::RenderLayerModelObject::cachedLayerClippedOverflowRect const):
(WebCore::RenderLayerModelObject::layerRepaintRects const): Deleted.
* Source/WebCore/rendering/RenderLayerModelObject.h:
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::scrollTo):

Canonical link: https://commits.webkit.org/270550@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7a1c0a: Remove tracking of content-supplied colors in canvas

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7a1c0aefc3456f3e8e9f0c5597cbb618b8adef56
  
https://github.com/WebKit/WebKit/commit/7a1c0aefc3456f3e8e9f0c5597cbb618b8adef56
  Author: Simon Fraser 
  Date:   2023-11-13 (Mon, 13 Nov 2023)

  Changed paths:
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.h

  Log Message:
  ---
  Remove tracking of content-supplied colors in canvas
https://bugs.webkit.org/show_bug.cgi?id=264786
rdar://118367460

Reviewed by Chris Dumez.

Updating m_suppliedColors shows up on profiles, and this is unused, so remove 
it.

* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::CanvasRenderingContext2DBase::setFillStyle):
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.h:
(WebCore::CanvasRenderingContext2DBase::suppliedColors const): Deleted.

Canonical link: https://commits.webkit.org/270686@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6aa1f6: RenderBox::applyVisualEffectOverflow() and RenderB...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6aa1f6767674ab7a07f899d2f3a9d338c7c95244
  
https://github.com/WebKit/WebKit/commit/6aa1f6767674ab7a07f899d2f3a9d338c7c95244
  Author: Simon Fraser 
  Date:   2023-11-28 (Tue, 28 Nov 2023)

  Changed paths:
M LayoutTests/fast/box-shadow/negative-shadow-box-expand-expected.txt
M LayoutTests/fast/box-shadow/negative-shadow-box-shrink-expected.txt
A LayoutTests/fast/repaint/outline-and-shadow-repaint-expected.txt
A LayoutTests/fast/repaint/outline-and-shadow-repaint.html
M LayoutTests/platform/gtk/fast/repaint/4776765-expected.txt
M LayoutTests/platform/mac-monterey-wk2/fast/repaint/4776765-expected.txt
M LayoutTests/platform/mac-ventura-wk2/fast/repaint/4776765-expected.txt
M LayoutTests/platform/mac-wk1/fast/repaint/4776765-expected.txt
M LayoutTests/platform/mac/fast/repaint/4776765-expected.txt
M Source/WebCore/display/css/DisplayBoxModelBox.cpp
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/style/RenderStyle.cpp
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/rendering/style/RenderStyleInlines.h
M Source/WebCore/rendering/style/ShadowData.cpp
M Source/WebCore/rendering/style/ShadowData.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGModelObject.cpp

  Log Message:
  ---
  RenderBox::applyVisualEffectOverflow() and 
RenderBox::outlineBoundsForRepaint() use different ways of computing 
outline/shadow extent
https://bugs.webkit.org/show_bug.cgi?id=264625
rdar://118582062

Reviewed by Alan Baradlay.

The logic in `ShadowData::adjustRectForShadow()` to compute the impact of 
box-shadow and outline
on a rect was wrong; the outline is not shadowed, so outline and shadow have 
independent effects
on the repaint rect. The correct implementation is to just compute their 
effects separately, and
take the union of the result, which is what 
`RenderBox::applyVisualEffectOverflow()` already
does.

So remove the outline argument from `ShadowData::adjustRectForShadow()` and 
delete
`RenderObject::adjustRectForOutlineAndShadow()`. 
`RenderBox::outlineBoundsForRepaint()` now just
calls `applyVisualEffectOverflow()`, and LegacyRenderSVGModelObject gets its 
own copy of the old
code because it's not clear how shadows and outlines interact in SVG.

There was also code duplication between `RenderStyle::shadowExtent()` and code 
in ShadowData, so
remove the RenderStyle code and have it call into ShadowData.

* LayoutTests/fast/box-shadow/negative-shadow-box-expand-expected.txt:
* LayoutTests/fast/box-shadow/negative-shadow-box-shrink-expected.txt:
* LayoutTests/fast/repaint/outline-and-shadow-repaint-expected.txt: Added.
* LayoutTests/fast/repaint/outline-and-shadow-repaint.html: Added.
* LayoutTests/platform/gtk/fast/repaint/4776765-expected.txt:
* LayoutTests/platform/mac-monterey-wk2/fast/repaint/4776765-expected.txt:
* LayoutTests/platform/mac-ventura-wk2/fast/repaint/4776765-expected.txt:
* LayoutTests/platform/mac-wk1/fast/repaint/4776765-expected.txt:
* LayoutTests/platform/mac/fast/repaint/4776765-expected.txt:
* Source/WebCore/display/css/DisplayBoxModelBox.cpp:
(WebCore::Display::BoxModelBox::absolutePaintingExtent const):
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::outlineBoundsForRepaint const):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::adjustRectForOutlineAndShadow const): Deleted.
* Source/WebCore/rendering/RenderObject.h:
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::shadowExtent): Deleted.
(WebCore::RenderStyle::shadowInsetExtent): Deleted.
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/style/RenderStyleInlines.h:
(WebCore::RenderStyle::boxShadowExtent const):
(WebCore::RenderStyle::boxShadowInsetExtent const):
(WebCore::RenderStyle::textShadowExtent const):
* Source/WebCore/rendering/style/ShadowData.cpp:
(WebCore::ShadowData::shadowOutsetExtent const):
(WebCore::ShadowData::shadowInsetExtent const):
(WebCore::ShadowData::adjustRectForShadow const):
(WebCore::calculateShadowExtent): Deleted.
* Source/WebCore/rendering/style/ShadowData.h:
(WebCore::ShadowData::shadowOutsetExtent):
(WebCore::ShadowData::shadowInsetExtent):
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGModelObject.cpp:
(WebCore::adjustRectForOutlineAndShadow):
(WebCore::LegacyRenderSVGModelObject::outlineBoundsForRepaint const):

Canonical link: https://commits.webkit.org/271254@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4e5d89: Fix some incorrect adoptNS() usage in tests

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4e5d8928f4798bb1a78734997e52292e9ae8cff7
  
https://github.com/WebKit/WebKit/commit/4e5d8928f4798bb1a78734997e52292e9ae8cff7
  Author: Simon Fraser 
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm

  Log Message:
  ---
  Fix some incorrect adoptNS() usage in tests
https://bugs.webkit.org/show_bug.cgi?id=265496
rdar://118908203

Reviewed by Chris Dumez.

Don't use adoptNS/adoptCF() with expressions that don't return a retained value.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm:
(TestWebKitAPI::TEST):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm:
(TestWebKitAPI::TEST):

Canonical link: https://commits.webkit.org/271287@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 59046b: Set kCACornerCurveCircular for CALayers with corne...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 59046b46f4f8bd12cb89e767fedd5d7b1d965bb5
  
https://github.com/WebKit/WebKit/commit/59046b46f4f8bd12cb89e767fedd5d7b1d965bb5
  Author: Simon Fraser 
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm
M Source/WebKit/UIProcess/PDF/WKPDFHUDView.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
M Source/WebKit/UIProcess/ios/fullscreen/WKFullscreenStackView.mm
M 
WebKitLibraries/SDKs/watchos10.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd
M 
WebKitLibraries/SDKs/watchos9.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd
M 
WebKitLibraries/SDKs/watchsimulator10.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd
M 
WebKitLibraries/SDKs/watchsimulator9.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd

  Log Message:
  ---
  Set kCACornerCurveCircular for CALayers with corner radius
https://bugs.webkit.org/show_bug.cgi?id=265492
rdar://113292205

Reviewed by Tim Horton.

Make sure corner radii on CALayers use circular corner radius, rather than 
continuous corner radius.

* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h: setCornerRadius: is API now.
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::setCornerRadius):
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm:
(WebKit::RemoteLayerTreePropertyApplier::applyPropertiesToLayer):
* Source/WebKit/UIProcess/PDF/WKPDFHUDView.mm:
(-[WKPDFHUDView _setupLayer:]):
* 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::updateLayersForInteractionRegions):
* Source/WebKit/UIProcess/ios/fullscreen/WKFullscreenStackView.mm:
(-[WKFullscreenStackView init]):
* 
WebKitLibraries/SDKs/watchos10.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd:
 QuartzCore is SPI on watchOS so we have to add the symbol here.
* 
WebKitLibraries/SDKs/watchos9.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd:
* 
WebKitLibraries/SDKs/watchsimulator10.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd:
* 
WebKitLibraries/SDKs/watchsimulator9.0-additions.sdk/System/Library/Frameworks/QuartzCore.framework/QuartzCore.tbd:

Canonical link: https://commits.webkit.org/271301@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c4e7c9: Eliminate some overrides of `clippedOverflowRect()`

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c4e7c9cb317654a0921884679cf2c501136aeccd
  
https://github.com/WebKit/WebKit/commit/c4e7c9cb317654a0921884679cf2c501136aeccd
  Author: Simon Fraser 
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderLineBreak.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderReplaced.cpp
M Source/WebCore/rendering/RenderReplaced.h
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderTableCell.h
M Source/WebCore/rendering/RenderTableCol.cpp
M Source/WebCore/rendering/RenderTableRow.cpp
M Source/WebCore/rendering/svg/RenderSVGBlock.cpp
M Source/WebCore/rendering/svg/RenderSVGGradientStop.h
M Source/WebCore/rendering/svg/RenderSVGModelObject.cpp
M Source/WebCore/rendering/svg/RenderSVGModelObject.h

  Log Message:
  ---
  Eliminate some overrides of `clippedOverflowRect()`
https://bugs.webkit.org/show_bug.cgi?id=265541
rdar://118946413

Reviewed by Alan Baradlay.

The implementations of clippedOverflowRect() in RenderBox, RenderReplaced, 
RenderTableCell
and RenderSVGModelObject are identical, other than starting with a different 
repaint rect.
So move the implementation to RenderObject, and have these classes override a 
new localRectForRepaint()
function instead.

RenderSVGBlock::clippedOverflowRect() can just call the base class when 
layerBasedSVGEngineEnabled()
is true.

Minor other `auto` improvements.

* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::localRectForRepaint const):
(WebCore::RenderBox::clippedOverflowRect const): Deleted.
* Source/WebCore/rendering/RenderBox.h:
* Source/WebCore/rendering/RenderLineBreak.h:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::localRectForRepaint const):
(WebCore::RenderObject::clippedOverflowRect const):
(WebCore::RenderObject::computeRect const):
(WebCore::RenderObject::computeFloatRectForRepaint const):
* Source/WebCore/rendering/RenderObject.h:
* Source/WebCore/rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::localRectForRepaint const):
(WebCore::RenderReplaced::clippedOverflowRect const): Deleted.
* Source/WebCore/rendering/RenderReplaced.h:
* Source/WebCore/rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::localRectForRepaint const):
(WebCore::RenderTableCell::clippedOverflowRect const): Deleted.
* Source/WebCore/rendering/RenderTableCell.h:
* Source/WebCore/rendering/RenderTableCol.cpp:
(WebCore::RenderTableCol::clippedOverflowRect const):
* Source/WebCore/rendering/RenderTableRow.cpp:
(WebCore::RenderTableRow::clippedOverflowRect const):
* Source/WebCore/rendering/svg/RenderSVGBlock.cpp:
(WebCore::RenderSVGBlock::clippedOverflowRect const):
* Source/WebCore/rendering/svg/RenderSVGGradientStop.h:
* Source/WebCore/rendering/svg/RenderSVGModelObject.cpp:
(WebCore::RenderSVGModelObject::localRectForRepaint const):
(WebCore::RenderSVGModelObject::clippedOverflowRect const): Deleted.
* Source/WebCore/rendering/svg/RenderSVGModelObject.h:

Canonical link: https://commits.webkit.org/271323@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 55dc29: Simplify the implementations of computeVisibleRect...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 55dc29da9f7467101567baf29ce1936af2f88c00
  
https://github.com/WebKit/WebKit/commit/55dc29da9f7467101567baf29ce1936af2f88c00
  Author: Simon Fraser 
  Date:   2023-11-30 (Thu, 30 Nov 2023)

  Changed paths:
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderInline.cpp
M Source/WebCore/rendering/RenderLayerModelObject.cpp
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderView.cpp

  Log Message:
  ---
  Simplify the implementations of computeVisibleRectInContainer() slightly
https://bugs.webkit.org/show_bug.cgi?id=265560
rdar://118961487

Reviewed by Alan Baradlay.

RenderBox::computeVisibleRectInContainer() had some confusing logic that copied 
adjustedRect.location()
into a `topLeft` variable, modified it, and then set it back on adjustedRect. 
It's simpler, and will
help with future changes, to just modify adjustedRect's location directly.

It's made slightly more complex by the fact that we have to store 
`locationOffset`, which can be modified
for integral-snapped widgets, across the transform case that computes a new 
adjustedRect.

RenderInline::computeVisibleRectInContainer() and 
RenderLayerModelObject::computeVisibleRectInSVGContainer()
copied the same pattern and can also be simplified.

Remove comments about "lightweight clipping rect that controls use" that are 
probably no longer relevant.

* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeVisibleRectInContainer const):
* Source/WebCore/rendering/RenderInline.cpp:
(WebCore::RenderInline::computeVisibleRectInContainer const):
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::computeVisibleRectInSVGContainer const):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::computeVisibleRectInContainer const):
* Source/WebCore/rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::computeVisibleRectInContainer const):
* Source/WebCore/rendering/RenderView.cpp:
(WebCore::RenderView::computeVisibleRectInContainer const):

Canonical link: https://commits.webkit.org/271339@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a56c5d: Lay the groundwork for computing a pair of repaint...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a56c5d7d78e04c9d5722856240d01d67312f7bca
  
https://github.com/WebKit/WebKit/commit/a56c5d7d78e04c9d5722856240d01d67312f7bca
  Author: Simon Fraser 
  Date:   2023-11-30 (Thu, 30 Nov 2023)

  Changed paths:
M Source/WebCore/page/IntersectionObserver.cpp
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderInline.cpp
M Source/WebCore/rendering/RenderInline.h
M Source/WebCore/rendering/RenderLayerModelObject.cpp
M Source/WebCore/rendering/RenderLayerModelObject.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderTableCell.h
M Source/WebCore/rendering/RenderView.cpp
M Source/WebCore/rendering/RenderView.h
M Source/WebCore/rendering/svg/RenderSVGBlock.cpp
M Source/WebCore/rendering/svg/RenderSVGBlock.h
M Source/WebCore/rendering/svg/RenderSVGHiddenContainer.h
M Source/WebCore/rendering/svg/RenderSVGModelObject.cpp
M Source/WebCore/rendering/svg/RenderSVGModelObject.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGRoot.cpp

  Log Message:
  ---
  Lay the groundwork for computing a pair of repaint rects
https://bugs.webkit.org/show_bug.cgi?id=265585
rdar://118989146

Reviewed by Alan Baradlay.

A future patch will eliminate `outlineBoundsForRepaint()` and compute that rect 
via the
`computeVisibleRectsInContainer()` code path. In preparation, create a new 
RepaintRects
struct that will hold both rects; for now, it just has a `clippedOverflowRect`. 
Use it
in `computeVisibleRectsInContainer()` which is the core function for mapping 
rects up
to a repaint container, and in `computeRects()` which is the non-virtual 
wrapper.

Functions called from also need to use RepaintRects: 
`applyCachedClipAndScrollPosition()`
and `computeVisibleRectsInSVGContainer()`.

`computeFloatVisibleRectInContainer()` is a parallel function to 
`computeVisibleRectsInContainer()`
used only for SVG: ideally these two would be collapsed together. For now, 
since SVG doesn't care
about painting outline bounds changes only, leave this FloatRect code alone.

This replacement is largely mechanical. For cleanliness, RepaintRects has some
helper functions for flipping, transforming etc, that in future will operate on
both rects.

* Source/WebCore/page/IntersectionObserver.cpp:
(WebCore::computeClippedRectInRootContentsSpace):
(WebCore::IntersectionObserver::computeIntersectionState const):
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::applyCachedClipAndScrollPosition const):
(WebCore::RenderBox::computeVisibleRectsUsingPaintOffset const):
(WebCore::RenderBox::computeVisibleRectsInContainer const):
(WebCore::RenderBox::flipForWritingMode const):
(WebCore::RenderBox::computeVisibleRectUsingPaintOffset const): Deleted.
(WebCore::RenderBox::computeVisibleRectInContainer const): Deleted.
* Source/WebCore/rendering/RenderBox.h:
* Source/WebCore/rendering/RenderInline.cpp:
(WebCore::RenderInline::clippedOverflowRect const):
(WebCore::RenderInline::computeVisibleRectsUsingPaintOffset const):
(WebCore::RenderInline::computeVisibleRectsInContainer const):
(WebCore::RenderInline::computeVisibleRectUsingPaintOffset const): Deleted.
(WebCore::RenderInline::computeVisibleRectInContainer const): Deleted.
* Source/WebCore/rendering/RenderInline.h:
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::computeVisibleRectsInSVGContainer const):
(WebCore::RenderLayerModelObject::computeVisibleRectInSVGContainer const): 
Deleted.
* Source/WebCore/rendering/RenderLayerModelObject.h:
(WebCore::RenderLayerModelObject::applyCachedClipAndScrollPosition const):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::clippedOverflowRect const):
(WebCore::RenderObject::computeRects const):
(WebCore::RenderObject::computeVisibleRectsInContainer const):
(WebCore::RenderObject::hasNonEmptyVisibleRectRespectingParentFrames const):
(WebCore::borderAndTextRects):
(WebCore::RenderObject::RepaintRects::transform):
(WebCore::RenderObject::computeRect const): Deleted.
(WebCore::RenderObject::computeVisibleRectInContainer const): Deleted.
* Source/WebCore/rendering/RenderObject.h:
(WebCore::RenderObject::RepaintRects::move):
(WebCore::RenderObject::RepaintRects::moveBy):
(WebCore::RenderObject::RepaintRects::expand):
(WebCore::RenderObject::RepaintRects::encloseToIntRects):
(WebCore::RenderObject::RepaintRects::unite):
(WebCore::RenderObject::RepaintRects::flipForWritingMode):
(WebCore::RenderObject::computeRectForRepaint const):
(WebCore::RenderObject::computeAbsoluteRepaintRect const): Deleted. It was 
unused.
* Source/WebCore/rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::computeVisibleRectsInContainer const):
(WebCore::RenderTabl

[webkit-changes] [WebKit/WebKit] cb2d6f: Remove a couple of clippedOverflowRect() overrides

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: cb2d6fa3441d2365a572a523c7299d2053688691
  
https://github.com/WebKit/WebKit/commit/cb2d6fa3441d2365a572a523c7299d2053688691
  Author: Simon Fraser 
  Date:   2023-12-01 (Fri, 01 Dec 2023)

  Changed paths:
M Source/WebCore/rendering/RenderLineBreak.h
M Source/WebCore/rendering/svg/RenderSVGGradientStop.h
M Source/WebCore/rendering/svg/SVGRenderSupport.cpp

  Log Message:
  ---
  Remove a couple of clippedOverflowRect() overrides
https://bugs.webkit.org/show_bug.cgi?id=265627
rdar://119016913

Reviewed by Alan Baradlay.

Don't override `clippedOverflowRect()` when we can instead override 
`localRectForRepaint()`, which
is true for RenderLineBreak and RenderSVGGradientStop.

Fix SVGRenderSupport::clippedOverflowRectForRepaint() to use 
`isInsideEntirelyHiddenLayer()`
which we use elsewhere.

* Source/WebCore/rendering/RenderLineBreak.h:
* Source/WebCore/rendering/svg/SVGRenderSupport.cpp:
(WebCore::SVGRenderSupport::clippedOverflowRectForRepaint):

Canonical link: https://commits.webkit.org/271388@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 0bfa98: Add outlineBoundsRect to RepaintRects

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0bfa98376d7330aae32fffe27eff473b21693152
  
https://github.com/WebKit/WebKit/commit/0bfa98376d7330aae32fffe27eff473b21693152
  Author: Simon Fraser 
  Date:   2023-12-01 (Fri, 01 Dec 2023)

  Changed paths:
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/svg/RenderSVGModelObject.cpp

  Log Message:
  ---
  Add outlineBoundsRect to RepaintRects
https://bugs.webkit.org/show_bug.cgi?id=265695
rdar://119049099

Reviewed by Alan Baradlay.

Another step towards computing clippedOverflowRect and outlineBoundsRect in the 
same
ancestor traversal is adding an optioal outlineBoundsRect to RepaintRects. Note
that this isn't clipped by the `intersect` functions, replicating the unclipped
behavior of `outlineBoundsForRepaint()`.

No-one sets the outlineBoundsRect yet.

* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::applyCachedClipAndScrollPosition const):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::RepaintRects::transform):
* Source/WebCore/rendering/RenderObject.h:
(WebCore::RenderObject::RepaintRects::RepaintRects):
(WebCore::RenderObject::RepaintRects::move):
(WebCore::RenderObject::RepaintRects::moveBy):
(WebCore::RenderObject::RepaintRects::expand):
(WebCore::RenderObject::RepaintRects::encloseToIntRects):
(WebCore::RenderObject::RepaintRects::unite):
(WebCore::RenderObject::RepaintRects::flipForWritingMode):
(WebCore::RenderObject::RepaintRects::intersect):
(WebCore::RenderObject::RepaintRects::edgeInclusiveIntersect):
* Source/WebCore/rendering/svg/RenderSVGModelObject.cpp:
(WebCore::RenderSVGModelObject::applyCachedClipAndScrollPosition const):

Canonical link: https://commits.webkit.org/271422@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 0724fe: Fix the xcfilelists after 271428@main

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0724fe5790b24a6c3ef9fd9f34e144d1a06f2cb3
  
https://github.com/WebKit/WebKit/commit/0724fe5790b24a6c3ef9fd9f34e144d1a06f2cb3
  Author: Simon Fraser 
  Date:   2023-12-02 (Sat, 02 Dec 2023)

  Changed paths:
M Source/WebCore/DerivedSources-output.xcfilelist

  Log Message:
  ---
  Fix the xcfilelists after 271428@main
https://bugs.webkit.org/show_bug.cgi?id=265725
rdar://119077212

Unreviewed build fix.

Add JSInvokerElement.cpp and JSInvokerElement.h to 
DerivedSources-output.xcfilelist

* Source/WebCore/DerivedSources-output.xcfilelist:

Canonical link: https://commits.webkit.org/271432@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ab344c: [iOS] Fix the build after 271429@main

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ab344c6519190b01c110499f38a7e42369d96938
  
https://github.com/WebKit/WebKit/commit/ab344c6519190b01c110499f38a7e42369d96938
  Author: Simon Fraser 
  Date:   2023-12-02 (Sat, 02 Dec 2023)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [iOS] Fix the build after 271429@main
https://bugs.webkit.org/show_bug.cgi?id=265733
rdar://119080414

Unreviewed build fix.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::performContextMenuAction const):
(WebKit::UnifiedPDFPlugin::handleContextMenuEvent):

Canonical link: https://commits.webkit.org/271433@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5c239a: Clean up RenderElement::repaintAfterLayoutIfNeeded()

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5c239a3e46973761ff7d8a20b5a4ce27c0e8bd2d
  
https://github.com/WebKit/WebKit/commit/5c239a3e46973761ff7d8a20b5a4ce27c0e8bd2d
  Author: Simon Fraser 
  Date:   2023-12-02 (Sat, 02 Dec 2023)

  Changed paths:
M 
LayoutTests/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt
M 
LayoutTests/platform/gtk/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt
M LayoutTests/platform/gtk/fast/repaint/4776765-expected.txt
M 
LayoutTests/platform/ios-wk2/compositing/repaint/invalidations-on-composited-layers-expected.txt
M LayoutTests/platform/mac-monterey-wk2/fast/repaint/4776765-expected.txt
M 
LayoutTests/platform/mac-monterey/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt
M LayoutTests/platform/mac-ventura-wk2/fast/repaint/4776765-expected.txt
M 
LayoutTests/platform/mac-ventura/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt
M LayoutTests/platform/mac-wk1/fast/repaint/4776765-expected.txt
M 
LayoutTests/platform/mac/compositing/repaint/invalidations-on-composited-layers-expected.txt
M 
LayoutTests/platform/mac/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt
M LayoutTests/platform/mac/fast/repaint/4776765-expected.txt
M Source/WebCore/rendering/RenderElement.cpp

  Log Message:
  ---
  Clean up RenderElement::repaintAfterLayoutIfNeeded()
https://bugs.webkit.org/show_bug.cgi?id=265726
rdar://119077478

Reviewed by Alan Baradlay.

Tidy up RenderElement::repaintAfterLayoutIfNeeded() by using a couple of lambda 
functions; one to replace
the standalone `mustRepaintBackgroundOrBorder()`, and a second to clarify the 
computation of `fullRepaint`.

There's one behavior change from:
if (oldClippedOverflowRect.isEmpty() || 
newClippedOverflowRect.isEmpty())
return true;

which removes some redundant repaints in fast/repaint/4776765.html.

* 
LayoutTests/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt:
* 
LayoutTests/platform/gtk/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt:
* LayoutTests/platform/gtk/fast/repaint/4776765-expected.txt:
* 
LayoutTests/platform/ios-wk2/compositing/repaint/invalidations-on-composited-layers-expected.txt:
* LayoutTests/platform/mac-monterey-wk2/fast/repaint/4776765-expected.txt:
* 
LayoutTests/platform/mac-monterey/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt:
* LayoutTests/platform/mac-ventura-wk2/fast/repaint/4776765-expected.txt:
* 
LayoutTests/platform/mac-ventura/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt:
* LayoutTests/platform/mac-wk1/fast/repaint/4776765-expected.txt:
* 
LayoutTests/platform/mac/compositing/repaint/invalidations-on-composited-layers-expected.txt:
* 
LayoutTests/platform/mac/editing/caret/insert-paragraph-does-not-paint-stale-carets-expected.txt:
* LayoutTests/platform/mac/fast/repaint/4776765-expected.txt:
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::repaintAfterLayoutIfNeeded):
(WebCore::mustRepaintBackgroundOrBorder): Deleted.

Canonical link: https://commits.webkit.org/271435@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3d19f6: Do a full repaint when the old and new clippedOver...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3d19f69ee7b4937ee44a021a267297c47ea69185
  
https://github.com/WebKit/WebKit/commit/3d19f69ee7b4937ee44a021a267297c47ea69185
  Author: Simon Fraser 
  Date:   2023-12-03 (Sun, 03 Dec 2023)

  Changed paths:
M 
LayoutTests/platform/ios/svg/repaint/text-repainting-after-modifying-container-transform-repaint-rects-expected.txt
M 
LayoutTests/platform/ios/svg/repaint/text-repainting-after-modifying-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/foreign-object-repainting-after-modifying-container-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/foreign-object-repainting-after-modifying-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/image-repainting-after-modifying-container-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/image-repainting-after-modifying-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/shape-repainting-after-modifying-container-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/shape-repainting-after-modifying-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/text-repainting-after-modifying-container-transform-repaint-rects-expected.txt
M 
LayoutTests/svg/repaint/text-repainting-after-modifying-transform-repaint-rects-expected.txt
M Source/WebCore/rendering/RenderElement.cpp

  Log Message:
  ---
  Do a full repaint when the old and new clippedOverflowRects don't overlap
https://bugs.webkit.org/show_bug.cgi?id=265754
rdar://119098796

Reviewed by Alan Baradlay.

In the non-full repaint code path, RenderElement::repaintAfterLayoutIfNeeded() 
does repaints based on the deltas
of each edge of the rects. This makes no sense if the rects don't overlap, so 
in that case just do a full repaint.

* 
LayoutTests/platform/ios/svg/repaint/text-repainting-after-modifying-container-transform-repaint-rects-expected.txt:
* 
LayoutTests/platform/ios/svg/repaint/text-repainting-after-modifying-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/foreign-object-repainting-after-modifying-container-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/foreign-object-repainting-after-modifying-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/image-repainting-after-modifying-container-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/image-repainting-after-modifying-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/shape-repainting-after-modifying-container-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/shape-repainting-after-modifying-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/text-repainting-after-modifying-container-transform-repaint-rects-expected.txt:
* 
LayoutTests/svg/repaint/text-repainting-after-modifying-transform-repaint-rects-expected.txt:
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::repaintAfterLayoutIfNeeded):

Canonical link: https://commits.webkit.org/271443@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b08857: When repainting after layout, compute the outline ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b088578e1f36d5fb9ce91269eab482bbc52be91d
  
https://github.com/WebKit/WebKit/commit/b088578e1f36d5fb9ce91269eab482bbc52be91d
  Author: Simon Fraser 
  Date:   2023-12-04 (Mon, 04 Dec 2023)

  Changed paths:
M 
LayoutTests/fast/repaint/hidpi-transform-on-subpixel-repaintrect-expected.txt
M LayoutTests/svg/repaint/mask-object-bounding-box-shrink-expected.txt
M Source/WebCore/rendering/LayoutRepainter.cpp
M Source/WebCore/rendering/LayoutRepainter.h
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/RenderElement.h
M Source/WebCore/rendering/RenderInline.cpp
M Source/WebCore/rendering/RenderInline.h
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLineBreak.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderReplaced.cpp
M Source/WebCore/rendering/RenderReplaced.h
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderTableCell.h
M Source/WebCore/rendering/RenderTableCol.cpp
M Source/WebCore/rendering/RenderTableCol.h
M Source/WebCore/rendering/RenderTableRow.cpp
M Source/WebCore/rendering/RenderTableRow.h
M Source/WebCore/rendering/RenderText.cpp
M Source/WebCore/rendering/RenderText.h
M Source/WebCore/rendering/svg/RenderSVGBlock.cpp
M Source/WebCore/rendering/svg/RenderSVGBlock.h
M Source/WebCore/rendering/svg/RenderSVGGradientStop.h
M Source/WebCore/rendering/svg/RenderSVGInline.cpp
M Source/WebCore/rendering/svg/RenderSVGInline.h
M Source/WebCore/rendering/svg/RenderSVGModelObject.cpp
M Source/WebCore/rendering/svg/RenderSVGModelObject.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGHiddenContainer.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGModelObject.cpp
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGModelObject.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGRoot.cpp
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGRoot.h

  Log Message:
  ---
  When repainting after layout, compute the outline bounds in the same pass as 
the clipped overflow rect
https://bugs.webkit.org/show_bug.cgi?id=265761
rdar://119101912

Reviewed by Alan Baradlay.

Currently repaints originating in RenderElement::repaintAfterLayoutIfNeeded() 
are computing using two rectangles:
the clippedOverflowRect, and the outlineBoundsForRepaint. These are computed in 
two separate ancestor traversals,
but we can make things more efficient by computing them at the same time.

The core functions that compute both rects, `computeRects()` and the virtual 
`computeVisibleRectsInContainer()`
that it calls were updated in previous commits (271364@main, 271422@main) to 
handle both rectangles. These
are generic functions that compute rectangles both for repaint, and other 
purposes.

Here we add a new, repaint-specific wrapper, `rectsForRepaintingAfterLayout()`, 
which returns both rectangles
via RepaintRects. Unfortunately, a number of classes specialize the calling 
function, `clippedOverflowRect()`,
so we need `rectsForRepaintingAfterLayout()` overrides in those classes to 
replicate their special behavior.

The previous `localRectForRepaint()` becomes `localRectsForRepaint()` to return 
the pair of rects,
optionally including the outline bounds rect.

RenderText and RenderInline are special becuase they never cares about the 
outline bounds rect. RenderTableRow and
RenderTableCol are special, and SVG has some special-case behavior in the 
non-LBSE code path.

LayoutRepainter now stores a RepaintsRect, and knows that the outline bounds is 
not needed if this is a full repaint.

RenderElement::repaintAfterLayoutIfNeeded() is adjusted to do the border radius 
computation using the outline
bounds rect (as a proxy for the border box size). Doing this computation in the 
clipped rect didn't make much sense.

RenderLayer no longer needs its own RepaintRects class. Also remove the 
assertions about invalid repaint rects;
they fired too often, and didn't clearly reflect real bugs.

There is a minor behavior change here that affects two tests: the results of 
the outline bounds rect computation
are snapped to device pixels, which did not happen before. This turns some full 
repaints into non-full repaints,
affecting fast/repaint/hidpi-transform-on-subpixel-repaintrect.html and 
svg/repaint/mask-object-bounding-box-shrink.html.
Testing shows that the former still repaints correctly. The latter fails to 
repaint, but I think that reflects
the fact that SVG should probably treat all post-layout repaints as full 
repaints (webkit.org/b/265723).

* LayoutTests/fast/repaint/hidpi-transform-on-subpixel-repaintrect-ex

[webkit-changes] [WebKit/WebKit] c6fb01: RenderLayer::recursiveUpdateLayerPositions() no lo...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c6fb0168de49b784a40b3f4d9a843dd408ad0869
  
https://github.com/WebKit/WebKit/commit/c6fb0168de49b784a40b3f4d9a843dd408ad0869
  Author: Simon Fraser 
  Date:   2023-12-04 (Mon, 04 Dec 2023)

  Changed paths:
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h

  Log Message:
  ---
  RenderLayer::recursiveUpdateLayerPositions() no longer needs a 
RenderGeometryMap
https://bugs.webkit.org/show_bug.cgi?id=265821
rdar://119153457

Reviewed by Alan Baradlay.

Now that we no longer call `outlineBoundsForRepaint()` in 
`RenderLayer::computeRepaintRects()`
we don't need to pass a RenderGeometryMap around, which means that it's more 
efficient for
`recursiveUpdateLayerPositions()` to just not create and maintain one (the 
pushing and popping
is not free).

This is a minor progression on some MotionMark subtests.

* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateLayerPositionsAfterStyleChange):
(WebCore::RenderLayer::updateLayerPositionsAfterLayout):
(WebCore::RenderLayer::recursiveUpdateLayerPositions):
(WebCore::RenderLayer::computeRepaintRects):
(WebCore::RenderLayer::updateLayerPositionsAfterOverflowScroll):
(WebCore::RenderLayer::updateLayerPositionsAfterDocumentScroll):
(WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll):
* Source/WebCore/rendering/RenderLayer.h:
(WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll):

Canonical link: https://commits.webkit.org/271541@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 13f0d2: Avoid forced layouts because of scrollTo(0, 0) if t...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 13f0d241c7f2d817c79ec142f33b54b35597b42b
  
https://github.com/WebKit/WebKit/commit/13f0d241c7f2d817c79ec142f33b54b35597b42b
  Author: Simon Fraser 
  Date:   2023-12-12 (Tue, 12 Dec 2023)

  Changed paths:
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/ElementRareData.h
M Source/WebCore/dom/EventTarget.h
M Source/WebCore/platform/ScrollTypes.cpp
M Source/WebCore/platform/ScrollTypes.h
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp

  Log Message:
  ---
  Avoid forced layouts because of scrollTo(0,0) if the element hasn't scrolled
https://bugs.webkit.org/show_bug.cgi?id=262012
rdar://115732977

Reviewed by Ryosuke Niwa.

We force a layout in `Element::scrollTo()` to ensure that style is up-to-date 
for checking
`document().scrollingElement()`, and to layout so that scrollHeight etc is 
computed.

But we can avoid this layout if the scrollTo() is to 0,0, and if this element's 
scroll
position was already 0,0. Do this by updating 
`Element::savedLayerScrollPosition()` on
every scroll (instead of just when a RenderLayer is torn down), and check this, 
and some
other conditions, before short-circuiting the scrollTo.

We have to store a bit in EventTargetFlags to say if this element has ever had 
a smooth scroll because
`scrollTo(0, 500, { behavior: smooth})` immediately followed by scrollTo(0, 0)` 
needs
to not short-circuit in order to cancel the animated scroll (tested by
imported/w3c/web-platform-tests/css/cssom-view/scroll-behavior-element.html).

* Source/WebCore/dom/Element.cpp:
(WebCore::Element::scrollTo):
(WebCore::Element::setScrollLeft):
(WebCore::Element::setScrollTop):
(WebCore::Element::removedFromAncestor):
(WebCore::Element::setSavedLayerScrollPositionSlow):
* Source/WebCore/dom/Element.h:
(WebCore::Element::hasEverHadSmoothScroll const):
(WebCore::Element::setHasEverHadSmoothScroll):
(WebCore::Element::setSavedLayerScrollPosition):
* Source/WebCore/dom/ElementRareData.h:
(WebCore::ElementRareData::savedLayerScrollPosition const):
(WebCore::ElementRareData::setSavedLayerScrollPosition):
* Source/WebCore/dom/EventTarget.h:
* Source/WebCore/platform/ScrollTypes.cpp:
(WebCore::operator<<):
* Source/WebCore/platform/ScrollTypes.h:
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::clear):
(WebCore::RenderLayerScrollableArea::restoreScrollPosition):
(WebCore::RenderLayerScrollableArea::scrollTo):

Canonical link: https://commits.webkit.org/271943@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 835f5f: [macOS] Make it possible to test smart magnify in ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 835f5fc2d0ec6def0f44cfc3d343d7f45cc82588
  
https://github.com/WebKit/WebKit/commit/835f5fc2d0ec6def0f44cfc3d343d7f45cc82588
  Author: Simon Fraser 
  Date:   2023-12-15 (Fri, 15 Dec 2023)

  Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M LayoutTests/resources/ui-helper.js
A LayoutTests/view-gestures/resources/view-gesture-helpers.js
A LayoutTests/view-gestures/smart-magnify/double-tap-zoom-expected.txt
A LayoutTests/view-gestures/smart-magnify/double-tap-zoom.html
M Source/WebCore/PAL/pal/spi/mac/IOKitSPIMac.h
M Source/WebCore/page/WheelEventTestMonitor.cpp
M Source/WebCore/page/WheelEventTestMonitor.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M Source/WebKit/UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm
M 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
M 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in
M Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.h
M Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.mm
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/EventSenderProxy.h
M Tools/WebKitTestRunner/InjectedBundle/Bindings/EventSendingController.idl
M Tools/WebKitTestRunner/InjectedBundle/EventSendingController.cpp
M Tools/WebKitTestRunner/InjectedBundle/EventSendingController.h
M Tools/WebKitTestRunner/TestController.cpp
M Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm
M Tools/WebKitTestRunner/mac/EventSenderProxy.mm
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.h
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm

  Log Message:
  ---
  [macOS] Make it possible to test smart magnify in layout tests
https://bugs.webkit.org/show_bug.cgi?id=266449
rdar://119699103

Reviewed by Tim Horton.

Make it possible to write a "smart magnify" test. There are several components 
to this:
1. We teach EventSender how to generate the event, which is an NSEvent of type 
NSEventTypeSmartMagnify
   with kIOHIDEventTypeZoomToggle.
2. We allow a test to enable WKWebView magnification via UIScriptController. We 
also fix WebKitTestRunner
   to reset the magnification state between tests.
3. We give WheelEventTestMonitor a defer reason so that a test can wait for the 
zoom animation to complete
   (yes, this isn't wheel events, but the infrastructure is exactly what we 
need).
   To support this, DrawingArea::commitTransientZoom() returns an async reply, 
and
   RemoteLayerTreeDrawingAreaProxyMac::commitTransientZoom() sets up the 
deferral reason across the
   CAAnimation, and the reply from the web process that the zoom is committed.

A new test is added in LayoutTests/view-gestures/smart-magnify. In future, we 
should move the swipe
tests into this view-gestures directory.

* LayoutTests/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.async smartMagnifyAt):
(window.UIHelper.setWebViewAllowsMagnification):
* LayoutTests/view-gestures/resources/view-gesture-helpers.js: Added.
(visualViewportDescription):
* LayoutTests/view-gestures/smart-magnify/double-tap-zoom-expected.txt: Added.
* LayoutTests/view-gestures/smart-magnify/double-tap-zoom.html: Added.
* Source/WebCore/page/WheelEventTestMonitor.cpp:
(WebCore::operator<<):
* Source/WebCore/page/WheelEventTestMonitor.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::commitTransientZoom):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::sendCommitTransientZoom):
* Source/WebKit/UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm:
(WebKit::TiledCoreAnimationDrawingAreaProxy::commitTransientZoom):
* 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::commitTransientZoom):
* 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::commitTransientZ

[webkit-changes] [WebKit/WebKit] b8b07e: Rename `renderRect` to make it clear it's an absol...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b8b07e7d490fedfd868d1e7d09d7361e4ebf06ca
  
https://github.com/WebKit/WebKit/commit/b8b07e7d490fedfd868d1e7d09d7361e4ebf06ca
  Author: Simon Fraser 
  Date:   2023-12-15 (Fri, 15 Dec 2023)

  Changed paths:
M Source/WebCore/dom/Node.cpp
M Source/WebCore/dom/Node.h
M Source/WebCore/html/HTMLAttachmentElement.cpp
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M Source/WebKit/UIProcess/ViewGestureController.h
M Source/WebKit/UIProcess/ios/SmartMagnificationController.mm
M Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm
M Source/WebKit/WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.cpp
M Source/WebKit/WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.h
M Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.cpp
M Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.h
M Source/WebKit/WebProcess/WebPage/ios/FindControllerIOS.mm
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Source/WebKitLegacy/mac/DOM/WebDOMOperations.mm

  Log Message:
  ---
  Rename `renderRect` to make it clear it's an absolute rect
https://bugs.webkit.org/show_bug.cgi?id=266496
rdar://119730738

Reviewed by Alan Baradlay.

Rename Node's `renderRect` and `pixelSnappedRenderRect` functions to refer to 
absolute coordinates, since
that's what they are. Propagate this rename though view gesture geometry code, 
and the other callers.

* Source/WebCore/dom/Node.cpp:
(WebCore::Node::absoluteBoundingRect):
(WebCore::Node::renderRect): Deleted.
* Source/WebCore/dom/Node.h:
(WebCore::Node::pixelSnappedAbsoluteBoundingRect):
(WebCore::Node::pixelSnappedRenderRect): Deleted.
* Source/WebCore/html/HTMLAttachmentElement.cpp:
(WebCore::HTMLAttachmentElement::saveButtonClientRect const):
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::commitTransientZoom):
* Source/WebKit/UIProcess/ViewGestureController.h:
* Source/WebKit/UIProcess/ios/SmartMagnificationController.mm:
(WebKit::SmartMagnificationController::didCollectGeometryForSmartMagnificationGesture):
* Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm:
(WebKit::ViewGestureController::didCollectGeometryForSmartMagnificationGesture):
* Source/WebKit/WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.cpp:
(WebKit::InjectedBundleNodeHandle::absoluteBoundingRect):
(WebKit::InjectedBundleNodeHandle::renderRect): Deleted.
* Source/WebKit/WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.h:
* Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.cpp:
(WebKit::ViewGestureGeometryCollector::dispatchDidCollectGeometryForSmartMagnificationGesture):
(WebKit::ViewGestureGeometryCollector::collectGeometryForSmartMagnificationGesture):
(WebKit::ViewGestureGeometryCollector::computeZoomInformationForNode):
* Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.h:
* Source/WebKit/WebProcess/WebPage/ios/FindControllerIOS.mm:
(WebKit::FindController::updateFindIndicator):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::potentialTapAtPosition):
* Source/WebKitLegacy/mac/DOM/WebDOMOperations.mm:
(-[DOMNode _renderRect:]):

Canonical link: https://commits.webkit.org/272154@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6c744e: [macOS WK2] Some minor smart magnify cleanup

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6c744e1658390e109a97abd5cb4e339832b25a2f
  
https://github.com/WebKit/WebKit/commit/6c744e1658390e109a97abd5cb4e339832b25a2f
  Author: Simon Fraser 
  Date:   2023-12-15 (Fri, 15 Dec 2023)

  Changed paths:
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M Source/WebKit/UIProcess/ViewGestureController.h
M Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm
M Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.cpp
M Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.h
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm

  Log Message:
  ---
  [macOS WK2] Some minor smart magnify cleanup
https://bugs.webkit.org/show_bug.cgi?id=266527
rdar://119746523

Reviewed by Tim Horton, Chris Dumez and Wenson Hsieh.

Rename the 'origin' argument in various ViewGestureController smart 
magnification functions
to `gestureLocationInViewCoordinates`, since that's what it is.

Add some more `ViewGestures` logging, and convert some `Scrolling` logging to 
that channel.

Other minor code changes for cleanliness and readability. No behavior changes.

* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::commitTransientZoom):
* Source/WebKit/UIProcess/ViewGestureController.h:
* Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm:
(WebKit::ViewGestureController::handleSmartMagnificationGesture):
(WebKit::ViewGestureController::didCollectGeometryForSmartMagnificationGesture):
* Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.cpp:
(WebKit::ViewGestureGeometryCollector::collectGeometryForSmartMagnificationGesture):
* Source/WebKit/WebProcess/WebPage/ViewGestureGeometryCollector.h:
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::commitTransientZoom):
(WebKit::TiledCoreAnimationDrawingArea::applyTransientZoomToPage):

Canonical link: https://commits.webkit.org/272164@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3a5a2d: REGRESSION (UI-side compositing): Unable to scroll...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3a5a2dc6d7b110ce9ee677a6f033b51343b1ddb0
  
https://github.com/WebKit/WebKit/commit/3a5a2dc6d7b110ce9ee677a6f033b51343b1ddb0
  Author: Simon Fraser 
  Date:   2023-12-18 (Mon, 18 Dec 2023)

  Changed paths:
A 
LayoutTests/view-gestures/smart-magnify/double-tap-zoom-scroll-above-top-expected.html
A 
LayoutTests/view-gestures/smart-magnify/double-tap-zoom-scroll-above-top.html
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm

  Log Message:
  ---
  REGRESSION (UI-side compositing): Unable to scroll to top of page after 
double tapping trackpad causes page to scroll down
https://bugs.webkit.org/show_bug.cgi?id=266529
rdar://116419609

Reviewed by Tim Horton.

The smart magnify gesture (two-finger double tap on the trackpad) results in 
some combination of
scrolling and zooming. 
`RemoteLayerTreeDrawingAreaProxyMac::commitTransientZoom()` uses a
CAAnimation to animate to the final state, but the completion handler of that 
animation put the
transform directly onto the `layerForPageScale`.

That's OK if the gesture results in a scale change; that transform will get 
replaced by one that
comes from the web process. However, if a gesture just resulted in a scroll 
with no scale change,
we never get a new transform from the web process, so we leave that transform on
`layerForPageScale`. This transform has a translation baked in, so this causes 
a permanent scroll
offset.

So we have to stop shoving the transform onto this layer. This revealed an 
issue where there was a
jump when the animation was removed. Fixing this just requires two things:

1. Delay removing the transient zoom animations until we know the web process 
has committed the new
   scale and scroll position (via a `callAfterNextPresentationUpdate()`).

2. Override any scroll position changes that come from the web process before 
this by adding a
   CAAnimation onto the scrolled contents layer which overrides the `position` 
property. If we
   don't do this, scroll position changes cause a flash of offset content. This 
requires tracking
   m_pageScrollingLayerID, but that information was already in the transaction 
for banner hookup.

* 
LayoutTests/view-gestures/smart-magnify/double-tap-zoom-scroll-above-top-expected.html:
 Added.
* 
LayoutTests/view-gestures/smart-magnify/double-tap-zoom-scroll-above-top.html: 
Added.
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::didCommitLayerTree):
(WebKit::fillFowardsAnimationWithKeyPath):
(WebKit::transientZoomTransformOverrideAnimation):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::applyTransientZoomToLayer):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::removeTransientZoomFromLayer):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::commitTransientZoom):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::sendCommitTransientZoom):

Canonical link: https://commits.webkit.org/272229@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 30a915: [UnifiedPDF] Going from Single Page to Two Pages d...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 30a915b5c386b5ecfc81b82be6d52072e8e6d108
  
https://github.com/WebKit/WebKit/commit/30a915b5c386b5ecfc81b82be6d52072e8e6d108
  Author: Simon Fraser 
  Date:   2023-12-19 (Tue, 19 Dec 2023)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Going from Single Page to Two Pages doesn't reset the scroll 
position
https://bugs.webkit.org/show_bug.cgi?id=266610
rdar://119520473

Reviewed by Tim Horton.

When changing from the single page to the 2-page view in the UnifiedPDF viewer, 
the document can get shorter,
so we may have to adjust the scroll position.

Do this after PDF layout. In order to set the scroll position, we need to 
implement `requestScrollToPosition()`
to talk to the relevant ScrollingCoordinator.

Not testable because you can't change the view mode in a test.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateScrollingExtents):
(WebKit::UnifiedPDFPlugin::requestScrollToPosition):
(WebKit::toWebCoreCursorType):

Canonical link: https://commits.webkit.org/272279@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 55195d: [UnifiedPDF] Scrollbars don't show

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 55195d817a86c40943811d2e3dd5d3b7ca10c76c
  
https://github.com/WebKit/WebKit/commit/55195d817a86c40943811d2e3dd5d3b7ca10c76c
  Author: Simon Fraser 
  Date:   2023-12-20 (Wed, 20 Dec 2023)

  Changed paths:
M 
LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree-dynamic-expected.txt
M LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree-dynamic.html
M LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree-expected.txt
M LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree.html
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp

  Log Message:
  ---
  [UnifiedPDF] Scrollbars don't show
https://bugs.webkit.org/show_bug.cgi?id=266644
rdar://119848161

Reviewed by Tim Horton.

Fix the UnifiedPDFPlugin to display scrollbars. This involves:

1. Making layers for scrollbars, via `layerForVerticalScrollbar()` and friends.
   Implement `viewRelativeVerticalScrollbarRect()` etc in the base class to 
share
   code related to scrollbar geometry. In the non-UI-side compositing 
configuration,
   those scrollbar layers are painted into via 
`UnifiedPDFPlugin::paintContents()`.

2. Make a m_overflowControlsContainer layer to host the overflow controls 
layers,
   which makes it easier to ensure that scrollbars are always above the content.

3. `UnifiedPDFPlugin::updateLayout()` takes scrollbars into account when
   doing layout, potentially doing two passes when they change as a result of 
layout.

4. Respond to changes between overlay and legacy scrollbars. This is handled
   by `UnifiedPDFPlugin::scrollbarStyleChanged()` which just updates layout,
   since scrollbars an affect the available space for the PDF content.

* LayoutTests/compositing/plugins/pdf/pdf-in-embed-expected.txt:
* LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree-dynamic-expected.txt:
* LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree-dynamic.html: The 
embed has to be small enough to trigger scrolling.
* LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree-expected.txt:
* LayoutTests/compositing/plugins/pdf/pdf-scrolling-tree.html: The embed has to 
be small enough to trigger scrolling.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::viewRelativeVerticalScrollbarRect const):
(WebKit::PDFPluginBase::viewRelativeHorizontalScrollbarRect const):
(WebKit::PDFPluginBase::viewRelativeScrollCornerRect const):
(WebKit::PDFPluginBase::updateScrollbars):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::ensureLayers):
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):
(WebKit::UnifiedPDFPlugin::didChangeSettings):
(WebKit::UnifiedPDFPlugin::paintContents):
(WebKit::UnifiedPDFPlugin::availableContentsRect const):
(WebKit::UnifiedPDFPlugin::updateLayout):
(WebKit::UnifiedPDFPlugin::updateOverflowControlsLayers):
(WebKit::UnifiedPDFPlugin::positionOverflowControlsLayers):
(WebKit::UnifiedPDFPlugin::invalidateScrollbarRect):
(WebKit::UnifiedPDFPlugin::invalidateScrollCornerRect):
(WebKit::UnifiedPDFPlugin::layerForHorizontalScrollbar const):
(WebKit::UnifiedPDFPlugin::layerForVerticalScrollbar const):
(WebKit::UnifiedPDFPlugin::layerForScrollCorner const):
(WebKit::UnifiedPDFPlugin::scrollingMode const):
(WebKit::UnifiedPDFPlugin::scrollbarStyleChanged):
(WebKit::UnifiedPDFPlugin::updateScrollbars):
(WebKit::UnifiedPDFPlugin::updateScrollingExtents):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::horizontalScrollbar):
(WebKit::PluginView::verticalScrollbar):

Canonical link: https://commits.webkit.org/272350@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 91d66c: [UnifedPDF] Can't click-drag on scrollbars

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 91d66cef29098316aa703b797edbcee089df4781
  
https://github.com/WebKit/WebKit/commit/91d66cef29098316aa703b797edbcee089df4781
  Author: Simon Fraser 
  Date:   2023-12-20 (Wed, 20 Dec 2023)

  Changed paths:
M Source/WebCore/platform/ScrollableArea.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifedPDF] Can't click-drag on scrollbars
https://bugs.webkit.org/show_bug.cgi?id=266718
rdar://119874627

Reviewed by Tim Horton.

In order to get click-dragging of UnifedPDF scrollbars to work, we need:
1. Tracking of m_lastMousePositionInPluginCoordinates, so move that down to 
PDFPluginBase
2. A RemoteScrollbarsController, so override createScrollbarsController() to 
call through
   to the ChromeClient.

* Source/WebCore/platform/ScrollableArea.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::createScrollbarsController):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):

Canonical link: https://commits.webkit.org/272385@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6a8d6e: [UnifiedPDF] Odd gray backgrounds for short PDFs o...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6a8d6ea573305298d429d9f26bf546196f2a04b6
  
https://github.com/WebKit/WebKit/commit/6a8d6ea573305298d429d9f26bf546196f2a04b6
  Author: Simon Fraser 
  Date:   2023-12-20 (Wed, 20 Dec 2023)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Odd gray backgrounds for short PDFs or when rubberbanding
https://bugs.webkit.org/show_bug.cgi?id=266746
rdar://119849112

Reviewed by Tim Horton.

Instead of painting the gray background into the scrolling tiles, put it on the 
root layer as a GraphicsLayer
background color. Also size the root layer to fill the plugin view.

This makes the PDF tiles transparent where not covered by pages. We may in 
future decide to make them opaque
and paint the color if necessary for performance.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::ensureLayers):
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):
(WebKit::UnifiedPDFPlugin::paintContents):

Canonical link: https://commits.webkit.org/272398@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d70968: [UnifiedPDF] Vertical scrollbar is too short after...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d70968a09fbce20180836668cfe081a333d81834
  
https://github.com/WebKit/WebKit/commit/d70968a09fbce20180836668cfe081a333d81834
  Author: Simon Fraser 
  Date:   2023-12-20 (Wed, 20 Dec 2023)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm

  Log Message:
  ---
  [UnifiedPDF] Vertical scrollbar is too short after zooming
https://bugs.webkit.org/show_bug.cgi?id=266747
rdar://119963305

Reviewed by Tim Horton.

When leaving space for the scroll corner, we need to subtract the height of the
horizontal scrollbar, not its width.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::viewRelativeVerticalScrollbarRect const):

Canonical link: https://commits.webkit.org/272400@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e353e4: [UnifiedPDF] PDF in style embed renders in the wro...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e353e4fd2798c593c6f57501514bc3c717e93f2e
  
https://github.com/WebKit/WebKit/commit/e353e4fd2798c593c6f57501514bc3c717e93f2e
  Author: Simon Fraser 
  Date:   2023-12-21 (Thu, 21 Dec 2023)

  Changed paths:
A LayoutTests/compositing/plugins/pdf/pdf-in-styled-embed-expected.txt
A LayoutTests/compositing/plugins/pdf/pdf-in-styled-embed.html
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] PDF in style embed renders in the wrong place
https://bugs.webkit.org/show_bug.cgi?id=266750
rdar://119969233

Reviewed by Alan Baradlay.

The UnifiedPDFPlugin's root layer has to be positioned relative to the 
compositing
layer of the RenderEmbeddedObject, which can be inflated by borders, outlines, 
padding
and shadows.

RenderLayerBacking knows best how to compute the right offset, so let it 
position
the plugin's root layer.

* LayoutTests/compositing/plugins/pdf/pdf-in-styled-embed-expected.txt: Added.
* LayoutTests/compositing/plugins/pdf/pdf-in-styled-embed.html: Added.
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAfterWidgetResize):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):

Canonical link: https://commits.webkit.org/272443@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6ff980: Remove CGContextDrawsWithCorrectShadowOffsets() code

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6ff9800218d27e12f4d5327cae0cc94abcc6f918
  
https://github.com/WebKit/WebKit/commit/6ff9800218d27e12f4d5327cae0cc94abcc6f918
  Author: Simon Fraser 
  Date:   2023-12-21 (Thu, 21 Dec 2023)

  Changed paths:
M Source/WebCore/PAL/pal/spi/cg/CoreGraphicsSPI.h
M Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp

  Log Message:
  ---
  Remove CGContextDrawsWithCorrectShadowOffsets() code
https://bugs.webkit.org/show_bug.cgi?id=260939
rdar://115090272

Reviewed by Chris Dumez.

The relevant bugs were fixed long ago; we no longer need this code.

* Source/WebCore/PAL/pal/spi/cg/CoreGraphicsSPI.h:
* Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp:
(WebCore::GraphicsContextCG::setCGShadow):
(WebCore::applyShadowOffsetWorkaroundIfNeeded): Deleted.

Canonical link: https://commits.webkit.org/272444@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 31001e: [UnifiedPDF] PDF content is offset in snapshots

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 31001e9814a15c1e2639a8fb4836b1ec65cc2fd1
  
https://github.com/WebKit/WebKit/commit/31001e9814a15c1e2639a8fb4836b1ec65cc2fd1
  Author: Simon Fraser 
  Date:   2023-12-21 (Thu, 21 Dec 2023)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/Plugins/PluginView.h

  Log Message:
  ---
  [UnifiedPDF] PDF content is offset in snapshots
https://bugs.webkit.org/show_bug.cgi?id=266791
rdar://120014898

Reviewed by Tim Horton.

UnifiedPDFPlugin had two issues related to painting; first, it painted the PDF 
content as well
as rendering it into a layer. Second, that painted content was in the wrong 
location.

Fix the first issue by checking for a snapshotting paint in 
PluginView::paint(), and returning
if not snapshotting and the plugin uses 
PluginLayerHostingStrategy::GraphicsLayer, which is only
true for the UnifiedPDFPlugin. Also factor the PDF painting into a new function,
UnifiedPDFPlugin::paintPDFContent(), which avoids the confusion of passing in 
m_contentsLayer
when doing a software paint.

The second issue is also fixed in PluginView::paint(); we have to undo the 
context transform
that RenderWidget::paintContents() does.

Minor cleanup in PluginView::invalidateRect() to use a Checked<> pointer.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paint):
(WebKit::UnifiedPDFPlugin::paintContents):
(WebKit::UnifiedPDFPlugin::paintPDFContent):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::protectedPlugin const):
(WebKit::PluginView::paint):
(WebKit::PluginView::checkedRenderer const):
(WebKit::PluginView::invalidateRect):
* Source/WebKit/WebProcess/Plugins/PluginView.h:

Canonical link: https://commits.webkit.org/272449@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d7611e: Horizontal scrollbars unusable with rtl element

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d7611e7b6b1a052b3d55fefc52f620a45b6089ed
  
https://github.com/WebKit/WebKit/commit/d7611e7b6b1a052b3d55fefc52f620a45b6089ed
  Author: Simon Fraser 
  Date:   2023-12-22 (Fri, 22 Dec 2023)

  Changed paths:
M LayoutTests/platform/ios/TestExpectations
A LayoutTests/scrollbars/scrollbar-drag-thumb-rtl-expected.txt
A LayoutTests/scrollbars/scrollbar-drag-thumb-rtl.html
M Source/WebCore/platform/ScrollableArea.cpp
M Source/WebCore/platform/Scrollbar.cpp
M Source/WebCore/rendering/RenderListBox.cpp
M Source/WebCore/rendering/RenderListBox.h

  Log Message:
  ---
  Horizontal scrollbars unusable with rtl element
https://bugs.webkit.org/show_bug.cgi?id=256995
rdar://109858866

Reviewed by Aditya Keerthi and Antti Koivisto.

Fix scroll offset/position confusion in 
ScrollableArea::scrollToOffsetWithoutAnimation().
In RTL, the offset is zero-based, but the position is relative to the scroll 
origin.

This also revealed offset/position confusion in RenderListBox, breaking 
vertical-rl
tests. Fix that code to do proper offset/position conversions.

* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/scrollbars/scrollbar-drag-thumb-rtl-expected.txt: Added.
* LayoutTests/scrollbars/scrollbar-drag-thumb-rtl.html: Added.
* Source/WebCore/platform/ScrollableArea.cpp:
(WebCore::ScrollableArea::scrollToOffsetWithoutAnimation):
* Source/WebCore/platform/Scrollbar.cpp:
(WebCore::Scrollbar::moveThumb):
* Source/WebCore/rendering/RenderListBox.cpp:
(WebCore::RenderListBox::scrollToRevealElementAtListIndex):
(WebCore::RenderListBox::scrollToPosition):
(WebCore::RenderListBox::setLogicalScrollTop):
* Source/WebCore/rendering/RenderListBox.h:

Canonical link: https://commits.webkit.org/272466@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a2e00c: Null check the ScrollingCoordinator in a few places

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a2e00ce3745e2380bb8748079cb80ca8d3ac8752
  
https://github.com/WebKit/WebKit/commit/a2e00ce3745e2380bb8748079cb80ca8d3ac8752
  Author: Simon Fraser 
  Date:   2024-01-02 (Tue, 02 Jan 2024)

  Changed paths:
M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  ---
  Null check the ScrollingCoordinator in a few places
https://bugs.webkit.org/show_bug.cgi?id=267002
rdar://116427384

Reviewed by Alan Baradlay.

We dereference the return value of 
RenderLayerCompositor::scrollingCoordinator() in
a couple of places without null-checking, so fix that.

* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::attachScrollingNode):
(WebCore::RenderLayerCompositor::detachScrollCoordinatedLayer):

Canonical link: https://commits.webkit.org/272588@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a50787: Various minor RenderStyle::diff() optimizations

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a507875fc8cfde9df318e7927e16f540da28c41c
  
https://github.com/WebKit/WebKit/commit/a507875fc8cfde9df318e7927e16f540da28c41c
  Author: Simon Fraser 
  Date:   2024-01-03 (Wed, 03 Jan 2024)

  Changed paths:
M Source/WebCore/platform/graphics/transforms/RotateTransformOperation.cpp
M Source/WebCore/rendering/style/BorderData.cpp
M Source/WebCore/rendering/style/RenderStyle.cpp

  Log Message:
  ---
  Various minor RenderStyle::diff() optimizations
https://bugs.webkit.org/show_bug.cgi?id=267004
rdar://120390005

Reviewed by Tim Nguyen.

Various minor optimizations, detailed below.

* Source/WebCore/platform/graphics/transforms/RotateTransformOperation.cpp:
(WebCore::RotateTransformOperation::operator== const):
Check the angle first, because it's more common to animate the angle than the 
origin.
* Source/WebCore/rendering/style/BorderData.cpp:
(WebCore::BorderData::isEquivalentForPainting const):
Use arePointingToEqualData() to check for pointer equality first.
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::changeRequiresLayout const):
Check for m_svgStyle pointer equality first.
(WebCore::RenderStyle::changeRequiresRepaint const):
Check for m_svgStyle pointer equality first.
(WebCore::RenderStyle::changeRequiresRepaintIfText const):
Check for pointer equality of the various classes before checking their members.

Canonical link: https://commits.webkit.org/272645@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b2c286: Remove the isLoadingCustomFonts() check in FontCa...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b2c286c1a7c173f053bbca6fb2d53e1d5806e0a1
  
https://github.com/WebKit/WebKit/commit/b2c286c1a7c173f053bbca6fb2d53e1d5806e0a1
  Author: Simon Fraser 
  Date:   2024-01-04 (Thu, 04 Jan 2024)

  Changed paths:
M Source/WebCore/platform/graphics/FontCascade.cpp

  Log Message:
  ---
  Remove the isLoadingCustomFonts() check in  FontCascade::operator==
https://bugs.webkit.org/show_bug.cgi?id=267083


Reviewed by Cameron McCormack.

The first landing of custom font support (20474@main) made it so that any 
FontCascade
comparison would return false if either side was loading custom fonts. But this 
makes
it impossible to use pointer equality in RenderStyle::diff() code, and could 
trigger
lots of extra layouts and painting while custom fonts are loading.

FontCascade::operator== already checks both `generation()` and 
`fontSelectorVersion()`
which increment as fonts load, so remove the isLoadingCustomFonts() check.

* Source/WebCore/platform/graphics/FontCascade.cpp:
(WebCore::FontCascade::operator== const):

Canonical link: https://commits.webkit.org/272673@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 473160: Inline RenderBoxModelObject::computedCSSPadding()

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 473160f0c11f2474feb47cc12cbe381a2e016525
  
https://github.com/WebKit/WebKit/commit/473160f0c11f2474feb47cc12cbe381a2e016525
  Author: Simon Fraser 
  Date:   2024-01-05 (Fri, 05 Jan 2024)

  Changed paths:
M Source/WebCore/rendering/RenderBoxModelObject.cpp
M Source/WebCore/rendering/RenderBoxModelObject.h
M Source/WebCore/rendering/RenderBoxModelObjectInlines.h

  Log Message:
  ---
  Inline RenderBoxModelObject::computedCSSPadding()
https://bugs.webkit.org/show_bug.cgi?id=267120
rdar://120510598

Reviewed by Wenson Hsieh and Tim Nguyen.

RenderBoxModelObject::computedCSSPadding() is fairly hot on some traces, and not
inlined because it was needlessly marked as WEBCORE_EXPORT, so inline it.

* Source/WebCore/rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::computedCSSPadding const): Deleted.
* Source/WebCore/rendering/RenderBoxModelObject.h:
* Source/WebCore/rendering/RenderBoxModelObjectInlines.h:
(WebCore::RenderBoxModelObject::computedCSSPadding const):

Canonical link: https://commits.webkit.org/272695@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 82682c: Optimize SVGRenderSupport::layoutDifferentRootIfNe...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 82682c1a0a673dc7b4ae28fef1ee9c8a3209d4fd
  
https://github.com/WebKit/WebKit/commit/82682c1a0a673dc7b4ae28fef1ee9c8a3209d4fd
  Author: Simon Fraser 
  Date:   2024-01-05 (Fri, 05 Jan 2024)

  Changed paths:
M Source/WebCore/rendering/svg/SVGRenderSupport.cpp
M Source/WebCore/rendering/svg/SVGResources.cpp
M Source/WebCore/rendering/svg/SVGResources.h

  Log Message:
  ---
  Optimize SVGRenderSupport::layoutDifferentRootIfNeeded()
https://bugs.webkit.org/show_bug.cgi?id=267014
rdar://120392477

Reviewed by Said Abou-Hallawa.

SVGRenderSupport::layoutDifferentRootIfNeeded() shows up on profiles of the 
Suits
MotionMark subtest.

We only need to call findTreeRootObject() on the renderer if the there are any  
clipper, masker,
filters etc are present, so pass the RenderElement which is the client of the 
SVG resources,
and lazily call findTreeRootObject() on it when necessary.

Also check m_clipperFilterMaskerData and m_markerData before calling the lambda 
on their
contents.

* Source/WebCore/rendering/svg/SVGRenderSupport.cpp:
(WebCore::SVGRenderSupport::layoutDifferentRootIfNeeded):
* Source/WebCore/rendering/svg/SVGResources.cpp:
(WebCore::SVGResources::layoutDifferentRootIfNeeded):
* Source/WebCore/rendering/svg/SVGResources.h:

Canonical link: https://commits.webkit.org/272696@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ef19f9: Cache "containsOnlyASCIIWhitespace" on Node

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ef19f93eea992586bc6636a05d1445d0200ca626
  
https://github.com/WebKit/WebKit/commit/ef19f93eea992586bc6636a05d1445d0200ca626
  Author: Simon Fraser 
  Date:   2024-01-05 (Fri, 05 Jan 2024)

  Changed paths:
M Source/WebCore/dom/CharacterData.cpp
M Source/WebCore/dom/CharacterData.h
M Source/WebCore/dom/Node.h
M Source/WebCore/html/HTMLObjectElement.cpp
M Source/WebCore/inspector/agents/InspectorDOMAgent.cpp
M Source/WebCore/rendering/updating/RenderTreeUpdater.cpp
M Source/WebCore/style/StyleTreeResolver.cpp

  Log Message:
  ---
  Cache "containsOnlyASCIIWhitespace" on Node
https://bugs.webkit.org/show_bug.cgi?id=267010
rdar://120391238

Reviewed by Ryosuke Niwa.

The call to `text->containsOnlyASCIIWhitespace()` in 
TreeResolver::resolveComposedTree() shows up on MotionMark
profiles (in the Design subtest). We can cache this state for Text nodes by 
using two bits from Node's StateFlags.

The "known" state is cleared by functions on CharacterData that mutate the 
content.

* Source/WebCore/dom/CharacterData.cpp:
(WebCore::CharacterData::substringData const):
(WebCore::CharacterData::parserAppendData):
(WebCore::CharacterData::setDataWithoutUpdate):
(WebCore::CharacterData::setDataAndUpdate):
(WebCore::CharacterData::containsOnlyASCIIWhitespace const):
(WebCore::CharacterData::substringData): Deleted.
* Source/WebCore/dom/CharacterData.h:
(WebCore::CharacterData::setDataWithoutUpdate): Deleted.
* Source/WebCore/dom/Node.h:
* Source/WebCore/html/HTMLObjectElement.cpp:
(WebCore::HTMLObjectElement::hasFallbackContent const):
(WebCore::preventsParentObjectFromExposure):
* Source/WebCore/inspector/agents/InspectorDOMAgent.cpp:
(WebCore::containsOnlyASCIIWhitespace):
* Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:
(WebCore::RenderTreeUpdater::updateRenderTree):
(WebCore::RenderTreeUpdater::textRendererIsNeeded):
* Source/WebCore/style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::resolveComposedTree):

Canonical link: https://commits.webkit.org/272724@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a762e4: Prepare for MotionMark 1.3 in testing infrastructure

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a762e46e5f2fce85f55d14f4fee7e82f6868b885
  
https://github.com/WebKit/WebKit/commit/a762e46e5f2fce85f55d14f4fee7e82f6868b885
  Author: Simon Fraser 
  Date:   2024-01-09 (Tue, 09 Jan 2024)

  Changed paths:
R 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/signposts/MotionMark1.3-tentative.patch
A 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/signposts/MotionMark1.3.patch
R 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webdriver/MotionMark1.3-tentative.patch
A 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webdriver/MotionMark1.3.patch
R 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webserver/MotionMark1.3-tentative.patch
A 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webserver/MotionMark1.3.patch
M Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark.plan
R 
Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark1.3-tentative.plan
A Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark1.3.plan

  Log Message:
  ---
  Prepare for MotionMark 1.3 in testing infrastructure
https://bugs.webkit.org/show_bug.cgi?id=267308
rdar://120756294

Reviewed by Dewei Zhu.

Add patch and plan files for MotionMark 1.3 
(https://github.com/WebKit/MotionMark/releases/tag/release%2FMotionMark1.3)

* 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/signposts/MotionMark1.3.patch:
 Renamed from 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/signposts/MotionMark1.3-tentative.patch.
* 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webdriver/MotionMark1.3.patch:
 Renamed from 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webdriver/MotionMark1.3-tentative.patch.
* 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webserver/MotionMark1.3.patch:
 Renamed from 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/webserver/MotionMark1.3-tentative.patch.
* Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark.plan:
* Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark1.3.plan: 
Renamed from 
Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark1.3-tentative.plan.

Canonical link: https://commits.webkit.org/272838@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a30be9: Update the version of MotionMark 1.3 used for perf...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a30be9ad6873fdd8bee60485591fe66db48bb72c
  
https://github.com/WebKit/WebKit/commit/a30be9ad6873fdd8bee60485591fe66db48bb72c
  Author: Simon Fraser 
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
M 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/signposts/MotionMark1.3.patch
M Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark1.3.plan

  Log Message:
  ---
  Update the version of MotionMark 1.3 used for perf testing
https://bugs.webkit.org/show_bug.cgi?id=267363
rdar://120803393

Reviewed by Dewei Zhu.

Update the version of MotionMark to 
https://github.com/WebKit/MotionMark/commit/5d9c88136d59c11daf78d539c73e4e3e88c091ab.

* 
Tools/Scripts/webkitpy/benchmark_runner/data/patches/signposts/MotionMark1.3.patch:
* Tools/Scripts/webkitpy/benchmark_runner/data/plans/motionmark1.3.plan:

Canonical link: https://commits.webkit.org/272878@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8c75d0: Media-query sensitive meta tags may not get update...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8c75d0ea90cef0785d346b3839295dda8aa857d3
  
https://github.com/WebKit/WebKit/commit/8c75d0ea90cef0785d346b3839295dda8aa857d3
  Author: Simon Fraser 
  Date:   2024-01-11 (Thu, 11 Jan 2024)

  Changed paths:
M Source/WebCore/html/HTMLMetaElement.cpp
M Source/WebCore/page/LocalFrameViewLayoutContext.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp

  Log Message:
  ---
  Media-query sensitive meta tags may not get updated after some style changes
https://bugs.webkit.org/show_bug.cgi?id=267423
rdar://120854167

Reviewed by Antti Koivisto.

https://github.com/WebKit/WebKit/pull/22531 caused the 
TestWebKitAPI.WKWebViewThemeColor.KVO
API test to break, when changing the to the `print` media type failed to cause 
a change of
theme color when the theme meta tag had `media=screen`.

That PR reduces the frequency of style diffs caused by FontCascade differences. 
In the API
test, this results in a change to the `print` media type no longer triggering a 
layout on
the (empty) document. Since the layout no longer occurs, we never hit
`updateStyleForLayout()`, so don't end up calling 
`updateElementsAffectedByMediaQueries()`.

Fix by calling `document.updateElementsAffectedByMediaQueries()` from
`Page::updateStyleAfterChangeInEnvironment()`, and have 
`WebPage::setOverriddenMediaType()`
call `updateStyleAfterChangeInEnvironment()` which seems like the right thing 
to do.

* Source/WebCore/html/HTMLMetaElement.cpp: Whitespace.
* Source/WebCore/page/LocalFrameViewLayoutContext.cpp: Whitespace.
* Source/WebCore/page/Page.cpp:
(WebCore::Page::updateStyleAfterChangeInEnvironment):
* Source/WebCore/page/Page.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::setOverriddenMediaType):

Canonical link: https://commits.webkit.org/272947@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2cc096: compositing/updates/animation-non-composited.html ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2cc096e109bacf90ff156b0d186df2f056c349a2
  
https://github.com/WebKit/WebKit/commit/2cc096e109bacf90ff156b0d186df2f056c349a2
  Author: Simon Fraser 
  Date:   2024-01-15 (Mon, 15 Jan 2024)

  Changed paths:
M LayoutTests/compositing/updates/animation-non-composited.html

  Log Message:
  ---
  compositing/updates/animation-non-composited.html is flaky
https://bugs.webkit.org/show_bug.cgi?id=267553


Reviewed by Anne van Kesteren.

In this test, the setTimeout(0) races with the m_updateCompositingLayersTimer 
timer in
RenderLayerCompositor, which is scheduled via 
`RenderLayerCompositor::rootBackgroundColorOrTransparencyChanged()`
as a result of the background color changing. Because of this, we sometimes get 
a compositing update
count of 1.

So delay the start of the animation on a requestAnimationFrame().

* LayoutTests/compositing/updates/animation-non-composited.html:

Canonical link: https://commits.webkit.org/273052@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e213ae: Font caches need to be invalidated when the font c...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e213ae74ae87ab8274aec65366b7981129b6f882
  
https://github.com/WebKit/WebKit/commit/e213ae74ae87ab8274aec65366b7981129b6f882
  Author: Simon Fraser 
  Date:   2024-01-16 (Tue, 16 Jan 2024)

  Changed paths:
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/platform/graphics/cocoa/FontCacheCocoa.mm
M Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp

  Log Message:
  ---
  Font caches need to be invalidated when the font content size category changes
https://bugs.webkit.org/show_bug.cgi?id=267564
rdar://121024996

Reviewed by Antoine Quint.

On iOS with https://github.com/WebKit/WebKit/pull/22531, 
fast/attachment/attachment-dynamic-type.html fails,
showing that fonts failed to update after we change `contentSizeCategory()` via 
Internals.

When the content size category changes via the user setting it in the UI, we 
get notified
via a `UIContentSizeCategoryDidChangeNotification` notification, and in 
response to this
we call `FontCache::invalidateAllFontCaches()` (see 
`fontCacheRegisteredFontsChangedNotificationCallback()`).
So we need to do the same when the content size category is changed through 
Internals.

This caused 
webanimations/css-animation-effect-target-change-and-get-keyframes-crash.html 
to crash
with a null m_target, so add a null check in 
`computeCSSAnimationBlendingKeyframes()`.

* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
* Source/WebCore/platform/graphics/cocoa/FontCacheCocoa.mm:
(WebCore::setContentSizeCategory):
* Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:
(WebCore::FontCache::platformInit):

Canonical link: https://commits.webkit.org/273070@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 15ebca: svg/compositing/transform-change-repainting-viewBo...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 15ebca4a77aaa3598046f640bbb4db3636af1b16
  
https://github.com/WebKit/WebKit/commit/15ebca4a77aaa3598046f640bbb4db3636af1b16
  Author: Simon Fraser 
  Date:   2024-01-16 (Tue, 16 Jan 2024)

  Changed paths:
M LayoutTests/compositing/updates/animation-non-composited.html
M 
LayoutTests/svg/compositing/transform-change-repainting-viewBox-expected.html
M LayoutTests/svg/compositing/transform-change-repainting-viewBox.html

  Log Message:
  ---
  svg/compositing/transform-change-repainting-viewBox.html should not enable 
layer borders
https://bugs.webkit.org/show_bug.cgi?id=267588
rdar://121052864

Reviewed by Tim Nguyen.

Turn off layer borders, remove pixel tolerance, and de-tab.

* LayoutTests/compositing/updates/animation-non-composited.html: Drive-by nit 
fix.
* LayoutTests/svg/compositing/transform-change-repainting-viewBox-expected.html:
* LayoutTests/svg/compositing/transform-change-repainting-viewBox.html:

Canonical link: https://commits.webkit.org/273090@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] bd33a8: Incorrect wheel event behavior with Shadow DOM

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: bd33a8e97f273f32b0034c9fed1f7ce52b460393
  
https://github.com/WebKit/WebKit/commit/bd33a8e97f273f32b0034c9fed1f7ce52b460393
  Author: Simon Fraser 
  Date:   2024-01-18 (Thu, 18 Jan 2024)

  Changed paths:
A 
LayoutTests/fast/scrolling/mac/wheel-event-in-overflow-with-shadow-dom-expected.txt
A 
LayoutTests/fast/scrolling/mac/wheel-event-in-overflow-with-shadow-dom.html
M Source/WebCore/page/mac/EventHandlerMac.mm

  Log Message:
  ---
  Incorrect wheel event behavior with Shadow DOM
https://bugs.webkit.org/show_bug.cgi?id=264469
rdar://118496293

Reviewed by Ryosuke Niwa and Chris Dumez.

`findEnclosingScrollableContainer()` needs to use `parentInComposedTree()` to 
find the enclosing
ScrollableArea for the overflow scroll.

* 
LayoutTests/fast/scrolling/mac/wheel-event-in-overflow-with-shadow-dom-expected.txt:
 Added.
* LayoutTests/fast/scrolling/mac/wheel-event-in-overflow-with-shadow-dom.html: 
Added.
* Source/WebCore/page/mac/EventHandlerMac.mm:
(WebCore::findEnclosingScrollableContainer):

Canonical link: https://commits.webkit.org/273181@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b6ac61: [UnifedPDF] Factor incremental PDF loading code in...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b6ac61e0064cad757dd1a2a81265150c436fe00c
  
https://github.com/WebKit/WebKit/commit/b6ac61e0064cad757dd1a2a81265150c436fe00c
  Author: Simon Fraser 
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
M Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
A Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
A Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/cocoa/VideoPresentationManager.mm

  Log Message:
  ---
  [UnifedPDF] Factor incremental PDF loading code into its own class
https://bugs.webkit.org/show_bug.cgi?id=267979
rdar://121487714

Reviewed by Tim Horton.

Move the incremental PDF loading code out of PDFPlugin into its own class, 
PDFIncrementalLoader.
All the complexities of ByteRangeRequest and PDFPluginStreamLoaderClient are 
now internal to that class.
PDFPlugin makes an instance of this class when incremental loading is enabled.

In addition to moving the code, a lot of code cleanup was done:
* Use of thread-safe weak pointers
* More main thread assertions
* Type for ByteRangeRequest identifiers
* Encapsulate the CFDataRef inside PDFPluginBase
* Clearer distinction between data loaded via the main resource request, and 
byte-range requests

* Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h: Added.
(WebKit::PDFIncrementalLoader::incrementThreadsWaitingOnCallback):
(WebKit::PDFIncrementalLoader::decrementThreadsWaitingOnCallback):
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm: Added.
(WebKit::ByteRangeRequest::ByteRangeRequest):
(WebKit::ByteRangeRequest::streamLoader):
(WebKit::ByteRangeRequest::setStreamLoader):
(WebKit::ByteRangeRequest::addData):
(WebKit::ByteRangeRequest::position const):
(WebKit::ByteRangeRequest::count const):
(WebKit::ByteRangeRequest::accumulatedData const):
(WebKit::ByteRangeRequest::clearStreamLoader):
(WebKit::ByteRangeRequest::completeWithBytes):
(WebKit::ByteRangeRequest::completeWithAccumulatedData):
(WebKit::ByteRangeRequest::completeIfPossible):
(WebKit::ByteRangeRequest::completeUnconditionally):
(WebKit::PDFPluginStreamLoaderClient::PDFPluginStreamLoaderClient):
(WebKit::PDFPluginStreamLoaderClient::willSendRequest):
(WebKit::PDFPluginStreamLoaderClient::didReceiveResponse):
(WebKit::PDFPluginStreamLoaderClient::didReceiveData):
(WebKit::PDFPluginStreamLoaderClient::didFail):
(WebKit::PDFPluginStreamLoaderClient::didFinishLoading):
(WebKit::PDFIncrementalLoader::create):
(WebKit::PDFIncrementalLoader::PDFIncrementalLoader):
(WebKit::PDFIncrementalLoader::clear):
(WebKit::PDFIncrementalLoader::receivedNonLinearizedPDFSentinel):
(WebKit::PDFIncrementalLoader::documentFinishedLoading const):
(WebKit::PDFIncrementalLoader::ensureDataBufferLength):
(WebKit::PDFIncrementalLoader::appendAccumulatedDataToDataBuffer):
(WebKit::PDFIncrementalLoader::availableDataSize const):
(WebKit::PDFIncrementalLoader::dataPtrForRange const):
(WebKit::PDFIncrementalLoader::incrementalPDFStreamDidFinishLoading):
(WebKit::PDFIncrementalLoader::incrementalPDFStreamDidReceiveData):
(WebKit::PDFIncrementalLoader::incrementalPDFStreamDidFail):
(WebKit::PDFIncrementalLoader::unconditionalCompleteOutstandingRangeRequests):
(WebKit::PDFIncrementalLoader::getResourceBytesAtPositionAfterLoadingComplete):
(WebKit::PDFIncrementalLoader::getResourceBytesAtPosition):
(WebKit::PDFIncrementalLoader::streamLoaderDidStart):
(WebKit::PDFIncrementalLoader::byteRangeRequestForStreamLoader):
(WebKit::PDFIncrementalLoader::forgetStreamLoader):
(WebKit::PDFIncrementalLoader::cancelAndForgetStreamLoader):
(WebKit::PDFIncrementalLoader::identifierForLoader):
(WebKit::PDFIncrementalLoader::removeOutstandingByteRangeRequest):
(WebKit::PDFIncrementalLoader::requestCompleteIfPossible):
(WebKit::PDFIncrementalLoader::requestDidCompleteWithBytes):
(WebKit::PDFIncrementalLoader::requestDidCompleteWithAccumulatedData):
(WebKit::dataProviderGetByteRangesCallback):
(WebKit::dataProviderGetBytesAtPositionCallback):
(WebKit::dataProviderReleaseInfoCallback):
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
(WebKit::PDFIncrementalLoader::dataProviderGetByteRanges):
(WebKit::PDFIncrementalLoader::transitionToMainThreadDocument):
(WebKit::PDFIncrementalLoader::threadEntry):
(WebKit::PDFIncrementalLoader::pdfLog):
(WebKit::PDFIncrementalLoader::logStreamLoader):
(WebKit::PDFIncrementalLoader::logState):
* Source/WebKit

[webkit-changes] [WebKit/WebKit] 15911b: Fix the internal iOS build after 273506@main

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 15911ba29d2c2d764c956852a9fccc68e382ccb8
  
https://github.com/WebKit/WebKit/commit/15911ba29d2c2d764c956852a9fccc68e382ccb8
  Author: Simon Fraser 
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm

  Log Message:
  ---
  Fix the internal iOS build after 273506@main
https://bugs.webkit.org/show_bug.cgi?id=268103
rdar://121621651

Unreviewed build fix.

Fix some HAVE(INCREMENTAL_PDF_APIS) and forward declare PDFDocument.

* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::teardown):
(WebKit::PDFPluginBase::streamDidReceiveData):
(WebKit::PDFPluginBase::streamDidFinishLoading):
(WebKit::PDFPluginBase::streamDidFail):

Canonical link: https://commits.webkit.org/273534@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6e17ae: Fix the internal iOS build again after 273506@main

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6e17ae0127758789a3a126499a34ac586ea3c427
  
https://github.com/WebKit/WebKit/commit/6e17ae0127758789a3a126499a34ac586ea3c427
  Author: Simon Fraser 
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h

  Log Message:
  ---
  Fix the internal iOS build again after 273506@main
https://bugs.webkit.org/show_bug.cgi?id=268123
rdar://121630550

Unreviewed build fix.

More fixes post 273506@main and 273534@main.

* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:

Canonical link: https://commits.webkit.org/273538@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b720c5: Make network-simulator.py a little more useful

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b720c5d85f453afe369678698d8d44fb244f21f0
  
https://github.com/WebKit/WebKit/commit/b720c5d85f453afe369678698d8d44fb244f21f0
  Author: Simon Fraser 
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
A LayoutTests/http/tests/harness/resources/chunked.txt
A LayoutTests/http/tests/harness/slow-loading-html-iframe-expected.html
A LayoutTests/http/tests/harness/slow-loading-html-iframe.html
M LayoutTests/http/tests/resources/network-simulator.py

  Log Message:
  ---
  Make network-simulator.py a little more useful
https://bugs.webkit.org/show_bug.cgi?id=268142
rdar://121642038

Reviewed by Dewei Zhu and Alexey Proskuryakov.

Enhance http/tests/resources/network-simulator.py to support an initial 
response delay,
and variable chunk size, and chunk delay. This makes it possible to use to 
simulate
a slow-loading resource (potentially replacing the various "slow.pl" scripts we 
already have).

Add PDF as a valid resource type, and fix some typos.

A new test exercises the added functionality.

* LayoutTests/http/tests/harness/resources/chunked.txt: Added.
* LayoutTests/http/tests/harness/slow-loading-html-iframe.html: Added.
* LayoutTests/http/tests/resources/network-simulator.py:
(content_type):
(generate_response):
(file_to_stdout):
(chunked_file_to_stdout):
(handle_increase_resource_count_command):
(handle_increate_resource_count_command): Deleted.

Canonical link: https://commits.webkit.org/273607@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 32f6aa: REGRESSION (273506@main): Going back to a PDF file...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 32f6aad73de0963f299af91b32f225a9c5c1d1d8
  
https://github.com/WebKit/WebKit/commit/32f6aad73de0963f299af91b32f225a9c5c1d1d8
  Author: Simon Fraser 
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm

  Log Message:
  ---
  REGRESSION (273506@main): Going back to a PDF file fails to render the PDF
https://bugs.webkit.org/show_bug.cgi?id=268237
rdar://121757735

Reviewed by Tim Horton.

In the refactoring in 273506@main, the loading fallback for non-linearized PDF 
lost
the check of `m_incrementalPDFLoadingEnabled`. Without that, we never create the
PDF document in the fallback case, for some loading timings.

Not currently testable.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::streamDidFinishLoading):

Canonical link: https://commits.webkit.org/273614@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 385ddc: [UnifiedPDF] Hook up incremental PDF loading

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 385ddccf0be7190f406577d4eb8c7bd9a2144255
  
https://github.com/WebKit/WebKit/commit/385ddccf0be7190f406577d4eb8c7bd9a2144255
  Author: Simon Fraser 
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/http/tests/pdf/linearized-pdf-in-iframe-expected.html
A LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html
A LayoutTests/http/tests/pdf/resources/linearized.pdf
A LayoutTests/http/tests/pdf/resources/non-linearized.pdf
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp

  Log Message:
  ---
  [UnifiedPDF] Hook up incremental PDF loading
https://bugs.webkit.org/show_bug.cgi?id=268209
rdar://118550660

Reviewed by Tim Horton.

Hook up a `PDFIncrementalLoader` in PDFPluginBase so that the UnifiedPDF plugin 
can
use one.

This is moved into a new function, called from the `PluginView` constructor, so
that it's called after the object is fully constructed.

Added an http test that streams out a linearized PDF.

* LayoutTests/TestExpectations:
* LayoutTests/http/tests/pdf/linearized-pdf-in-iframe-expected.html: Added.
* LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html: Added.
* LayoutTests/http/tests/pdf/resources/linearized.pdf: Added.
* LayoutTests/http/tests/pdf/resources/non-linearized.pdf: Added.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::PDFPlugin):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::startLoading):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::PluginView):

Canonical link: https://commits.webkit.org/273670@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2fc837: [UnifiedPDF] Can't zoom out below scale 1

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2fc8377fb2908ec7003d3e8591aa5a418bfdcf54
  
https://github.com/WebKit/WebKit/commit/2fc8377fb2908ec7003d3e8591aa5a418bfdcf54
  Author: Simon Fraser 
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
M Source/WebKit/UIProcess/ViewGestureController.cpp
M Source/WebKit/UIProcess/ViewGestureController.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/UIProcess/gtk/ViewGestureControllerGtk.cpp
M Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp

  Log Message:
  ---
  [UnifiedPDF] Can't zoom out below scale 1
https://bugs.webkit.org/show_bug.cgi?id=268310
rdar://121866624

Reviewed by Tim Horton.

For the PDF plugin, we need to allow minimum zoom scales of less than 1. Add 
support
for this by allowing the plugin to vend min and max scales, keeping track of 
them
in WebPageProxy. ViewGestureController reads them from there.

We compute the min and max elastic zoom scales relative to the min and max,
using multipliers that gives the same results as the old hard-coded values.

The PDF min and max scale values match those in PDFKit.

* Source/WebKit/UIProcess/ViewGestureController.cpp:
(WebKit::ViewGestureController::endMagnificationGesture):
* Source/WebKit/UIProcess/ViewGestureController.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::minPageZoomFactor const):
(WebKit::WebPageProxy::maxPageZoomFactor const):
(WebKit::WebPageProxy::mainFramePluginHandlesPageScaleGestureDidChange):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
* Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm:
(WebKit::ViewGestureController::resistanceForDelta):
(WebKit::ViewGestureController::handleMagnificationGestureEvent):
(WebKit::ViewGestureController::didCollectGeometryForSmartMagnificationGesture):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::minScaleFactor const):
(WebKit::PDFPluginBase::maxScaleFactor const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::layoutSingleColumn):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::initializePlugin):

Canonical link: https://commits.webkit.org/273725@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e61686: [UnifiedPDF] scrolling is broken after navigating ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e6168698e8a3a0a3b2df3c26747b814b55f5174f
  
https://github.com/WebKit/WebKit/commit/e6168698e8a3a0a3b2df3c26747b814b55f5174f
  Author: Simon Fraser 
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
A 
LayoutTests/compositing/plugins/pdf/pdf-in-iframe-scrolling-tree-after-back-expected.txt
A 
LayoutTests/compositing/plugins/pdf/pdf-in-iframe-scrolling-tree-after-back.html
A LayoutTests/compositing/plugins/pdf/resources/go-back.html
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] scrolling is broken after navigating back to a PDF
https://bugs.webkit.org/show_bug.cgi?id=268228
rdar://120847163

Reviewed by Tim Horton.

When navigating back to a main frame PDF using the UnifiedPDF plugin, we'd fail 
to hook up
the scrolling tree, resulting in assertions in debug builds, and scrolling 
failures in release.

The bug happens because when navigating back, the ordering of creating the 
plugin's scrolling
node, and the main frame's scrolling node is different; the plugin node gets 
created first,
but with no parent, so it's thrown away, and the scrolling coordinator 
re-creates it later
with the same ID, but without the necessary layers.

Fix by creating the plugin's scrolling node on demand, when scrollingNodeID() 
is called.

The new test doesn't not actually replicate the bug (we can't yet test main 
frame PDFs),
but seems like a good test to have that exercises history.back() in an iframe 
with a PDF.

* 
LayoutTests/compositing/plugins/pdf/pdf-in-iframe-scrolling-tree-after-back-expected.txt:
 Added.
* 
LayoutTests/compositing/plugins/pdf/pdf-in-iframe-scrolling-tree-after-back.html:
 Added.
* LayoutTests/compositing/plugins/pdf/resources/go-back.html: Added.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::ensureLayers):
(WebKit::UnifiedPDFPlugin::scrollingNodeID const):
(WebKit::UnifiedPDFPlugin::createScrollingNodeIfNecessary):

Canonical link: https://commits.webkit.org/273727@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4fd244: [UnifiedPDF] When zooming out below 1, the content...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4fd2440d7ed92da3cc44cfcb64bc01137a492ba3
  
https://github.com/WebKit/WebKit/commit/4fd2440d7ed92da3cc44cfcb64bc01137a492ba3
  Author: Simon Fraser 
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] When zooming out below 1, the content should be centered
https://bugs.webkit.org/show_bug.cgi?id=268355
rdar://121900997

Reviewed by Tim Horton.

In `UnifiedPDFPlugin::setPageScaleFactor()`, when the scale is less than 1, 
compute the extra
space, and add half on the left size via a post-scale translate on the contents 
layer. We also
need to clamp scroll positions from prevent them from going negative.

In `UnifiedPDFPlugin::updateLayerHierarchy()`, the contents layer size is 
pre-scaling, so
we should use `documentSize()`. This fixes truncated tiles when zoomed out.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::documentSize const):
(WebKit::UnifiedPDFPlugin::contentsSize const):

Canonical link: https://commits.webkit.org/273729@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] eb3399: [UnifiedPDF] Fix hit-testing when zoomed

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: eb3399bb2c9b06b232eb049c1f2a7ff9cb86f6b7
  
https://github.com/WebKit/WebKit/commit/eb3399bb2c9b06b232eb049c1f2a7ff9cb86f6b7
  Author: Simon Fraser 
  Date:   2024-01-30 (Tue, 30 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Fix hit-testing when zoomed
https://bugs.webkit.org/show_bug.cgi?id=268357
rdar://121903219

Reviewed by Tim Horton.

Factor the side padding computation into its own function.

Fix `UnifiedPDFPlugin::convertFromPluginToDocument()` to take side padding and 
scale factor
into account. Add some logging.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::sidePaddingWidth const):
(WebKit::UnifiedPDFPlugin::convertFromPluginToDocument const):
(WebKit::operator<<):
(WebKit::UnifiedPDFPlugin::pdfElementTypesForPluginPoint const):

Canonical link: https://commits.webkit.org/273758@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] abc473: Crash in MomentumEventDispatcher::handleWheelEvent()

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: abc473b91584189cf995d69d0a34194fa3f7720b
  
https://github.com/WebKit/WebKit/commit/abc473b91584189cf995d69d0a34194fa3f7720b
  Author: Simon Fraser 
  Date:   2023-04-26 (Wed, 26 Apr 2023)

  Changed paths:
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp

  Log Message:
  ---
  Crash in MomentumEventDispatcher::handleWheelEvent()
https://bugs.webkit.org/show_bug.cgi?id=255885
rdar://108204029

Reviewed by Tim Horton.

A wheel event bouncing to the scrolling thread can race with 
RemoteLayerTreeEventDispatcher::invalidate()
and get handled after m_momentumEventDispatcher has been nulled out.

The scrolling thread entry points all already null-check the scrolling tree 
(whose access is thread-safe),
so we can null out m_scrollingTree in 
RemoteLayerTreeEventDispatcher::invalidate() as a reliable signal
that invalidation has happened.

Also standardize the "strongThis" vs "protectedThis" naming in this file.

* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp:
(WebKit::RemoteLayerTreeEventDispatcher::invalidate):
(WebKit::RemoteLayerTreeEventDispatcher::scrollingThreadHandleWheelEvent):
(WebKit::RemoteLayerTreeEventDispatcher::wheelEventHandlingCompleted):
(WebKit::RemoteLayerTreeEventDispatcher::startOrStopDisplayLink):
(WebKit::RemoteLayerTreeEventDispatcher::waitForRenderingUpdateCompletionOrTimeout):
(WebKit::RemoteLayerTreeEventDispatcher::flushMomentumEventLoggingSoon):

Canonical link: https://commits.webkit.org/263426@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ccbeb1: Hairline pixel crack around background-clip: text

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ccbeb1e341f13f05bf4167f0f7253d8d87383da0
  
https://github.com/WebKit/WebKit/commit/ccbeb1e341f13f05bf4167f0f7253d8d87383da0
  Author: Simon Fraser 
  Date:   2023-04-28 (Fri, 28 Apr 2023)

  Changed paths:
A LayoutTests/fast/css/background-clip-text-hairline-expected.html
A LayoutTests/fast/css/background-clip-text-hairline.html
M Source/WebCore/rendering/BackgroundPainter.cpp

  Log Message:
  ---
  Hairline pixel crack around background-clip: text
https://bugs.webkit.org/show_bug.cgi?id=179333
rdar://54325642

Reviewed by Alan Baradlay.

When there is some non-integral transform (or a non axis-aligned transform) in 
the CTM, we could
show some antialiasing noise at the edge of `background-clip: text` regions. 
This noise was not
in the buffer used as a mask, but seemed to come from some the transparency 
layer operations.

We can work around it by inflating maskRect by a pixel on each size, which pads 
the intermediate
buffer, and the size of the transparency layer.

* LayoutTests/fast/css/background-clip-text-hairline-expected.html: Added.
* LayoutTests/fast/css/background-clip-text-hairline.html: Added.
* Source/WebCore/rendering/BackgroundPainter.cpp:
(WebCore::BackgroundPainter::paintFillLayer):

Canonical link: https://commits.webkit.org/263526@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 77bb47: WebContent crash: Invalid message dispatched virtu...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 77bb4783cf75a060cca04bdbe5fd780c3c39c587
  
https://github.com/WebKit/WebKit/commit/77bb4783cf75a060cca04bdbe5fd780c3c39c587
  Author: Simon Fraser 
  Date:   2023-05-02 (Tue, 02 May 2023)

  Changed paths:
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer-expected.txt
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer.html
M Source/WebCore/rendering/LayerAncestorClippingStack.cpp
M Source/WebCore/rendering/RenderLayerBacking.cpp

  Log Message:
  ---
  WebContent crash: Invalid message dispatched virtual void 
WebKit::RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations(const
 RemoteLayerTreeHost &)
https://bugs.webkit.org/show_bug.cgi?id=256195
rdar://108204370

Reviewed by Tim Horton.

262413@main added two MESSAGE_CHECK() in
RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations() that 
fire when the UI
process receives a scrolling tree with invalid cross-references; 
ScrollingTreePositionedNodes or
ScrollingTreeOverflowScrollProxyNodes with invalid references to overflow 
scrolling nodes.

Sites triggering this MESSAGE_CHECK() all hit a pattern where an 
`overflow:scroll` element became
non-scrollable, but we failed to clean up ScrollingTreeOverflowScrollProxyNodes 
that referenced this
overflow scroll. ScrollingTreeOverflowScrollProxyNodes are created when the 
overflow scroller has
non paint-order descendants (typically positioned) which need to move then the 
scroller scrolls;
each of these has a LayerAncestorClippingStack which tracks the layers and 
scrolling tree nodes for
non paint-order ancestors that affect the given layer.

The bug was that we'd clear the LayerAncestorClippingStack without 
unregistering the
ScrollingTreeOverflowScrollProxyNodes that it referenced, so when
RenderLayerBacking::updateAncestorClipping() is removing the 
m_ancestorClippingStack, call
LayerAncestorClippingStack::clear() to unregister those nodes.

Also have LayerAncestorClippingStack::clear() unparent the scrolling layer as 
well as the clipping
layer.

* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer-expected.txt:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer.html:
 Added.
* Source/WebCore/rendering/LayerAncestorClippingStack.cpp:
(WebCore::LayerAncestorClippingStack::clear):
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAncestorClipping):

Canonical link: https://commits.webkit.org/263590@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 46572d: Assert that the scrolling tree is valid, and fix i...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 46572d8428cba7c77d2ea1182c7a1c9502b12ab8
  
https://github.com/WebKit/WebKit/commit/46572d8428cba7c77d2ea1182c7a1c9502b12ab8
  Author: Simon Fraser 
  Date:   2023-05-02 (Tue, 02 May 2023)

  Changed paths:
M Source/WebCore/page/scrolling/ScrollingStateTree.cpp
M Source/WebCore/page/scrolling/ScrollingStateTree.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h

  Log Message:
  ---
  Assert that the scrolling tree is valid, and fix issues with negative z-index 
layers
https://bugs.webkit.org/show_bug.cgi?id=256193
rdar://108769471

Reviewed by Tim Horton.

To make it easier to detect invalid scrolling trees which can result in 
MESSAGE_CHECKs
(rdar://108204370) add code to check the validity of the scrolling tree in the 
web process, and
assert when not valid. This code checks that nodes that have cross-references 
to other scrolling
tree nodes actually point to live nodes.

This detected a case where we have incorrect behavior (tested by
scrollingcoordinator/scrolling-tree/scroller-with-negative-z-child.html and two 
similar tests); when
an overflow:scroll has composited descendant which is not a paint-order child, 
the child gets an
"ancestor clipping stack" which points to 
ScrollingStateOverflowScrollProxyNodes, which reference
the actual overflow scrolling node. However, if the child has negative z-index, 
we encounter the
child before the overflow scroller so fail to find its scrolling tree node.

Fix this by keeping track of RenderLayers with unresolved scrolling tree 
references in
m_layersWithUnresolvedRelations, and updating them at the end of the "update 
backing and hierarchy"
compositing phase.

* Source/WebCore/page/scrolling/ScrollingStateTree.cpp:
(WebCore::ScrollingStateTree::commit):
(WebCore::ScrollingStateTree::traverse const):
(WebCore::ScrollingStateTree::isValid const):
* Source/WebCore/page/scrolling/ScrollingStateTree.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateCompositingLayers):
(WebCore::RenderLayerCompositor::setupScrollProxyRelatedOverflowScrollingNode):
(WebCore::RenderLayerCompositor::updateScrollingNodeForScrollingProxyRole):
(WebCore::RenderLayerCompositor::resolveScrollingTreeRelationships):
* Source/WebCore/rendering/RenderLayerCompositor.h:

Canonical link: https://commits.webkit.org/263620@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 522450: Cherry-pick 263590@main (77bb4783cf75). https://bu...

[Simon Fraser]

  Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: 5224503460cdae8668c38ab410016469e9dd6a5d
  
https://github.com/WebKit/WebKit/commit/5224503460cdae8668c38ab410016469e9dd6a5d
  Author: Simon Fraser 
  Date:   2023-05-03 (Wed, 03 May 2023)

  Changed paths:
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer-expected.txt
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer.html
M Source/WebCore/rendering/LayerAncestorClippingStack.cpp
M Source/WebCore/rendering/RenderLayerBacking.cpp

  Log Message:
  ---
  Cherry-pick 263590@main (77bb4783cf75). 
https://bugs.webkit.org/show_bug.cgi?id=256195

WebContent crash: Invalid message dispatched virtual void 
WebKit::RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations(const
 RemoteLayerTreeHost &)
https://bugs.webkit.org/show_bug.cgi?id=256195
rdar://108204370

Reviewed by Tim Horton.

262413@main added two MESSAGE_CHECK() in
RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations() 
that fire when the UI
process receives a scrolling tree with invalid cross-references; 
ScrollingTreePositionedNodes or
ScrollingTreeOverflowScrollProxyNodes with invalid references to overflow 
scrolling nodes.

Sites triggering this MESSAGE_CHECK() all hit a pattern where an 
`overflow:scroll` element became
non-scrollable, but we failed to clean up 
ScrollingTreeOverflowScrollProxyNodes that referenced this
overflow scroll. ScrollingTreeOverflowScrollProxyNodes are created when the 
overflow scroller has
non paint-order descendants (typically positioned) which need to move then 
the scroller scrolls;
each of these has a LayerAncestorClippingStack which tracks the layers and 
scrolling tree nodes for
non paint-order ancestors that affect the given layer.

The bug was that we'd clear the LayerAncestorClippingStack without 
unregistering the
ScrollingTreeOverflowScrollProxyNodes that it referenced, so when
RenderLayerBacking::updateAncestorClipping() is removing the 
m_ancestorClippingStack, call
LayerAncestorClippingStack::clear() to unregister those nodes.

Also have LayerAncestorClippingStack::clear() unparent the scrolling layer 
as well as the clipping
layer.

* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer-expected.txt:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer.html:
 Added.
* Source/WebCore/rendering/LayerAncestorClippingStack.cpp:
(WebCore::LayerAncestorClippingStack::clear):
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAncestorClipping):

Canonical link: https://commits.webkit.org/263590@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 406e57: Cherry-pick 263590@main (77bb4783cf75). https://bu...

[Simon Fraser]

  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: 406e5713ae613847ba6b87af3862d41a909f76f3
  
https://github.com/WebKit/WebKit/commit/406e5713ae613847ba6b87af3862d41a909f76f3
  Author: Simon Fraser 
  Date:   2023-05-03 (Wed, 03 May 2023)

  Changed paths:
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer-expected.txt
A 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer.html
M Source/WebCore/rendering/LayerAncestorClippingStack.cpp
M Source/WebCore/rendering/RenderLayerBacking.cpp

  Log Message:
  ---
  Cherry-pick 263590@main (77bb4783cf75). 
https://bugs.webkit.org/show_bug.cgi?id=256195

WebContent crash: Invalid message dispatched virtual void 
WebKit::RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations(const
 RemoteLayerTreeHost &)
https://bugs.webkit.org/show_bug.cgi?id=256195
rdar://108204370

Reviewed by Tim Horton.

262413@main added two MESSAGE_CHECK() in
RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations() 
that fire when the UI
process receives a scrolling tree with invalid cross-references; 
ScrollingTreePositionedNodes or
ScrollingTreeOverflowScrollProxyNodes with invalid references to overflow 
scrolling nodes.

Sites triggering this MESSAGE_CHECK() all hit a pattern where an 
`overflow:scroll` element became
non-scrollable, but we failed to clean up 
ScrollingTreeOverflowScrollProxyNodes that referenced this
overflow scroll. ScrollingTreeOverflowScrollProxyNodes are created when the 
overflow scroller has
non paint-order descendants (typically positioned) which need to move then 
the scroller scrolls;
each of these has a LayerAncestorClippingStack which tracks the layers and 
scrolling tree nodes for
non paint-order ancestors that affect the given layer.

The bug was that we'd clear the LayerAncestorClippingStack without 
unregistering the
ScrollingTreeOverflowScrollProxyNodes that it referenced, so when
RenderLayerBacking::updateAncestorClipping() is removing the 
m_ancestorClippingStack, call
LayerAncestorClippingStack::clear() to unregister those nodes.

Also have LayerAncestorClippingStack::clear() unparent the scrolling layer 
as well as the clipping
layer.

* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer-expected.txt:
 Added.
* 
LayoutTests/scrollingcoordinator/scrolling-tree/scroller-with-proxy-nodes-loses-layer.html:
 Added.
* Source/WebCore/rendering/LayerAncestorClippingStack.cpp:
(WebCore::LayerAncestorClippingStack::clear):
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAncestorClipping):

Canonical link: https://commits.webkit.org/263590@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3a9fba: REGRESSION(263286@main): [ Debug ] ASSERTION FAILE...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3a9fba1a0f45a422ca23ce9f157a576e938925ed
  
https://github.com/WebKit/WebKit/commit/3a9fba1a0f45a422ca23ce9f157a576e938925ed
  Author: Simon Fraser 
  Date:   2023-05-05 (Fri, 05 May 2023)

  Changed paths:
A LayoutTests/fast/layers/scroll-dimentions-dirty-assertion-expected.txt
A LayoutTests/fast/layers/scroll-dimentions-dirty-assertion.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp
M Source/WebCore/rendering/RenderLayerScrollableArea.h

  Log Message:
  ---
  REGRESSION(263286@main): [ Debug ] ASSERTION FAILED: !m_scrollDimensionsDirty
https://bugs.webkit.org/show_bug.cgi?id=256177
rdar://108753838

Reviewed by Alan Baradlay.

263286@main made us call computeHasCompositedScrollableOverflow() in more 
cases; doing this from
`RenderLayer::styleChanged()` was already wrong, because layout is not 
up-to-date then, so asking
questions about overflow geometry is not valid.

Fix by passing LayoutUpToDate; if No, the only thing we can do is to consult 
the style to see
if it prevents overflow scrolling.

In order to not regress 225752@main, we need to eagerly recompute 
layer.hasCompositedScrollableOverflow()
in RenderLayerCompositor::requiresCompositingForOverflowScrolling().

* LayoutTests/fast/layers/scroll-dimentions-dirty-assertion.html: Added.
* LayoutTests/fast/layers/scroll-dimentions-dirty-assertion-expected.txt: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects const):
* Source/WebCore/rendering/RenderLayer.h:
* Source/WebCore/rendering/RenderLayerCompositor.h:
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::computeScrollDimensions):
(WebCore::RenderLayerScrollableArea::computeHasCompositedScrollableOverflow):
* Source/WebCore/rendering/RenderLayerScrollableArea.h:

Canonical link: https://commits.webkit.org/263722@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3f7af1: [UI-side compositing] Guard against UI process han...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3f7af1859b92db6b242e50fa76450385e91628e0
  
https://github.com/WebKit/WebKit/commit/3f7af1859b92db6b242e50fa76450385e91628e0
  Author: Simon Fraser 
  Date:   2023-05-08 (Mon, 08 May 2023)

  Changed paths:
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp

  Log Message:
  ---
  [UI-side compositing] Guard against UI process hangs caused by incorrect 
frame rate data
https://bugs.webkit.org/show_bug.cgi?id=256399
rdar://108954321

Reviewed by Chris Dumez.

The spin report in the radar suggests that the Safari main thread is blocked on
RemoteLayerTreeEventDispatcher::mainThreadDisplayDidRefresh() because the 
scrolling thread
is stuck in 
RemoteLayerTreeEventDispatcher::waitForRenderingUpdateCompletionOrTimeout().
The only way this can happen is that we send a long timeout to 
m_stateCondition.waitUntil(),
but this timeout should be at most half of the frame duration.

So protect against bad m_scrollingTree->frameDuration() data by imposing a cap
at at most 32ms on this timeout, and release log if it seems wrong.

* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp:
(WebKit::RemoteLayerTreeEventDispatcher::waitForRenderingUpdateCompletionOrTimeout):

Canonical link: https://commits.webkit.org/263806@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c408a8: HysteresisActivity::impulse() thrashes a timer

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c408a82764d20985bb78dbc1b4847bfa9eb5dad9
  
https://github.com/WebKit/WebKit/commit/c408a82764d20985bb78dbc1b4847bfa9eb5dad9
  Author: Simon Fraser 
  Date:   2023-05-10 (Wed, 10 May 2023)

  Changed paths:
M Source/WTF/wtf/cf/RunLoopCF.cpp
M Source/WebCore/PAL/pal/HysteresisActivity.h

  Log Message:
  ---
  HysteresisActivity::impulse() thrashes a timer
https://bugs.webkit.org/show_bug.cgi?id=256572
rdar://109134335

Reviewed by Chris Dumez.

`HysteresisActivity::impulse()` stops and re-starts a timer simply to 
reschedule it into the future;
this destroys and recreates the timer every time, which is expensive. The 
implementation of
`HysteresisActivity::impulse()` can simply restart the timer.

We can make this cheaper by rescheduling the CFTimerRef if it hasn't fired yet, 
so add support for
this in `RunLoop::TimerBase::start()`; we can only reschedule non-repeating 
timers which haven't
fired yet, but this is fairly common.

* Source/WTF/wtf/cf/RunLoopCF.cpp:
(WTF::RunLoop::TimerBase::start):
* Source/WebCore/PAL/pal/HysteresisActivity.h:
(PAL::HysteresisActivity::start):
(PAL::HysteresisActivity::stop):
(PAL::HysteresisActivity::impulse):

Canonical link: https://commits.webkit.org/263946@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes