[webkit-changes] [WebKit/WebKit] ab75b8: [Unified PDF] pages are blank/white for 3-10s afte...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ab75b8adc9a8e4104500c8972db4d1b92cc9d2ca
  
https://github.com/WebKit/WebKit/commit/ab75b8adc9a8e4104500c8972db4d1b92cc9d2ca
  Author: Simon Fraser 
  Date:   2024-05-29 (Wed, 29 May 2024)

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

  Log Message:
  ---
  [Unified PDF] pages are blank/white for 3-10s after scrolling quickly in 2-up
https://bugs.webkit.org/show_bug.cgi?id=274862
rdar://128405116

Reviewed by Abrar Rahman Protyasha.

AsyncPDFRenderer was failing to keep track of already-requested page previews;
it never added to or removed from `m_enqueuedPagePreviews`. This caused it to
repeatedly decode previews for the same page.

Fix by adding to `m_enqueuedPagePreviews` in `generatePreviewImageForPage`
and removing in `didCompletePagePreviewRender()`, which is code factored
out of the main thread callback that was in `paintPagePreviewOnWorkQueue()`.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::generatePreviewImageForPage):
(WebKit::AsyncPDFRenderer::paintPagePreviewOnWorkQueue):
(WebKit::AsyncPDFRenderer::didCompletePagePreviewRender):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a9fa14: [UnifiedPDF] Re-enable asynchronous drawing for th...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a9fa14bfb0da82fad6677a9b9da150b3e4d5782a
  
https://github.com/WebKit/WebKit/commit/a9fa14bfb0da82fad6677a9b9da150b3e4d5782a
  Author: Simon Fraser 
  Date:   2024-05-29 (Wed, 29 May 2024)

  Changed paths:
M Source/WebCore/platform/graphics/ca/PlatformCALayer.h
M Source/WebCore/platform/graphics/ca/TileGrid.cpp
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm

  Log Message:
  ---
  [UnifiedPDF] Re-enable asynchronous drawing for the contents layer
https://bugs.webkit.org/show_bug.cgi?id=274387
rdar://128389156

Reviewed by Abrar Rahman Protyasha.

When accelerated drawing was enabled, bringing a background tab containing PDF 
to the front
could result in missing high-resolution tiles (rdar://127869064). This happened 
because the
PDF's tiled layer never sends `willRepaintTile()` callbacks in this case, since 
the code path
that deals with IOSurface volatility, in 
`RemoteLayerBackingStore::needsDisplay()()`, didn't
ever call -setNeedsDisplay() on the tile layers; it just added their backing 
stores to the
list of backing stores that needed display in 
`RemoteLayerBackingStoreCollection::backingStoreWillBeDisplayed()`.

Fix by making it possible for TileGrid to query `layer->needsDisplay()` by 
implementing
`PlatformCALayer::needsDisplay()`, and use this in 
`TileGrid::ensureTilesForRect()`.

Drive-by fix for TileGrid::ValidationPolicyFlag dumping.

* Source/WebCore/platform/graphics/ca/PlatformCALayer.h:
* Source/WebCore/platform/graphics/ca/TileGrid.cpp:
(WebCore::operator<<):
(WebCore::TileGrid::revalidateTiles):
(WebCore::TileGrid::ensureTilesForRect):
(WebCore::validationPolicyAsString): Deleted.
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h:
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::needsDisplay const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::ensureLayers):
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm:
(WebKit::PlatformCALayerRemote::needsDisplay const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 35f090: [UnifiedPDF] Crash in UnifiedPDFPlugin::repaintFor...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 35f09068c7e287e8b5466353a7cb742e33b8492a
  
https://github.com/WebKit/WebKit/commit/35f09068c7e287e8b5466353a7cb742e33b8492a
  Author: Simon Fraser 
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
A 
LayoutTests/http/tests/pdf/linearized-pdf-in-display-none-iframe-expected.txt
A LayoutTests/http/tests/pdf/linearized-pdf-in-display-none-iframe.html
M LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Crash in UnifiedPDFPlugin::repaintForIncrementalLoad() loading 
charbonnelchocolates.com page
https://bugs.webkit.org/show_bug.cgi?id=274563
rdar://128316806

Reviewed by Abrar Rahman Protyasha.

repaintForIncrementalLoad() can get called before the main thread has a 
PDFDocument or has created any layers,
so early return in that case. This web page has a `display:none` iframe with 
PDF contents, which triggered
this crash.

* 
LayoutTests/http/tests/pdf/linearized-pdf-in-display-none-iframe-expected.txt: 
Added.
* LayoutTests/http/tests/pdf/linearized-pdf-in-display-none-iframe.html: Copied 
from LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html.
* LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::repaintForIncrementalLoad):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 19697c: [UnifiedPDF] Add the concept of "rows" to PDFDocum...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 19697c5f3ef870f6c4ab84937a06156ee11d0a53
  
https://github.com/WebKit/WebKit/commit/19697c5f3ef870f6c4ab84937a06156ee11d0a53
  Author: Simon Fraser 
  Date:   2024-05-22 (Wed, 22 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Add the concept of "rows" to PDFDocumentLayout
https://bugs.webkit.org/show_bug.cgi?id=274496
rdar://128504528

Reviewed by Abrar Rahman Protyasha.

Discrete (non-scrolling) mode makes heavy use of the "row" concept, where
a row is a set of one or two pages viewed together. So introduce PDFLayoutRow,
and pass an optional row argument to nearestPageIndexForDocumentPoint().

Other namespace-related cleanup and utility additions for rows.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFDocumentLayout::isSinglePageDisplayMode):
(WebKit::PDFDocumentLayout::isTwoUpDisplayMode):
(WebKit::PDFDocumentLayout::isScrollingDisplayMode):
(WebKit::PDFDocumentLayout::isDiscreteDisplayMode):
(WebKit::PDFDocumentLayout::isSinglePageDisplayMode const):
(WebKit::PDFDocumentLayout::isTwoUpDisplayMode const):
(WebKit::PDFDocumentLayout::isScrollingDisplayMode const):
(WebKit::PDFDocumentLayout::isDiscreteDisplayMode const):
(WebKit::PDFLayoutRow::numPages const):
(WebKit::PDFLayoutRow::containsPage const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::isRightPageIndex const):
(WebKit::PDFDocumentLayout::isLastPageIndex const):
(WebKit::PDFDocumentLayout::lastPageIndex const):
(WebKit::PDFDocumentLayout::isFirstPageOfRow const):
(WebKit::PDFDocumentLayout::indexForPage const):
(WebKit::PDFDocumentLayout::nearestPageIndexForDocumentPoint const):
(WebKit::PDFDocumentLayout::pageIndexAndPagePointForDocumentYOffset const):
(WebKit::PDFDocumentLayout::updateLayout):
(WebKit::PDFDocumentLayout::rowCount const):
(WebKit::PDFDocumentLayout::rows const):
(WebKit::PDFDocumentLayout::rowForPageIndex const):
(WebKit::PDFDocumentLayout::rowIndexForPageIndex const):
(WebKit::PDFDocumentLayout::layoutBoundsForRow const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::visibleRow const):
(WebKit::UnifiedPDFPlugin::shouldDisplayPage):
(WebKit::UnifiedPDFPlugin::indexForCurrentPageInView const):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::createContextMenu const):
(WebKit::UnifiedPDFPlugin::continueAutoscroll):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1d5ea2: [UnifiedPDF] Clean up selection repaint code

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1d5ea2d61eff45027240a20a5561f6a393c7ad13
  
https://github.com/WebKit/WebKit/commit/1d5ea2d61eff45027240a20a5561f6a393c7ad13
  Author: Simon Fraser 
  Date:   2024-05-22 (Wed, 22 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Clean up selection repaint code
https://bugs.webkit.org/show_bug.cgi?id=274499
rdar://128505796

Reviewed by Abrar Rahman Protyasha.

Selection repaint currently works by computing a vector of rectangles for
the selection (and possibly the old selection too), and then repainting them.
This loses information about which page the rect belongs to, and for future
discrete mode changes we'll need this.

So repaint selections by enumerating their page coverage. If we have to
repaint the old selection, just pass it directly to 
`repaintOnSelectionChange()`.
Rename that method since it was called for selection repaint in general,
not just on active state changes.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::windowActivityDidChange):
(WebKit::UnifiedPDFPlugin::repaintOnSelectionChange):
(WebKit::UnifiedPDFPlugin::setCurrentSelection):
(WebKit::UnifiedPDFPlugin::setNeedsRepaintInDocumentRects): Deleted.
(WebKit::UnifiedPDFPlugin::boundsForSelection const): Deleted.
(WebKit::UnifiedPDFPlugin::repaintOnSelectionActiveStateChangeIfNeeded): 
Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f2967e: [UIProcess] Unsafe downcast in ScrollingTreeSticky...

[Simon Fraser]

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

  Changed paths:
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
M Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp

  Log Message:
  ---
  [UIProcess] Unsafe downcast in ScrollingTreeStickyNode::computeLayerPosition 
leading to type confusion.
https://bugs.webkit.org/show_bug.cgi?id=271395
rdar://125084284

Reviewed by Chris Dumez.

Fix various places in scrolling tree-related code where we do unchecked 
`downcast<>`s of
scrolling tree types.

* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::frameViewVisualViewportChanged):
(WebCore::AsyncScrollingCoordinator::setViewportConstraintedNodeConstraints):
* Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp:
(WebCore::ScrollingStateOverflowScrollProxyNode::dumpProperties const):
* Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp:
(WebCore::ScrollingStateStickyNode::computeLayerPosition const):
* Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp:
(WebCore::ScrollingTreeOverflowScrollProxyNode::dumpProperties const):
* Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp:
(WebCore::ScrollingTreeStickyNode::computeLayerPosition const):

Originally-landed-as: 272448.773@safari-7618-branch (052845bc6c5c). 
rdar://128088754
Canonical link: https://commits.webkit.org/278914@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a9ca27: Allow a TiledBackingClient to be a client for mult...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a9ca2712f944864544be392b09fdc34ab5d354d5
  
https://github.com/WebKit/WebKit/commit/a9ca2712f944864544be392b09fdc34ab5d354d5
  Author: Simon Fraser 
  Date:   2024-05-14 (Tue, 14 May 2024)

  Changed paths:
M Source/WebCore/Headers.cmake
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
A Source/WebCore/platform/graphics/TileGridIdentifier.h
M Source/WebCore/platform/graphics/TiledBacking.h
M Source/WebCore/platform/graphics/ca/TileController.cpp
M Source/WebCore/platform/graphics/ca/TileGrid.cpp
M Source/WebCore/platform/graphics/ca/TileGrid.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm

  Log Message:
  ---
  Allow a TiledBackingClient to be a client for multiple TiledBackings
rdar://128073464
https://bugs.webkit.org/show_bug.cgi?id=274164

Reviewed by Sammy Gill.

AsyncPDFRenderer will need to handle multiple TiledBackings in future, and 
currently
there's no way to tell which TiledBacking a client callback is associated with. 
So
pass a `TiledBacking&` to all the client callbacks.

Also make TileGrid identifiers unique; previously they were 0 or 1, but that 
allows
for confusion between TileGrids belonging to different TiledBackings. So give 
TileGrid
a TileGridIdentifier and pass it to the client callbacks.

We also have to add TiledBackingClient::willRemoveGrid() so that clients don't
accumulate data for TileGrids that have gone away (now that the identifiers are
monotonically increasing). AsyncPDFRenderer implements this, but it will 
actually
never get hit because AsyncPDFRenderer doesn't enable two-level tile caches.

* Source/WebCore/Headers.cmake:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/platform/graphics/TileGridIdentifier.h: Added.
* Source/WebCore/platform/graphics/TiledBacking.h:
* Source/WebCore/platform/graphics/ca/TileController.cpp:
(WebCore::TileController::setContentsScale):
(WebCore::TileController::setCoverageRect):
(WebCore::TileController::willRepaintTile):
(WebCore::TileController::willRemoveTile):
(WebCore::TileController::willRepaintAllTiles):
* Source/WebCore/platform/graphics/ca/TileGrid.cpp:
(WebCore::TileGrid::TileGrid):
* Source/WebCore/platform/graphics/ca/TileGrid.h:
(WebCore::TileGrid::identifier const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
(WebKit::TileForGrid::computeHash const):
(WTF::TileForGridHash::hash):
(WTF::TileForGridHash::equal):
(WTF::HashTraits::emptyValue):
(WTF::HashTraits::deletedValue):
(WebKit::AsyncPDFRenderer::TileRenderInfo::equivalentForPainting const): 
Deleted.
(WebKit::AsyncPDFRenderer::TileRenderInfo::equivalentForPaintingIgnoringContentVersion
 const): Deleted.
(WebKit::AsyncPDFRenderer::renderInfoForTile): Deleted.
(WebKit::AsyncPDFRenderer::enqueueTilePaintIfNecessary): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::willRepaintTile):
(WebKit::AsyncPDFRenderer::willRemoveTile):
(WebKit::AsyncPDFRenderer::willRepaintAllTiles):
(WebKit::AsyncPDFRenderer::coverageRectDidChange):
(WebKit::AsyncPDFRenderer::tilingScaleFactorDidChange):
(WebKit::AsyncPDFRenderer::willRemoveGrid):
(WebKit::operator<<):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5d5ae5: [UnifiedPDF] Describe selection rects in terms of ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5d5ae59db1cbc2bcc2fd74d11dce31f9a8c86ef8
  
https://github.com/WebKit/WebKit/commit/5d5ae59db1cbc2bcc2fd74d11dce31f9a8c86ef8
  Author: Simon Fraser 
  Date:   2024-05-14 (Tue, 14 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Describe selection rects in terms of PDFPageCoverage
https://bugs.webkit.org/show_bug.cgi?id=274139
rdar://128043619

Reviewed by Abrar Rahman Protyasha.

Replace `UnifiedPDFPlugin::boundsForSelection()` with 
`UnifiedPDFPlugin::pageCoverageForSelection()`
which returns a `PDFPageCoverage`, which will be useful in future when we need 
to have per-page
selection bounds info.

`UnifiedPDFPlugin::textIndicatorForSelection()` can use this, asking for only 
the first page.
`UnifiedPDFPlugin::selectionBoundsForFirstPageInDocumentSpace()` can be removed.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::pageCoverageForSelection const):
(WebKit::UnifiedPDFPlugin::boundsForSelection const):
(WebKit::UnifiedPDFPlugin::repaintOnSelectionActiveStateChangeIfNeeded):
(WebKit::UnifiedPDFPlugin::setCurrentSelection):
(WebKit::UnifiedPDFPlugin::textIndicatorForSelection):
(WebKit::UnifiedPDFPlugin::selectionBoundsForFirstPageInDocumentSpace const): 
Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1fdc4a: [UnifiedPDF] Two-up layouts are not centered

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1fdc4a13e9f8d6d7a19563ef0baf08848cbae838
  
https://github.com/WebKit/WebKit/commit/1fdc4a13e9f8d6d7a19563ef0baf08848cbae838
  Author: Simon Fraser 
  Date:   2024-05-14 (Tue, 14 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Two-up layouts are not centered
https://bugs.webkit.org/show_bug.cgi?id=274138
rdar://128042484

Reviewed by Tim Horton.

When computing the centering of two-up page rows, we need to take the margin 
between the two pages into account.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::layoutTwoUpColumn):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6f439d: [UnifiedPDF] Generalize PDFPageCoverage

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6f439da8df038386e726c054b53aa2a3218fc171
  
https://github.com/WebKit/WebKit/commit/6f439da8df038386e726c054b53aa2a3218fc171
  Author: Simon Fraser 
  Date:   2024-05-13 (Mon, 13 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Generalize PDFPageCoverage
https://bugs.webkit.org/show_bug.cgi?id=274036
rdar://127937268

Reviewed by Abrar Rahman Protyasha.

The concept of "a set of page and page-relative rectangles" will be used to
represent selection rects, among other things, so define `PDFPageCoverage` to
just be a `Vector`, and use `PDFPageCoverageAndScales` for
the struct that's used for painting-related things, that has the additional
scales in it.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::coverageRectDidChange):
(WebKit::AsyncPDFRenderer::renderInfoForTile const):
(WebKit::AsyncPDFRenderer::pdfContentChangedInRect):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.mm:
(WebKit::operator<<):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::pageCoverageForRect const):
(WebKit::UnifiedPDFPlugin::pageCoverageAndScalesForRect const):
(WebKit::UnifiedPDFPlugin::paintPDFContent):
(WebKit::UnifiedPDFPlugin::paintPDFSelection):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b64c3e: [UnifedPDF] Clean up annotation repaint code

[Simon Fraser]

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

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

  Log Message:
  ---
  [UnifedPDF] Clean up annotation repaint code
https://bugs.webkit.org/show_bug.cgi?id=274030
rdar://127915821

Reviewed by Tim Horton.

Future changes will require that we target repaints at pages, not just at the 
entire
document.

To support this, tighten up annotation repaint code to target a page (until the 
final
conversion to document coordinates). Implement a `pageIndexForAnnotation()` 
helper,
and add `setNeedsRepaintForAnnotation()`.

Implementing `revealAnnotation()` eliminates the final call site of 
`documentRectForAnnotation()`,
which can be removed.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setNeedsRepaintForAnnotation):
(WebKit::UnifiedPDFPlugin::paintHoveredAnnotationOnPage):
(WebKit::UnifiedPDFPlugin::pageIndexForAnnotation const):
(WebKit::UnifiedPDFPlugin::pageIndexWithHoveredAnnotation const):
(WebKit::UnifiedPDFPlugin::repaintAnnotationsForFormField):
(WebKit::UnifiedPDFPlugin::startTrackingAnnotation):
(WebKit::UnifiedPDFPlugin::updateTrackedAnnotation):
(WebKit::UnifiedPDFPlugin::finishTrackingAnnotation):
(WebKit::UnifiedPDFPlugin::setActiveAnnotation):
(WebKit::UnifiedPDFPlugin::revealAnnotation):
(WebKit::UnifiedPDFPlugin::annotationRectsForTesting const):
(WebKit::UnifiedPDFPlugin::documentRectForAnnotation const): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8648d7: Fix some unified sources issues, mainly in PDF code

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8648d79fb455737c205759800594756fc79b93d1
  
https://github.com/WebKit/WebKit/commit/8648d79fb455737c205759800594756fc79b93d1
  Author: Simon Fraser 
  Date:   2024-05-09 (Thu, 09 May 2024)

  Changed paths:
M Source/WebKit/Platform/ios/PlaybackSessionInterfaceLMK.h
M Source/WebKit/Platform/ios/VideoPresentationInterfaceLMK.h
M 
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDataDetectorOverlayController.h
M 
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDataDetectorOverlayController.mm

  Log Message:
  ---
  Fix some unified sources issues, mainly in PDF code
https://bugs.webkit.org/show_bug.cgi?id=273983
rdar://127848229

Reviewed by Wenson Hsieh and Aditya Keerthi.

Fix some missing WebCore:: prefixes in PDFDataDetectorOverlayController.h and
remove some `using namespace WebCore` from headers.

* Source/WebKit/Platform/ios/PlaybackSessionInterfaceLMK.h:
* Source/WebKit/Platform/ios/VideoPresentationInterfaceLMK.h:
* 
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDataDetectorOverlayController.h:
* 
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDataDetectorOverlayController.mm:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7208a1: [UnifiedPDF] When an incremental PDF completes its...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7208a15cb4af909a38d444b9e4aaf1c56fb013bd
  
https://github.com/WebKit/WebKit/commit/7208a15cb4af909a38d444b9e4aaf1c56fb013bd
  Author: Simon Fraser 
  Date:   2024-05-09 (Thu, 09 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] When an incremental PDF completes its load, blank pages are 
still visible
https://bugs.webkit.org/show_bug.cgi?id=273917
rdar://127713604

Reviewed by Tim Horton.

While loading an incremental PDF (potentially over a slow network connection), 
nothing
currently triggers repaints, so we never show pages as they load, nor do we 
repaint all
the pages when the load completes. This can leave you with blank pages until 
you scroll
or zoom.

Fix by hooking up some virtual functions on the plugin to give UnifiedPDFPlugin 
a way
to know when incremental loads progress, finish or cancel. While progressing, 
fire
a repeating timer every 1s to trigger repaints (we currently can't know which 
pages
become valid based on data ranges). Also trigger a repaint when the load 
completes.
This repaints use the coverage rect to only invalidate visible pages.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::incrementalLoadingDidProgress):
(WebKit::PDFPluginBase::incrementalLoadingDidCancel):
(WebKit::PDFPluginBase::incrementalLoadingDidFinish):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::streamDidReceiveData):
(WebKit::PDFPluginBase::streamDidFinishLoading):
(WebKit::PDFPluginBase::streamDidFail):
(WebKit::PDFPluginBase::receivedNonLinearizedPDFSentinel):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::coverageRectDidChange):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::contentsSize const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::installPDFDocument):
(WebKit::UnifiedPDFPlugin::incrementalLoadingDidProgress):
(WebKit::UnifiedPDFPlugin::incrementalLoadingDidCancel):
(WebKit::UnifiedPDFPlugin::incrementalLoadingDidFinish):
(WebKit::UnifiedPDFPlugin::updatePageBackgroundLayers):
(WebKit::UnifiedPDFPlugin::incrementalLoadingRepaintTimerFired):
(WebKit::UnifiedPDFPlugin::repaintForIncrementalLoad):
(WebKit::UnifiedPDFPlugin::paintContents):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] eb42c4: Use constexpr in some geometry classes

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: eb42c47c896489c50aea83ab8be3ca19ac393ecd
  
https://github.com/WebKit/WebKit/commit/eb42c47c896489c50aea83ab8be3ca19ac393ecd
  Author: Simon Fraser 
  Date:   2024-05-09 (Thu, 09 May 2024)

  Changed paths:
M Source/WebCore/platform/LayoutUnit.h
M Source/WebCore/platform/graphics/IntPoint.h
M Source/WebCore/platform/graphics/LayoutPoint.h

  Log Message:
  ---
  Use constexpr in some geometry classes
https://bugs.webkit.org/show_bug.cgi?id=273954
rdar://127819143

Reviewed by Wenson Hsieh and Matthieu Dubet.

Add constexpr to more constructors and functions on 
IntPoint/LayoutPoint/LayoutUnit to
allow for these types to be used in compile-time constants.

* Source/WebCore/platform/LayoutUnit.h:
(WebCore::LayoutUnit::LayoutUnit):
(WebCore::LayoutUnit::toInt const):
(WebCore::LayoutUnit::toFloat const):
(WebCore::LayoutUnit::toDouble const):
(WebCore::LayoutUnit::toUnsigned const):
(WebCore::LayoutUnit::operator int const):
(WebCore::LayoutUnit::operator float const):
(WebCore::LayoutUnit::operator double const):
(WebCore::LayoutUnit::operator bool const):
(WebCore::LayoutUnit::rawValue const):
* Source/WebCore/platform/graphics/IntPoint.h:
(WebCore::IntPoint::IntPoint):
(WebCore::IntPoint::zero):
(WebCore::IntPoint::isZero const):
(WebCore::IntPoint::x const):
(WebCore::IntPoint::y const):
(WebCore::IntPoint::expandedTo const):
(WebCore::IntPoint::shrunkTo const):
* Source/WebCore/platform/graphics/LayoutPoint.h:
(WebCore::LayoutPoint::LayoutPoint):
(WebCore::LayoutPoint::zero):
(WebCore::LayoutPoint::isZero const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5ab3ad: [UnfiedPDF] Flicker of low-resolution content when...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5ab3ad6fd099efc7c3e3a9fb10394603c6f6b928
  
https://github.com/WebKit/WebKit/commit/5ab3ad6fd099efc7c3e3a9fb10394603c6f6b928
  Author: Simon Fraser 
  Date:   2024-05-08 (Wed, 08 May 2024)

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

  Log Message:
  ---
  [UnfiedPDF] Flicker of low-resolution content when toggling a checkbox
https://bugs.webkit.org/show_bug.cgi?id=273912
rdar://127773717

Reviewed by Abrar Rahman Protyasha.

The fine-grained tile invalidation added in 277837@main adds a check on the 
"contentVersion",
which increments whenever an annotation, like a checkbox, changes state. This 
caused us to
throw away rendered tiles in `AsyncPDFRenderer::willRepaintTile()`, which 
resulted in a flash
of the blurry page background until we got the new tile.

It's OK to paint tiles with a stale contentVersion; we'll paint the new state 
once we've got
a rendered tile with the new content.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
(WebKit::AsyncPDFRenderer::TileRenderInfo::equivalentForPaintingIgnoringContentVersion
 const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::renderInfoIsValidForTile const):
(WebKit::AsyncPDFRenderer::willRepaintTile):
(WebKit::AsyncPDFRenderer::didCompleteTileRender):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7754d9: [UnifiedPDF] Text jiggles between the low-res page...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7754d9bf5ef54b9c4c58bdace2e3cd25da11df2c
  
https://github.com/WebKit/WebKit/commit/7754d9bf5ef54b9c4c58bdace2e3cd25da11df2c
  Author: Simon Fraser 
  Date:   2024-05-04 (Sat, 04 May 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Text jiggles between the low-res page snapshots and 
high-resolution tiles
https://bugs.webkit.org/show_bug.cgi?id=273727
rdar://127523619

Reviewed by Tim Horton.

Fix two issues that caused text and other content to not be perfectly aligned 
between
page previews and high-resolution tiles.

First, the scale are always non-integral, so there was some slight scaling of 
the
page preview buffers in `AsyncPDFRenderer::paintPagePreview()` since the image 
buffer size
is an expanded integral value, and when painting without a sourceRect, it 
scales the whole
buffer to fit the destination rect. We can use the same rect for source and 
destination
to avoid this.

Second, turn off CG font subpixel quantization and positioning, both of which 
can cause
glyphs to snap when drawing into the scaled-down context used for page previews.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::paintPDFPageIntoBuffer):
(WebKit::AsyncPDFRenderer::paintPagePreview):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4142d9: Rename "computedCSSPadding()" to "resolveLengthPer...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4142d950a6e7766786f1f3e2bd4650e3228628ec
  
https://github.com/WebKit/WebKit/commit/4142d950a6e7766786f1f3e2bd4650e3228628ec
  Author: Simon Fraser 
  Date:   2024-05-03 (Fri, 03 May 2024)

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

  Log Message:
  ---
  Rename "computedCSSPadding()" to "resolveLengthPercentage()"
https://bugs.webkit.org/show_bug.cgi?id=273672
rdar://problem/127473476

Reviewed by Tim Nguyen.

`computedCSSPadding()` was called for margin values in 
`RenderBox::marginBoxRect()`,
so is clearly misnamed. It's really resolving the CSS ``[1] 
values
which use the container's logical width (which is true for margins and padding)
so name it thusly.

[1] https://drafts.csswg.org/css-values-4/#mixed-percentages

* Source/WebCore/rendering/RenderBoxInlines.h:
(WebCore::RenderBox::marginBoxRect const):
* Source/WebCore/rendering/RenderBoxModelObject.h:
* Source/WebCore/rendering/RenderBoxModelObjectInlines.h:
(WebCore::RenderBoxModelObject::computedCSSPaddingAfter const):
(WebCore::RenderBoxModelObject::computedCSSPaddingBefore const):
(WebCore::RenderBoxModelObject::computedCSSPaddingBottom const):
(WebCore::RenderBoxModelObject::computedCSSPaddingEnd const):
(WebCore::RenderBoxModelObject::computedCSSPaddingLeft const):
(WebCore::RenderBoxModelObject::computedCSSPaddingRight const):
(WebCore::RenderBoxModelObject::computedCSSPaddingStart const):
(WebCore::RenderBoxModelObject::computedCSSPaddingTop const):
(WebCore::RenderBoxModelObject::resolveLengthPercentageUsingContainerLogicalWidth
 const):
(WebCore::RenderBoxModelObject::computedCSSPadding const): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 593a44: [UnifedPDF] Occasional crash at GraphicsLayerCA::s...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 593a44258e5e7a802caee79c99b7a31c807bb029
  
https://github.com/WebKit/WebKit/commit/593a44258e5e7a802caee79c99b7a31c807bb029
  Author: Simon Fraser 
  Date:   2024-05-02 (Thu, 02 May 2024)

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

  Log Message:
  ---
  [UnifedPDF] Occasional crash at GraphicsLayerCA::setNeedsDisplayInRect() with 
slow-rendering PDFs
https://bugs.webkit.org/show_bug.cgi?id=273661
rdar://127443945

Reviewed by Abrar Rahman Protyasha.

We should use `unparentAndClear()` on the GraphicsLayers to both unparent them, 
and clear their
GraphicsLayerClient. Do this on the layers which draw content, since those are 
the ones whose
clients can get called after a delay.

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

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e7ab50: [macOS] If you scroll the page without moving the ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e7ab50a7e7be8981e4a7992320befbd8b61175f2
  
https://github.com/WebKit/WebKit/commit/e7ab50a7e7be8981e4a7992320befbd8b61175f2
  Author: Simon Fraser 
  Date:   2024-05-02 (Thu, 02 May 2024)

  Changed paths:
M Source/WebCore/PAL/pal/HysteresisActivity.h
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/page/EventHandler.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebCore/HysteresisActivityTests.cpp

  Log Message:
  ---
  [macOS] If you scroll the page without moving the mouse, we fail to update 
the cursor as things scroll underneath it
https://bugs.webkit.org/show_bug.cgi?id=273335
rdar://122347347

Reviewed by Tim Horton.

If you don't move the mouse after loading a page, we'll never update the cursor 
after scrolling via the trackpad.
This is because the web process never gets an updated mouse position if the 
only events we handle are wheel
events, which are handled entirely in the UI process (in the absence of JS 
wheel event handlers).

Fix by explicitly sending `setLastKnownMousePosition()` to EventHandler when we 
know that we're not
going to send the wheel events to the web process. Only do this on the `began` 
event, since we don't want to
flood the web process with new IPC when the position doesn't change (wheel 
gestures usually keep the same
position throughout).

Even when we did send wheel events to the web process, they would fail to 
update the last known mouse position,
so fix that in `EventHandler::handleWheelEventInternal()`.

I tried to write a test, but it was impossible to make it not flakey (it's 
attached to the radar).
However, the test revealed a race condition; the reload raced with the 
WebPage::m_pageScrolledHysteresis timer,
and sometimes this would cause `WebPage::pageDidScroll()` to get called right 
after we've constructed the new
ScrollView with a zero scroll position, which would get saved to the history 
item, and clobber the previously
saved scroll offset; this caused the scroll offset to get reset on reload. Fix 
by having `WebPage::didCommitLoad()`
call `cancel()` `m_pageScrolledHysteresis`, which needs to implemented in 
HysteresisActivity, with a test.

* Source/WebCore/PAL/pal/HysteresisActivity.h:
(PAL::HysteresisActivity::cancel):
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::handleMousePressEvent):
(WebCore::EventHandler::handleMouseDoubleClickEvent):
(WebCore::EventHandler::handleMouseMoveEvent):
(WebCore::EventHandler::handleMouseReleaseEvent):
(WebCore::EventHandler::handleMouseForceEvent):
(WebCore::EventHandler::handleWheelEventInternal):
(WebCore::EventHandler::setLastKnownMousePosition):
* Source/WebCore/page/EventHandler.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::continueWheelEventHandling):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::setLastKnownMousePosition):
(WebKit::WebPage::didCommitLoad):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebCore/HysteresisActivityTests.cpp:
(TestWebKitAPI::TEST(HysteresisActivity, Cancelation)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a2d74c: REGRESSION (278263@main): [UnifiedPDF] Error about...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a2d74c7f55777b2a56cef8c4f90bb87182299a97
  
https://github.com/WebKit/WebKit/commit/a2d74c7f55777b2a56cef8c4f90bb87182299a97
  Author: Simon Fraser 
  Date:   2024-05-02 (Thu, 02 May 2024)

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

  Log Message:
  ---
  REGRESSION (278263@main): [UnifiedPDF] Error about 
ProcessCapabilities::canUseAcceleratedBuffers()
https://bugs.webkit.org/show_bug.cgi?id=273658
rdar://127462832

Reviewed by Abrar Rahman Protyasha and Sammy Gill.

We can't mix and match accelerated drawing, and accessing the platform context, 
because this
tries to map IOSurfaces into the webcontent process, which is denied by the 
sandbox.

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

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] df3719: Rename some "forceRepaint" functions for clarity

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: df37193a08ae565c630e17b04f9b2995eeedd70a
  
https://github.com/WebKit/WebKit/commit/df37193a08ae565c630e17b04f9b2995eeedd70a
  Author: Simon Fraser 
  Date:   2024-05-02 (Thu, 02 May 2024)

  Changed paths:
M Source/WebKit/UIProcess/API/C/WKPage.cpp
M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
M Source/WebKit/UIProcess/ViewGestureController.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
M Source/WebKit/UIProcess/mac/WKFullScreenWindowController.mm
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.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/RemoteLayerTree/RemoteLayerTreeDrawingArea.h
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm
M Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.cpp
M Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h

  Log Message:
  ---
  Rename some "forceRepaint" functions for clarity
https://bugs.webkit.org/show_bug.cgi?id=273596
rdar://127396058

Reviewed by Tim Horton.

Rename forceRepaint functions in WebKit to reduce the confusion about what 
"force repaint" really means.
In layout code we use "repaint" to mean "invalidate for painting", but these 
"forceRepaint" functions
do the invalidation, and then they trigger a rendering update, so call them 
"updateRenderingWithForcedRepaint".

* Source/WebKit/UIProcess/API/C/WKPage.cpp:
(WKPageForceRepaint):
* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:
* Source/WebKit/UIProcess/ViewGestureController.cpp:
(WebKit::ViewGestureController::forceRepaintIfNeeded):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::updateRenderingWithForcedRepaint):
(WebKit::WebPageProxy::forceRepaint): Deleted.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
(-[WKFullScreenWindowController _completedExitFullScreen]):
* Source/WebKit/UIProcess/mac/WKFullScreenWindowController.mm:
(-[WKFullScreenWindowController 
finishedExitFullScreenAnimationAndExitImmediately:]):
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageForceRepaint):
* 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::updateRenderingWithForcedRepaint):
(WebKit::DrawingAreaCoordinatedGraphics::updateRenderingWithForcedRepaintAsync):
(WebKit::DrawingAreaCoordinatedGraphics::forceRepaint): Deleted.
(WebKit::DrawingAreaCoordinatedGraphics::forceRepaintAsync): Deleted.
* 
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::updateRenderingWithForcedRepaint):
(WebKit::DrawingArea::forceRepaint): Deleted.
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h:
* 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::updateRenderingWithForcedRepaint):
(WebKit::RemoteLayerTreeDrawingArea::updateRenderingWithForcedRepaintAsync):
(WebKit::RemoteLayerTreeDrawingArea::forceRepaintAsync): Deleted.
(WebKit::RemoteLayerTreeDrawingArea::forceRepaint): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::updateRenderingWithForcedRepaintWithoutCallback):
(WebKit::WebPage::updateRenderingWithForcedRepaint):
(WebKit::WebPage::forceRepaintWithoutCallback): Deleted.
(WebKit::WebPage::forceRepaint): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h:
* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::updateRenderingWithForcedRepaint):
(WebKit::TiledCoreAnimationDrawingArea::updateRenderingWithForcedRepaintAsync):
(WebKit::TiledCoreAnimationDrawingArea::forceRepaint): Deleted.
(WebKit::TiledCoreAnimationDrawingArea::forceRepaintAsync): Deleted.
* Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.cpp:
(WebKit::DrawingAreaWC::updateRenderingWithForcedRepaintAsync):
(

[webkit-changes] [WebKit/WebKit] 8df037: Fetch all 4 border widths with one virtual functio...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8df0378a0254d6cf68a2e13ffbbdae61ee5f8e21
  
https://github.com/WebKit/WebKit/commit/8df0378a0254d6cf68a2e13ffbbdae61ee5f8e21
  Author: Simon Fraser 
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBoxInlines.h

  Log Message:
  ---
  Fetch all 4 border widths with one virtual function call in a few more places
https://bugs.webkit.org/show_bug.cgi?id=273521
rdar://127320983

Reviewed by Alan Baradlay.

Adopt the RectEdges<> getter for border widths in two places, to reduce the 
number
of virtual function calls in hot code.

* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::clientBoxRectInFragment const):
(WebCore::RenderBox::paddingBoxRect const):
* Source/WebCore/rendering/RenderBoxInlines.h:
(WebCore::RenderBox::paddingBoxHeight const):
(WebCore::RenderBox::paddingBoxRectIncludingScrollbar const):
(WebCore::RenderBox::contentBoxRect const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7ef93c: REGRESSION (277837@main): [UnifiedPDF] PDF content...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7ef93c1bf37e2fe9a88a50a573bcfb0ab53922c1
  
https://github.com/WebKit/WebKit/commit/7ef93c1bf37e2fe9a88a50a573bcfb0ab53922c1
  Author: Simon Fraser 
  Date:   2024-04-30 (Tue, 30 Apr 2024)

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

  Log Message:
  ---
  REGRESSION (277837@main): [UnifiedPDF] PDF content scales oddly, and 
selection detaches, when resizing in "Automatically Resize" mode
https://bugs.webkit.org/show_bug.cgi?id=273519
rdar://127314933

Reviewed by Abrar Rahman Protyasha.

After 277837@main we allow rendered tiles with invalid geometry to remain in 
the cache, which means that we can paint them,
e.g. on auto resizing, even though their geometry is wrong. So remove them from 
the cache of rendered tiles when we know
their contents are wrong.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::willRepaintTile):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9f717e: [UnifiedPDF] Resizing a slow-rendering PDF, wedges...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9f717e3bb0d15503330aad55b66c9d609594b1b9
  
https://github.com/WebKit/WebKit/commit/9f717e3bb0d15503330aad55b66c9d609594b1b9
  Author: Simon Fraser 
  Date:   2024-04-23 (Tue, 23 Apr 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Resizing a slow-rendering PDF, wedges all cores for tens of 
minutes
https://bugs.webkit.org/show_bug.cgi?id=272880
rdar://126213078

Reviewed by Tim Horton.

Currently we dispatch PDF tile renders as soon as we get notified that a tile 
needs
new content. That causes all the requests to pile up in libdispatch, and once 
they
are dispatched we have no way to cancel those that are stale.

Fix by using a work queue for tile render requests; while requests are still in 
the
queue, they can be removed. We track how many renders are in flight, and only 
dispatch
new ones when requests complete.

The number of concurrent renders is computed based on the number of cores, with 
some
sensible limits. We don't just match the number of cores because that brings 
back the
original problem of farming out lots of uncancellable renders.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::maxConcurrentTileRenders):
(WebKit::AsyncPDFRenderer::AsyncPDFRenderer):
(WebKit::AsyncPDFRenderer::willRemoveTile):
(WebKit::AsyncPDFRenderer::clearRequestsAndCachedTiles):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::serviceRequestQueue):
(WebKit::AsyncPDFRenderer::didCompleteTileRender):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1d9888: macOS 14.4 Regression: HTML elements in a WebView ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1d9888c85e204821e7f0489d01bc5b3ae0a42833
  
https://github.com/WebKit/WebKit/commit/1d9888c85e204821e7f0489d01bc5b3ae0a42833
  Author: Simon Fraser 
  Date:   2024-04-22 (Mon, 22 Apr 2024)

  Changed paths:
M Source/WebKitLegacy/mac/WebView/WebHTMLView.mm

  Log Message:
  ---
  macOS 14.4 Regression: HTML elements in a WebView (Legacy) do not repaint 
when their width/height change
https://bugs.webkit.org/show_bug.cgi?id=270898
rdar://124564409

Reviewed by Matt Woodrow.

After 271261@main we don't update compositing layers on every layout, but when 
WebKitLegacy forces
layout, we need to update them. This fixes an issue resizing solid-color-only 
layers; for other
layers, the triggered repaint avoids the bug.

I tried to fix DumpRenderTree to respect `testRunner.dontForceRepaint()` so I 
could write a test,
but even with this, the runloop observer fires in DRT and updates layers, so 
the test didn't work.

* Source/WebKitLegacy/mac/WebView/WebHTMLView.mm:
(-[WebHTMLView _web_updateLayoutAndStyleIfNeededRecursive]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8feb39: [UnifiedPDF] Do more fine-grained tile invalidation

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8feb3943337028bf46df4837262ae202e7fe30db
  
https://github.com/WebKit/WebKit/commit/8feb3943337028bf46df4837262ae202e7fe30db
  Author: Simon Fraser 
  Date:   2024-04-22 (Mon, 22 Apr 2024)

  Changed paths:
M Source/WebCore/platform/graphics/TiledBacking.h
M Source/WebCore/platform/graphics/ca/TileController.cpp
M Source/WebCore/platform/graphics/ca/TileController.h
M Source/WebCore/platform/graphics/ca/TileGrid.cpp
M Source/WebCore/platform/graphics/ca/TileGrid.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/WebPage/wc/GraphicsLayerWC.cpp

  Log Message:
  ---
  [UnifiedPDF] Do more fine-grained tile invalidation
https://bugs.webkit.org/show_bug.cgi?id=273016
rdar://126779250

Reviewed by Tim Horton.

AsyncPDFRenderer's tile invalidation was based on the 
PDFConfigurationIdentifier changing,
which happened on scaling and layout changes. However, some kinds of layout 
(e.g. window
resize without automatic resizing) don't change the per-tile PDF contents, so 
in those cases
we can preserve rendered tiles, which can avoid large amounts of re-rendering 
for PDFs
which are expensive to render.

We can compare `TileRenderInfo`s to know if a tile has changed, since 
`PDFPageCoverage`
gives us page-relative rects for this tile.

Remove PDFConfigurationIdentifiers which we no longer need. Make it possible to 
test `TileRenderInfo`
for painting equality (which ignores the optional clip rect), and implement 
`renderInfoForTile()` which
allows us to compute a `TileRenderInfo` from the current state of the PDF and 
tile grid (we need
`rectForTile()` for this, which is added to `TiledBacking`).

Now `willRepaintTile()` can ask if we have a valid cached tile using more data 
than just
the tile index. `enqueueTilePaintIfNecessary()` can also early return if we 
have an existing
queued paint which is valid, and `didCompleteTileRender()` can ask whether the 
paint we
just completed asynchronously is still valid.

We do need a new identifier, PDFContentsVersionIdentifier, which increments 
when the PDF
contents change (e.g. an annotation update); this allows us to ask whether an 
enqueued
tile paint is still valid (e.g. for partial updates on form control changes).

* Source/WebCore/platform/graphics/TiledBacking.h:
* Source/WebCore/platform/graphics/ca/TileController.cpp:
(WebCore::TileController::rectForTile const):
* Source/WebCore/platform/graphics/ca/TileController.h:
* Source/WebCore/platform/graphics/ca/TileGrid.cpp:
(WebCore::TileGrid::rectForTile const):
* Source/WebCore/platform/graphics/ca/TileGrid.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
(WebKit::AsyncPDFRenderer::TileRenderInfo::equivalentForPainting const):
(WebKit::AsyncPDFRenderer::renderInfoForTile):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::AsyncPDFRenderer):
(WebKit::AsyncPDFRenderer::renderInfoIsValidForTile const):
(WebKit::AsyncPDFRenderer::willRepaintTile):
(WebKit::AsyncPDFRenderer::tilingScaleFactorDidChange):
(WebKit::AsyncPDFRenderer::enqueueTilePaintIfNecessary):
(WebKit::AsyncPDFRenderer::renderInfoForTile const):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::didCompleteTileRender):
(WebKit::AsyncPDFRenderer::paintTilesForPage):
(WebKit::AsyncPDFRenderer::pdfContentChangedInRect):
(WebKit::AsyncPDFRenderer::layoutConfigurationChanged): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):
(WebKit::UnifiedPDFPlugin::setScaleFactor):
* Source/WebKit/WebProcess/WebPage/wc/GraphicsLayerWC.cpp:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 74f0ad: [UnifiedPDF] Unify the "partial" and "full" PDF ti...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 74f0ad1b6f48586b34a55482948f69c7596d0a34
  
https://github.com/WebKit/WebKit/commit/74f0ad1b6f48586b34a55482948f69c7596d0a34
  Author: Simon Fraser 
  Date:   2024-04-19 (Fri, 19 Apr 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Unify the "partial" and "full" PDF tile code paths
https://bugs.webkit.org/show_bug.cgi?id=272945
rdar://126723009

Reviewed by Tim Horton.

AsyncPDFRenderer had separate code paths for partial and full tile updates, 
with two places
where we called `m_paintingWorkQueue->dispatch(...)`. Remove the one in 
`AsyncPDFRenderer::pdfContentChangedInRect()`,
calling `enqueueTilePaintIfNecessary()` instead.

`AsyncPDFRenderer::enqueueTilePaintIfNecessary()` now takes an optional 
clipRect for partial updates.
We need to take care when there is already a paint for this tile in flight; 
there's no guarantee that
it will finish before our new one, so we have just override it, taking care to 
unite any partial updates.
The newly added PDFTileRenderIdentifier allows us to determine, when a tile 
render completes, if it's the
most recent one.

Now that we have this tracking, we can also remove entries from 
`m_currentValidTileRenders` as soon
as they are complete, rather than waiting until paint time, which was a poor 
version of batching.

Also ensure that `paintTileOnWorkQueue()` always notifies the main thread, even 
in the case of buffer
allocation failure, to avoid leaving entries in m_currentValidTileRenders.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
(WebKit::AsyncPDFRenderer::enqueueTilePaintIfNecessary):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::willRepaintTile):
(WebKit::AsyncPDFRenderer::willRemoveTile):
(WebKit::AsyncPDFRenderer::willRepaintAllTiles): Just call 
clearRequestsAndCachedTiles().
(WebKit::AsyncPDFRenderer::clearRequestsAndCachedTiles):
(WebKit::AsyncPDFRenderer::enqueueTilePaintIfNecessary):
(WebKit::AsyncPDFRenderer::renderInfoForTile const):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintTileOnWorkQueue):
(WebKit::AsyncPDFRenderer::transferBufferToMainThread):
(WebKit::AsyncPDFRenderer::didCompleteTileRender):
(WebKit::AsyncPDFRenderer::paintTilesForPage):
(WebKit::AsyncPDFRenderer::pdfContentChangedInRect):
(WebKit::AsyncPDFRenderer::didCompleteNewTileRender): Deleted.
(WebKit::AsyncPDFRenderer::didCompleteTileUpdateRender): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f3cac5: Optimize the computation of layout overflow

[Simon Fraser]

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

  Changed paths:
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/RenderBlock.h
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderBoxModelObject.h
M Source/WebCore/rendering/RenderBoxModelObjectInlines.h
M Source/WebCore/rendering/RenderTable.h
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderTableCell.h
M Source/WebCore/rendering/RenderTableInlines.h

  Log Message:
  ---
  Optimize the computation of layout overflow
https://bugs.webkit.org/show_bug.cgi?id=272859


Reviewed by Alan Baradlay.

Computing layout overflow would call the 4 virtual border width functions
many times, so add a single virtual border widths getter to reduce that 
overhead.

Also `flippedClientBoxRect()` has non-trivial cost and would be computed each 
time
for the container, so compute that once and pass it into 
`addOverflowFromChild()`.

Finally check the `hasNonVisibleOverflow()` bit in a couple of places before
doing tests for various kinds of overflow.

* Source/WebCore/rendering/RenderBlock.cpp:
(WebCore::RenderBlock::addOverflowFromPositionedObjects):
(WebCore::RenderBlock::borderWidths const):
* Source/WebCore/rendering/RenderBlock.h:
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::addOverflowFromChild):
(WebCore::RenderBox::addLayoutOverflow):
(WebCore::RenderBox::layoutOverflowRectForPropagation const):
(WebCore::RenderBox::flippedClientBoxRect const):
* Source/WebCore/rendering/RenderBox.h:
* Source/WebCore/rendering/RenderBoxModelObject.h:
* Source/WebCore/rendering/RenderBoxModelObjectInlines.h:
(WebCore::RenderBoxModelObject::borderWidths const):
* Source/WebCore/rendering/RenderTable.h:
* Source/WebCore/rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::borderWidths const):
* Source/WebCore/rendering/RenderTableCell.h:
* Source/WebCore/rendering/RenderTableInlines.h:
(WebCore::RenderTable::borderWidths const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d927d7: Sometimes the contents of a visibility:hidden ifra...

[Simon Fraser]

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

  Changed paths:
M LayoutTests/compositing/visibility/iframe-visibility-hidden-expected.html
M LayoutTests/compositing/visibility/iframe-visibility-hidden.html
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h

  Log Message:
  ---
  Sometimes the contents of a visibility:hidden iframe become visible
https://bugs.webkit.org/show_bug.cgi?id=272727
rdar://126178201

Reviewed by Matt Woodrow.

A normal composited but `visibility:hidden` layer uses 
`setContentsVisible(false)`
to hide its contents (by clearing the layer's `contents` property), and this 
works
within a document because `visibility` is inherited, and allows a visible child
inside a hidden ancestor.

For plugin or iframe layers we try to avoid making them composited when they
are `visibility:hidden`. However, if they are composited for other reasons (e.g.
`position:fixed`) then we hide their layer contents, but we fail to hide their
descendant layers, which GraphicsLayer parented via 
`attachWidgetContentLayers()`.

Fix this by not parenting the widget's content layers in 
`RenderLayerCompositor::attachWidgetContentLayersIfNecessary()`,
and enhancing the return value to distinguish between "widget has contents via 
child layers", and "mutated the layer hierarchy"
since the two callers were using the return value in two different ways.

Enhance an existing test to exercise this case.
* LayoutTests/compositing/visibility/iframe-visibility-hidden-expected.html:
* LayoutTests/compositing/visibility/iframe-visibility-hidden.html:
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateConfiguration):
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateBackingAndHierarchy):
(WebCore::RenderLayerCompositor::attachWidgetContentLayersIfNecessary):
(WebCore::RenderLayerCompositor::attachWidgetContentLayers): Deleted.
* Source/WebCore/rendering/RenderLayerCompositor.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] bfb404: Optimize CachedResource::didAccessDecodedData()

[Simon Fraser]

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

  Changed paths:
M Source/WebCore/loader/cache/CachedResource.cpp
M Source/WebCore/loader/cache/MemoryCache.cpp
M Source/WebCore/loader/cache/MemoryCache.h

  Log Message:
  ---
  Optimize CachedResource::didAccessDecodedData()
https://bugs.webkit.org/show_bug.cgi?id=272499
rdar://126244115

Reviewed by Ryosuke Niwa and Chris Dumez.

LRUList has a `moveToLastIfPresent()` so use that instead of removing and 
re-adding just to get
something to the end of the LRU list.

* Source/WebCore/loader/cache/CachedResource.cpp:
(WebCore::CachedResource::didAccessDecodedData):
* Source/WebCore/loader/cache/MemoryCache.cpp:
(WebCore::MemoryCache::moveToEndOfLiveDecodedResourcesListIfPresent):
(WebCore::MemoryCache::pruneSoon):
* Source/WebCore/loader/cache/MemoryCache.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6e2d49: [macOS] MiniBrowser can't zoom out sometimes in PDFs

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6e2d49d136fcaa67adac012bc9b8ad9b7b46e824
  
https://github.com/WebKit/WebKit/commit/6e2d49d136fcaa67adac012bc9b8ad9b7b46e824
  Author: Simon Fraser 
  Date:   2024-04-10 (Wed, 10 Apr 2024)

  Changed paths:
M Tools/MiniBrowser/mac/WK2BrowserWindowController.m

  Log Message:
  ---
  [macOS] MiniBrowser can't zoom out sometimes in PDFs
https://bugs.webkit.org/show_bug.cgi?id=272490
rdar://126237086

Reviewed by Tim Horton and Sammy Gill.

Fix copypasta in `zoomOut:`

* Tools/MiniBrowser/mac/WK2BrowserWindowController.m:
(-[WK2BrowserWindowController zoomOut:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 629488: Minor optimizations in positioned layout

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 629488f43b33d8bc6bf3de43012047c95ba02f64
  
https://github.com/WebKit/WebKit/commit/629488f43b33d8bc6bf3de43012047c95ba02f64
  Author: Simon Fraser 
  Date:   2024-04-10 (Wed, 10 Apr 2024)

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

  Log Message:
  ---
  Minor optimizations in positioned layout
https://bugs.webkit.org/show_bug.cgi?id=272371
rdar://126113799

Reviewed by Alan Baradlay.

Avoid calling `isOrthogonal()` multiple times.

Use local copies of localLeft/Right/Top/Bottom, clarifying which get modified 
in the course
of the function.

* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::computeBlockStaticDistance):
(WebCore::RenderBox::computePositionedLogicalWidthReplaced const):
(WebCore::RenderBox::computePositionedLogicalHeightReplaced const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9ab862: Optimize RenderBox::contentBoxRect()

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9ab862354f2a6c2eac2b73b3de555c40660d30f0
  
https://github.com/WebKit/WebKit/commit/9ab862354f2a6c2eac2b73b3de555c40660d30f0
  Author: Simon Fraser 
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
M Source/WebCore/rendering/RenderBoxInlines.h

  Log Message:
  ---
  Optimize RenderBox::contentBoxRect()
https://bugs.webkit.org/show_bug.cgi?id=272372
rdar://126114704

Reviewed by Alan Baradlay.

`contentBoxRect()` called `contentBoxLocation()` and `contentSize()` and both 
fan out into
calls involving scrollbar gutter and scrollbar width which are repetitive. So 
replace with
a single function that fetches all the input values without redundancy.

* Source/WebCore/rendering/RenderBoxInlines.h:
(WebCore::RenderBox::computedCSSContentBoxRect const):
(WebCore::RenderBox::contentBoxRect const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 56edd4: [UnifiedPDF] Maintain scroll position when zooming...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 56edd4201d2fee53ba3f72c3d4618bd587c097ae
  
https://github.com/WebKit/WebKit/commit/56edd4201d2fee53ba3f72c3d4618bd587c097ae
  Author: Simon Fraser 
  Date:   2024-04-02 (Tue, 02 Apr 2024)

  Changed paths:
M LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Maintain scroll position when zooming and resizing the window
https://bugs.webkit.org/show_bug.cgi?id=271938
rdar://119632576

Reviewed by Tim Horton.

Do a better job of preserving the page that is in the viewport ("restoring the 
scroll position")
under two circumstances:
1. We're in "Automatically Resize" mode and the user is resizing the window
2. Switching between Single Page and Two Page modes.

We do this by computing a point in the PDF page that is closest to the top of 
the viewport,
arbitrarily picking a point horizontally centered in that page.
`PDFDocumentLayout::pageIndexAndPagePointForDocumentYOffset()` has logic to 
pick the right page
if it is closer to the top (e.g. when page sizes are uneven).

After layout, we compute a new scroll position based on this page/point pair, 
and scroll to
it.

We avoid doing this when not in "Automatically Resize" mode because we don't 
want to clobber
the horizontal scroll position. We also need to ensure that we've laid out the 
PDF pages
at least once.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::pageIndexAndPagePointForDocumentYOffset const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayout):
(WebKit::UnifiedPDFPlugin::scrollAnchoringForCurrentScrollPosition const):
(WebKit::UnifiedPDFPlugin::restoreScrollPositionWithInfo):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ed9218: [UnifiedPDF] Zoom out doesn't go out far enough wi...

[Simon Fraser]

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

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

  Log Message:
  ---
  [UnifiedPDF] Zoom out doesn't go out far enough with keyboard zoom
https://bugs.webkit.org/show_bug.cgi?id=271937
rdar://125386166

Reviewed by Tim Horton.

Internally, UnifiedPDFPlugin would adjust m_scaleFactor based on window-fitting
and other behaviors for the correct layout. However, the value exposed to
clients was somewhat arbitrary; m_scaleFactor==1 meant "fit to window", not
"actual size". This meant that the behavior of "Actual Size" from the PDF 
context
menu was different to "Actual Size" in the Safari menus, which just called
`setPageScaleFactor(1)`, and Command-+ and Command-- wouldn't work as expected.

Fix by computing a normalization factor so that the exposed scale factor is `1`
for actual size.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::computeNormalizationFactor):
(WebKit::UnifiedPDFPlugin::fromNormalizedScaleFactor const):
(WebKit::UnifiedPDFPlugin::toNormalizedScaleFactor const):
(WebKit::UnifiedPDFPlugin::scaleFactor const):
(WebKit::UnifiedPDFPlugin::setScaleFactor):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::updateLayout):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 770666: [PDF] Clean up some scales and #ifdefs in PDFPlugi...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7706664bf8e1ca841670d2e6f23e8253d57f3f6e
  
https://github.com/WebKit/WebKit/commit/7706664bf8e1ca841670d2e6f23e8253d57f3f6e
  Author: Simon Fraser 
  Date:   2024-03-29 (Fri, 29 Mar 2024)

  Changed paths:
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/PDFPluginAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.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
M Source/WebKit/WebProcess/Plugins/PluginView.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp

  Log Message:
  ---
  [PDF] Clean up some scales and #ifdefs in PDFPlugin code
https://bugs.webkit.org/show_bug.cgi?id=271912
rdar://125630155

Reviewed by Tim Horton.

Various minor bits of cleanup in PDFPlugin code:
1. Make all the scales be doubles
2. Make `contentScaleFactor()` internal to PDFPluginBase and subclasses,
   requiring some annotation classes to be friends. Stop exposing it via
   PluginView.
3. Change some ENABLE(LEGACY_PDFKIT_PLUGIN) to ENABLE(PDF_PLUGIN) for classes
   that are still used with UnifiedPDF

* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::showDefinitionForAttributedString):
(WebKit::PDFPlugin::scaleFactor const):
(WebKit::PDFPlugin::contentScaleFactor const):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::didEndMagnificationGesture):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::dictionaryPopupInfoForSelection):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.mm:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::scaleForActualSize const):
(WebKit::UnifiedPDFPlugin::scaleForFitToView const):
(WebKit::UnifiedPDFPlugin::initialScale const):
(WebKit::UnifiedPDFPlugin::scaleFactor const):
(WebKit::UnifiedPDFPlugin::contentScaleFactor const):
(WebKit::UnifiedPDFPlugin::centeringOffset const):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::contentScaleFactor const): Deleted.
* Source/WebKit/WebProcess/Plugins/PluginView.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::pageZoomFactor const):
(WebKit::WebPage::setPageZoomFactor):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2c9d24: [UnifiedPDF] PDF is opening in Safari zoomed in an...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2c9d242f87f88dd7f4d777ea9f8bc0381345bf03
  
https://github.com/WebKit/WebKit/commit/2c9d242f87f88dd7f4d777ea9f8bc0381345bf03
  Author: Simon Fraser 
  Date:   2024-03-28 (Thu, 28 Mar 2024)

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

  Log Message:
  ---
  [UnifiedPDF] PDF is opening in Safari zoomed in and off-center
https://bugs.webkit.org/show_bug.cgi?id=271870
rdar://125382902

Reviewed by Abrar Rahman Protyasha and Sammy Gill.

Safari does per-site saving of page zoom, which means that when you re-open a 
PDF, it calls `UnifiedPDFPlugin::setPageScaleFactor()`
before we've received the PDFDocument. This causes 
`UnifiedPDFPlugin::setPageScaleFactor()` to set `m_shouldUpdateAutoSizeScale` 
to `ShouldUpdateAutoSizeScale::No`.

When then run `PDFDocumentLayout::updateLayout()` with a null document, and 
compute a small maxRowWidth which is just the margins,
thus computing a huge scale. And because `m_shouldUpdateAutoSizeScale` is 
forever after `ShouldUpdateAutoSizeScale::No`, we get stuck
with this huge scale.

Fix by ensuring that the first layout with a non-null PDFDocument runs with 
`ShouldUpdateAutoSizeScale::Yes`.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFDocumentLayout::havePDFDocument const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayout):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] aa53cb: [UnifiedPDF] Move the ShouldUpdateAutoSizeScale st...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: aa53cbad39408afbc5434f6d2a11f790c221a437
  
https://github.com/WebKit/WebKit/commit/aa53cbad39408afbc5434f6d2a11f790c221a437
  Author: Simon Fraser 
  Date:   2024-03-28 (Thu, 28 Mar 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Move the ShouldUpdateAutoSizeScale state out of PDFDocumentLayout
https://bugs.webkit.org/show_bug.cgi?id=271851
rdar://125580423

Reviewed by Sammy Gill.

It's surprising that the behavior of PDFDocumentLayout in terms of
setting m_scale after layout is stateful, based on `m_autoSizeState`.
Move this statefulness to UnifiedPDFPlugin where it makes more sense.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFDocumentLayout::setShouldUpdateAutoSizeScale): Deleted.
(WebKit::PDFDocumentLayout::shouldUpdateAutoSizeScale const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::updateLayout):
(WebKit::PDFDocumentLayout::layoutPages):
(WebKit::PDFDocumentLayout::layoutSingleColumn):
(WebKit::PDFDocumentLayout::layoutTwoUpColumn):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::updateLayout):
(WebKit::UnifiedPDFPlugin::contextMenuItem const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):
(WebKit::UnifiedPDFPlugin::zoomIn):
(WebKit::UnifiedPDFPlugin::zoomOut):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a69359: [ iOS Debug ] compositing/backing/page-scale-overl...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a69359535a752782eaceb592b46b2bc39baef79f
  
https://github.com/WebKit/WebKit/commit/a69359535a752782eaceb592b46b2bc39baef79f
  Author: Simon Fraser 
  Date:   2024-03-28 (Thu, 28 Mar 2024)

  Changed paths:
M LayoutTests/platform/ipad/TestExpectations
M 
LayoutTests/platform/ipad/compositing/backing/page-scale-overlap-in-iframe-expected.txt

  Log Message:
  ---
  [ iOS Debug ] compositing/backing/page-scale-overlap-in-iframe.html is a 
constant text failure
rdar://123118235
https://bugs.webkit.org/show_bug.cgi?id=269617

Unreviewed test gardening.

Update ipad results, remove from TestExpectations.

* LayoutTests/platform/ipad/TestExpectations:
* 
LayoutTests/platform/ipad/compositing/backing/page-scale-overlap-in-iframe-expected.txt:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4c27f7: [UnifiedPDF] Checked form controls flicker off whi...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4c27f79a1556e7862b88a1df0e3d809dbb83d521
  
https://github.com/WebKit/WebKit/commit/4c27f79a1556e7862b88a1df0e3d809dbb83d521
  Author: Simon Fraser 
  Date:   2024-03-28 (Thu, 28 Mar 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Checked form controls flicker off while resizing the window
https://bugs.webkit.org/show_bug.cgi?id=270040
rdar://123566546

Reviewed by Abrar Rahman Protyasha and Sammy Gill.

When PDF annotations change that affect painted annotations, we need to update
the page previews so that while tiles are missing during zooming/resize, the low
res snapshot has the correct state.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::pdfContentChangedInRect):
(WebKit::AsyncPDFRenderer::updateTilesForPaintingRect): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setNeedsRepaintInDocumentRect):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6fa1d3: REGRESSION (273999@main): Elements fail to render ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6fa1d3b94cd776cb8af563c46495c66e3c483668
  
https://github.com/WebKit/WebKit/commit/6fa1d3b94cd776cb8af563c46495c66e3c483668
  Author: Simon Fraser 
  Date:   2024-03-26 (Tue, 26 Mar 2024)

  Changed paths:
A 
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing-expected.html
A 
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing.html
M 
LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/absolute-in-nested-overflow-scroll-expected.txt
M 
LayoutTests/scrollingcoordinator/scrolling-tree/absolute-in-nested-overflow-scroll-expected.txt
M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  ---
  REGRESSION (273999@main): Elements fail to render in Spinnaker
https://bugs.webkit.org/show_bug.cgi?id=271710
rdar://124483601

Reviewed by Alan Baradlay.

273999@main reverted some backing sharing behavior to an older configuration, 
but this brought back
a bug which affects Spinnaker dashboards. The test reduction has a series of 
overflow scrollers, both
siblings and nested, and an element later in the tree that ends up obscured 
when the bug occurs.

A simplified paint-order tree dump (via the Compositing log channel) looks like 
this:

-S-C-c-- 0x118000810 RenderView 0x1180002c0
-S---c--   + 0x118001850 RenderBlock 0x118001700 HTML 0x118001050
-S-C-c-- + 0x1180044a0 RenderBlock (relative positioned) 
0x118004350 DIV 0x118003350 class='container'
-S-O-XxC   - 0x118004740 RenderTextControl 0x118005460 TEXTAREA 
0x118003c20 class='fixed'
---O---CPc--   + 0x1180049e0 RenderBlock (relative positioned) 
0x1180045f0 DIV 0x1180033d0 id='main'
--NO---C-c-- n 0x118004dd0 RenderBlock 0x118004890 DIV 0x118003530 
class='outer-scroller'
--NO---C--s-   n 0x118005070 RenderBlock 0x118004c80 DIV 
0x1180035b0 class='scroller'
p-s-   + 0x1180055b0 RenderBlock (relative positioned) 
0x1180051c0 DIV 0x118003790 class='indicator'

Note the P on '0x1180049e0' indicating that it's a shared backing provider, and 
the p on '0x1180055b0' showing that
it paints into that shared backing. However, the normal flow descendant layers 
of 0x1180049e0 (0x118004dd0 and 0x118005070)
are both [C]composited, so they appear on top of 0x1180055b0, which is the bug.

A composited layer normally interrupts a backing sharing sequence. However, we 
only determined that 0x1180049e0 could
be a backing provider after traversing its descendant layers in 
`updateBackingSharingAfterDescendantTraversal()`,
and made it one despite it having composited descendants. So fix 
`updateBackingSharingAfterDescendantTraversal()`
to check that.

This undoes the backing sharing that happened in 
`scrollingcoordinator/scrolling-tree/absolute-in-nested-overflow-scroll`,
but that sharing was undone on scrolling anyway.

* 
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing-expected.html:
 Added.
* 
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing.html:
 Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateBackingSharingAfterDescendantTraversal):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b289d5: REGRESSION (UI-side compositing?): Sporadic failur...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b289d5f2461d7da84861df406cee682afa4c39df
  
https://github.com/WebKit/WebKit/commit/b289d5f2461d7da84861df406cee682afa4c39df
  Author: Simon Fraser 
  Date:   2024-03-21 (Thu, 21 Mar 2024)

  Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h

  Log Message:
  ---
  REGRESSION (UI-side compositing?): Sporadic failures in layout tests due to 
wrong test images
https://bugs.webkit.org/show_bug.cgi?id=271348
rdar://120050275

Reviewed by Tim Horton.

When we take snapshots of layout tests, we wait for a 
`callAfterNextPresentationUpdate()`, which
waits for a transaction to come from the web process. However, it doesn't wait 
for the subsequent
Core Animation commit, which actually pushes changes to WindowServer. Yet the 
snapshot we do is
a WindowServer snapshot (`PlatformWebView::windowSnapshotImage()`), so we can 
sometimes capture state that is stale.

We don't actually know when our new content gets to WindowServer and will show 
up in a snapshot,
but we can reduce the raciness by at least waiting for the Core Animation 
commit to complete.
So add `callAfterNextPresentationUpdateAndLayerCommit()` and use it 
`WebPageProxy::forceRepaint()`.
Also update `-[WKWebView takeSnapshotWithConfiguration:]` to use it.

* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView takeSnapshotWithConfiguration:completionHandler:]):
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::callAfterNextPresentationUpdateAndLayerCommit):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::forceRepaint):
(WebKit::WebPageProxy::callAfterNextPresentationUpdateAndLayerCommit):
* Source/WebKit/UIProcess/WebPageProxy.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] af754b: [VisionOS] Build failure after 276430@main

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: af754bb7da6aeee2593212de3a6ab9ded084771c
  
https://github.com/WebKit/WebKit/commit/af754bb7da6aeee2593212de3a6ab9ded084771c
  Author: Simon Fraser 
  Date:   2024-03-21 (Thu, 21 Mar 2024)

  Changed paths:
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCAFiltersCocoa.mm

  Log Message:
  ---
  [VisionOS] Build failure after 276430@main
https://bugs.webkit.org/show_bug.cgi?id=271385
rdar://125170546

Unreviewed build fix for VisionOS.

* Source/WebCore/platform/graphics/ca/cocoa/PlatformCAFiltersCocoa.mm:
(WebCore::PlatformCAFilters::setFiltersOnLayer):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c71e10: [UnifiedPDF] PDF flickers/flashes while zooming

[Simon Fraser]

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

  Changed paths:
M Source/WebCore/platform/graphics/GraphicsLayerClient.h
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm

  Log Message:
  ---
  [UnifiedPDF] PDF flickers/flashes while zooming
https://bugs.webkit.org/show_bug.cgi?id=271292
rdar://122884598

Reviewed by Tim Horton.

Change the way we paint the low-resolution page backgrounds so that they 
reliably appear behind
the PDF tiles when zooming.

Previously, the page previews were only painted in 
`AsyncPDFRenderer::paintTilesForPage()` if
we'd painted no cached tiles. However, there was no guarantee that the entire 
rect was covered
in cached tile paints, and "leakage" of repaint rects between tiles (because of 
GraphicsLayerCA-level
integral rounding) often resulting in painting some strips of tiles around the 
edges, but not
filling the entire area; this area would remain white (from the white fill 
painted earlier), hence
flashing.

Conceptually the page preview needs to appear behind cached tiles, and it's 
hard to answer the
question "have I filled the given rect with tiles" given floating point drawing 
coordinates.
We also want to avoid always painting the page previews behind the tiles, for 
performance.

So instead, display the page previews in the "page background" layers which we 
already have
and currently just provide a white fill. We need draw the page previews only 
once; we can just
scale the page background layers as necessary. To avoid repaints on page scale 
changes, we need
to implement a new GraphicsLayerClient callback that allows us to keep the 
layer contentsScale
fixed.

The page background layers, and their associated cache buffers are always sized 
using `layoutBoundsForPageAtIndex()`,
and the buffer scale, and the layer contents scale are determined via 
`scaleForPagePreviews()`.

The white fill behind the full-resolution PDF content is now painted into the 
cached buffers.

* Source/WebCore/platform/graphics/GraphicsLayerClient.h:
(WebCore::GraphicsLayerClient::customContentsScale const):
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::updateContentsScale):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::paintPagePreviewOnWorkQueue):
(WebKit::AsyncPDFRenderer::coverageRectDidChange):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::paintTilesForPage):
(WebKit::AsyncPDFRenderer::paintPagePreview):
(WebKit::AsyncPDFRenderer::updateTilesForPaintingRect):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updatePageBackgroundLayers):
(WebKit::UnifiedPDFPlugin::paintBackgroundLayerForPage):
(WebKit::UnifiedPDFPlugin::scaleForPagePreviews const):
(WebKit::UnifiedPDFPlugin::didGeneratePreviewForPage):
(WebKit::UnifiedPDFPlugin::backgroundLayerForPage const):
(WebKit::UnifiedPDFPlugin::pageIndexForPageBackgroundLayer const):
(WebKit::UnifiedPDFPlugin::customContentsScale const):
(WebKit::UnifiedPDFPlugin::tiledBackingUsageChanged):
(WebKit::UnifiedPDFPlugin::didChangeIsInWindow):
(WebKit::UnifiedPDFPlugin::paint):
(WebKit::UnifiedPDFPlugin::paintContents):
(WebKit::UnifiedPDFPlugin::paintPDFContent):
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm:
(WebKit::PlatformCALayerRemote::create):

,

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5dce17: [UnifiedPDF] Can't click-drag the scrollbar

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5dce1764e0a3228c2260c1797276d4ac1fba2158
  
https://github.com/WebKit/WebKit/commit/5dce1764e0a3228c2260c1797276d4ac1fba2158
  Author: Simon Fraser 
  Date:   2024-03-16 (Sat, 16 Mar 2024)

  Changed paths:
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/plugins/PluginViewBase.h
M Source/WebCore/rendering/RenderEmbeddedObject.cpp
M Source/WebCore/rendering/RenderEmbeddedObject.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/Plugins/PluginView.h

  Log Message:
  ---
  [UnifiedPDF] Can't click-drag the scrollbar
https://bugs.webkit.org/show_bug.cgi?id=271115
rdar://124785551

Reviewed by Abrar Rahman Protyasha.

For mouse interaction with the PDFPlugin's scrollbars to work, 
`EventHandler::enclosingScrollableArea()`
has to be able to find the plugin node's ScrollableArea. Add an easy way to get 
to the ScrollableArea
from RenderEmbeddedObject, which calls through the PluginView. Replace the odd 
code in `startKeyboardScrollAnimationOnPlugin()`
with this cleaner code.

Oddly that broke keyboard scrolling, which is fixed by implementing 
`scrollAnimatorEnabled()` in
PDFPluginBase to return true.

Also implement `PDFPluginBase::enclosingScrollableArea()`; this isn't called on 
macOS at this point, but
is implemented for completeness.

* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::enclosingScrollableArea):
(WebCore::EventHandler::startKeyboardScrollAnimationOnPlugin):
* Source/WebCore/plugins/PluginViewBase.h:
(WebCore::PluginViewBase::scrollableArea const):
* Source/WebCore/rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::scrollableArea const):
(WebCore::RenderEmbeddedObject::usesAsyncScrolling const):
(WebCore::RenderEmbeddedObject::scrollingNodeID const):
(WebCore::RenderEmbeddedObject::willAttachScrollingNode):
(WebCore::RenderEmbeddedObject::didAttachScrollingNode):
* Source/WebCore/rendering/RenderEmbeddedObject.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::enclosingScrollableArea const):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::scrollableArea const):
* Source/WebKit/WebProcess/Plugins/PluginView.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3a2359: [UnifiedPDF] Satisfy data requests synchronously w...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3a2359b8709e76a04cbcf07f04052652713e7bde
  
https://github.com/WebKit/WebKit/commit/3a2359b8709e76a04cbcf07f04052652713e7bde
  Author: Simon Fraser 
  Date:   2024-03-15 (Fri, 15 Mar 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Satisfy data requests synchronously when possible
https://bugs.webkit.org/show_bug.cgi?id=271072
rdar://123061082

Reviewed by Tim Horton.

Previously, fulfilling a PDFKit data request in 
`PDFIncrementalLoader::dataProviderGetBytesAtPosition()`
and `PDFIncrementalLoader::dataProviderGetByteRanges()` always bounced to the 
main thread, using a semaphore
to block the calling thread.

But now that access to `m_data` and associated metadata is thread-safe, we can 
just lock and fulfill
requests directly, when the data has already been loaded, which is most of the 
time. This vastly
reduces the frequency of deadlocks.

* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
(WebKit::PDFIncrementalLoader::dataProviderGetByteRanges):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::getByteRanges const):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2cf765: [UnifiedPDF] Zoom origin is unstable when zooming

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2cf765d13bb88672dd9f14d8077a656a33f19a99
  
https://github.com/WebKit/WebKit/commit/2cf765d13bb88672dd9f14d8077a656a33f19a99
  Author: Simon Fraser 
  Date:   2024-03-15 (Fri, 15 Mar 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Zoom origin is unstable when zooming
https://bugs.webkit.org/show_bug.cgi?id=271077
rdar://124709631

Reviewed by Tim Horton.

There were two issues that caused zooming to feel wonky, especially when 
zooming fast.

First, the origin was off by top content inset, because the origin passed in to
`UnifiedPDFPlugin::setScaleFactor()` is not in root view coordinates;
`ViewGestureController::handleMagnificationGestureEvent()` subtracts out top 
content inset,
so put it back.

Second, because scrolling is asynchronous, computing scroll deltas for each 
zoom increment
doesn't work because the old scroll offset can reflect state from further in 
the past.
Fix this by computing each new scroll position directly from the zoom origin in 
content
coordinates, and in plugin coordinates. Cache these origins for the duration of 
a gesture.

* Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm:
(WebKit::ViewGestureController::handleMagnificationGestureEvent):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::didEndMagnificationGesture):
(WebKit::UnifiedPDFPlugin::setScaleFactor):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 51537e: [UnifiedPDF] Prepare for thread-safe access to loa...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 51537ed487c6c33534b9aa748d8419ddbe07e355
  
https://github.com/WebKit/WebKit/commit/51537ed487c6c33534b9aa748d8419ddbe07e355
  Author: Simon Fraser 
  Date:   2024-03-15 (Fri, 15 Mar 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
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm

  Log Message:
  ---
  [UnifiedPDF] Prepare for thread-safe access to loaded PDF data
https://bugs.webkit.org/show_bug.cgi?id=271019
rdar://124644460

Reviewed by Tim Horton.

In a future patch I will be attempting to read loaded PDF data off the main 
thread, rather than
using the semaphore-driven hops to the main thread.

In preparation for this, make accessing the various data members related to 
loaded PDF data
thread-safe. In particular, add a Lock to protect `m_data` and 
`m_streamedBytes`, and move
the `RangeSet>` (which represents ranges of loaded data beyond 
m_streamedBytes) into
PDFPluginBase to be protected by the same lock.

Now we need the "check data availability and return data pointer" blocks to be 
thread-safe,
so remove `haveDataForRange()`, and make callers just try to call 
`dataPtrForRange()` which
internally takes the lock for both the checks and the data access.

There are code paths that want to avoid checking m_validRanges (the "complete 
unconditionally" code path);
for them, add a CheckValidRanges enum to `dataPtrForRange()`.

* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::ByteRangeRequest::completeUnconditionally):
(WebKit::PDFIncrementalLoader::dataPtrForRange const):
(WebKit::PDFIncrementalLoader::incrementalPDFStreamDidReceiveData):
(WebKit::PDFIncrementalLoader::requestCompleteIfPossible):
(WebKit::PDFIncrementalLoader::requestDidCompleteWithAccumulatedData):
(WebKit::PDFIncrementalLoader::ensureDataBufferLength): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::WTF_GUARDED_BY_LOCK):
(WebKit::PDFPluginBase::streamedBytes const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::teardown):
(WebKit::PDFPluginBase::originalData const):
(WebKit::PDFPluginBase::streamedBytes const):
(WebKit::PDFPluginBase::haveStreamedDataForRange const):
(WebKit::PDFPluginBase::copyDataAtPosition const):
(WebKit::PDFPluginBase::dataPtrForRange const):
(WebKit::PDFPluginBase::insertRangeRequestData):
(WebKit::PDFPluginBase::streamDidReceiveData):
(WebKit::PDFPluginBase::streamDidFail):
(WebKit::PDFPluginBase::addArchiveResource):
(WebKit::PDFPluginBase::incrementalLoaderLog):
(WebKit::PDFPluginBase::haveDataForRange const): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d13ee4: [UnifiedPDF] After zooming, subframe/embed PDFs ar...

[Simon Fraser]

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

  Changed paths:
M Source/WebCore/platform/graphics/TiledBacking.h
M Source/WebCore/platform/graphics/ca/TileController.cpp
M Source/WebCore/platform/graphics/ca/TileController.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/WebPage/wc/GraphicsLayerWC.cpp

  Log Message:
  ---
  [UnifiedPDF] After zooming, subframe/embed PDFs are messed up
https://bugs.webkit.org/show_bug.cgi?id=270211
rdar://123731682

Reviewed by Tim Horton.

The tile caching logic assumed that page scale factor (i.e. what scaleFactor() 
returns)
is the exact inverse of the scale factor that TiledBacking uses to map between 
tile coordinates
and painting coordinates.

This is true for main-frame PDFs, where the plugin takes over page scale, but 
for subframes,
page scale exists on some ancestor GraphicsLayer, yet the plugin's TiledBacking 
is aware
of this scale, because it's tracked through the GraphicsLayers. TileController 
accumulates the
scale on all ancestors in order to keep tiles at 512x512 in screen space.

So replace the uses of pageScaleFactor with `tilingScaleFactor` that we get 
from the TiledBacking.
This fixes computations that map from tile coordinates to painting coordinates, 
including fixing
blurry tiles, and missing tiles.

Also add a TiledBackingClient function that allows us to bump our configuration 
identifier when
the tiling scale factor changes, so we don't use stale tiles when the main 
frame is zoomed.

* Source/WebCore/platform/graphics/TiledBacking.h:
* Source/WebCore/platform/graphics/ca/TileController.cpp:
(WebCore::TileController::setContentsScale):
(WebCore::TileController::tilingScaleFactor const):
* Source/WebCore/platform/graphics/ca/TileController.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::tilingScaleFactorDidChange):
(WebKit::AsyncPDFRenderer::tileToPaintingTransform):
(WebKit::AsyncPDFRenderer::paintingToTileTransform):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::transferBufferToMainThread):
(WebKit::AsyncPDFRenderer::paintTilesForPage):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.mm:
(WebKit::operator<<):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::pageCoverageForRect const):
(WebKit::UnifiedPDFPlugin::paintPDFContent):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 463c4d: [Unified PDF] Document turns blank white, flashes ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 463c4d367dff65f9fdfda6ad0726d27c3a900f25
  
https://github.com/WebKit/WebKit/commit/463c4d367dff65f9fdfda6ad0726d27c3a900f25
  Author: Simon Fraser 
  Date:   2024-02-24 (Sat, 24 Feb 2024)

  Changed paths:
M Source/WebCore/platform/graphics/TiledBacking.h
M Source/WebCore/platform/graphics/ca/TileController.cpp
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [Unified PDF] Document turns blank white, flashes / flickers, while 
scrolling/zooming
https://bugs.webkit.org/show_bug.cgi?id=270042
rdar://123458964

Reviewed by Tim Horton.

With async tile rendering, we don't always have tiles to paint for a given 
rect, resulting
in flashing, e.g. when resizing the window or zooming.

Ameliorate this by generating a preview for each page, and painting this when 
we don't have
tiles. Currently we generate previews at 0.5x scale for a 1x page scale.

AsyncPDFRenderer takes care of generating page previews, using a new callback 
from the
TiledBacking client when page coverage changes. The page previews are generated 
on the
concurrent work queue. Unlike tiles, these page previews are not invalidate on 
configuration
changes (there's a FIXME to update them when PDF content changes).

* Source/WebCore/platform/graphics/TiledBacking.h:
* Source/WebCore/platform/graphics/ca/TileController.cpp:
(WebCore::TileController::setCoverageRect):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::generatePreviewImageForPage):
(WebKit::AsyncPDFRenderer::removePreviewForPage):
(WebKit::AsyncPDFRenderer::paintPagePreviewOnWorkQueue):
(WebKit::AsyncPDFRenderer::previewImageForPage const):
(WebKit::AsyncPDFRenderer::coverageRectDidChange):
(WebKit::AsyncPDFRenderer::paintPDFPageIntoBuffer):
(WebKit::AsyncPDFRenderer::paintTilesForPage):
(WebKit::AsyncPDFRenderer::updateTilesForPaintingRect):
(WebKit::AsyncPDFRenderer::paintTilesForPaintingRect): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintPDFContent): drawingRect was unused. Move 
documentScale out of the loop. Rename pageBoundsInDocumentCoordinates.
(WebKit::UnifiedPDFPlugin::heightForPageAtIndex const): Rename.
(WebKit::UnifiedPDFPlugin::firstPageHeight const):
(WebKit::UnifiedPDFPlugin::layoutBoundsForPageAtIndex const):
(WebKit::UnifiedPDFPlugin::scrollToPDFDestination):
(WebKit::UnifiedPDFPlugin::heightForPage const): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c6069f: [UnifiedPDF] Flashing when interacting with form c...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c6069f49ce6b011ecf978e53ce4875f39cea3727
  
https://github.com/WebKit/WebKit/commit/c6069f49ce6b011ecf978e53ce4875f39cea3727
  Author: Simon Fraser 
  Date:   2024-02-23 (Fri, 23 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Flashing when interacting with form controls
https://bugs.webkit.org/show_bug.cgi?id=269958
rdar://123479307

Reviewed by Tim Horton.

Currently when PDF content is invalidated (e.g. by a form control action) we 
throw
away the rendered tiles for that rect, and asynchronously regenerate them. That 
results
in flashes.

Instead, we can keep the existing tile, and update it from a 
asynchronously-rendered
buffer containing the invalidated rect for that tile. This means that paints 
may use
a stale tile, but that's better than flashing.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::paintingToTileTransform):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintTileOnWorkQueue):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::transferBufferToMainThread):
(WebKit::AsyncPDFRenderer::didCompleteNewTileRender):
(WebKit::AsyncPDFRenderer::didCompleteTileUpdateRender):
(WebKit::AsyncPDFRenderer::updateTilesForPaintingRect):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setNeedsRepaintInDocumentRect):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] fb33b4: [UnifedPDF] List boxes don't update after choosing...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: fb33b40b703b9b95ed491793dca03fad91d4b975
  
https://github.com/WebKit/WebKit/commit/fb33b40b703b9b95ed491793dca03fad91d4b975
  Author: Simon Fraser 
  Date:   2024-02-22 (Thu, 22 Feb 2024)

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

  Log Message:
  ---
  [UnifedPDF] List boxes don't update after choosing an option
https://bugs.webkit.org/show_bug.cgi?id=269944
rdar://123461005

Reviewed by Sammy Gill.

We need to trigger repaints of the PDF content for "choice widget" type 
annotations.

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

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 241d9a: [UnifiedPDF] Track PageCoverage for each rendered ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 241d9ab4f0c9a478c19560d63cd2743691228320
  
https://github.com/WebKit/WebKit/commit/241d9ab4f0c9a478c19560d63cd2743691228320
  Author: Simon Fraser 
  Date:   2024-02-21 (Wed, 21 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Track PageCoverage for each rendered tile
https://bugs.webkit.org/show_bug.cgi?id=269887
rdar://123416384

Reviewed by Tim Horton.

In order to store PDFPageCoverage per rendered tile, reshuffle the data 
structures
in AsyncPDFRenderer a little.

We can fold the `tileRect` into `TileRenderInfo`, which means it gets passed to 
the
decoding callback and back to the main thread in that struct so we no longer 
need
to track it separately.

Then we can store a `TileRenderInfo` in what used to be called `BufferAndClip`,
and is here renamed to `RenderedTile`. That then now tracks the tileRect,
the configurationIdentifier and the PDFPageCoverage.

No behavior change.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintTileOnWorkQueue):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::transferBufferToMainThread):
(WebKit::AsyncPDFRenderer::paintTilesForPaintingRect):
(WebKit::AsyncPDFRenderer::invalidateTilesForPaintingRect):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a55bd5: [UnifiedPDF] Crash when scrolling after a swipe ba...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a55bd5c3df1c8395a4ca3a81c88b176ec8b3b664
  
https://github.com/WebKit/WebKit/commit/a55bd5c3df1c8395a4ca3a81c88b176ec8b3b664
  Author: Simon Fraser 
  Date:   2024-02-21 (Wed, 21 Feb 2024)

  Changed paths:
M Source/WebCore/plugins/PluginViewBase.h
M Source/WebCore/rendering/RenderEmbeddedObject.cpp
M Source/WebCore/rendering/RenderEmbeddedObject.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
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
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/Plugins/PluginView.h

  Log Message:
  ---
  [UnifiedPDF] Crash when scrolling after a swipe back from an external link 
follow
https://bugs.webkit.org/show_bug.cgi?id=269244
rdar://122835175

Reviewed by Tim Horton.

Having calls to `UnifiedPDFPlugin::scrollingNodeID()` lazily create the 
scrolling tree node is problematic,
since this can happen early (under 
`UnifiedPDFPlugin::updateOverflowControlsLayers()`), which causes
the ScrollingCoordinator to create an unparented node, which is later replaced 
by a different node
with the same ID, causing us to lose the layer registrations.

Fix by adding an explicit `willAttachScrollingNode()` which is called by 
`RenderLayerCompositor::attachWidgetContentLayers()`,
and have it create the node, and done the necessary layer and geometry updates 
on the node.

* Source/WebCore/plugins/PluginViewBase.h:
(WebCore::PluginViewBase::willAttachScrollingNode):
* Source/WebCore/rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::willAttachScrollingNode):
* Source/WebCore/rendering/RenderEmbeddedObject.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::attachWidgetContentLayers):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::willAttachScrollingNode):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::willAttachScrollingNode):
(WebKit::UnifiedPDFPlugin::scrollingNodeID const):
(WebKit::UnifiedPDFPlugin::createScrollingNodeIfNecessary):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::willAttachScrollingNode):
* Source/WebKit/WebProcess/Plugins/PluginView.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 625cdc: [UnifiedPDF] Clean up the coordinate system code

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 625cdc03e3b236e872f37780ff2fde4272524459
  
https://github.com/WebKit/WebKit/commit/625cdc03e3b236e872f37780ff2fde4272524459
  Author: Simon Fraser 
  Date:   2024-02-18 (Sun, 18 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Clean up the coordinate system code
https://bugs.webkit.org/show_bug.cgi?id=269657
rdar://123173348

Reviewed by Tim Horton.

Replace the panoply of coordinate conversion functions with two template 
functions, capable
of converting FloatPoints and FloatRects. These are `convertUp()` and 
`convertDown()`, where
the former converts to enclosing coordinate systems, and the latter to inner 
coordinate
systems. An enum describes the available coordinate systems.

It was a purposeful choice to have convertUp() and convertDown() only do 
conversions within
the Plugin; outside the Plugin boundary (e.g. to/from RootView), functions on 
PDFPluginBase
can be used, albeit with the minor annoyance that conversions between integer 
and float
types are necessary.

Generally, staying in FloatPoint/FloatRect are preferred to converting using 
integer types

Minor other cleanups.

The only thing I can find that doesn't seem to use the correct conversions is 
painting the
yellow Find highlight, which continues to give incorrect results.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::nearestPageIndexForDocumentPoint const):
(WebKit::PDFDocumentLayout::layoutBoundsForPageAtIndex const):
(WebKit::PDFDocumentLayout::scaledContentsSize const):
(WebKit::PDFDocumentLayout::documentToPDFPage const):
(WebKit::PDFDocumentLayout::pdfPageToDocument const):
(WebKit::PDFDocumentLayout::documentPointToPDFPagePoint const): Deleted.
(WebKit::PDFDocumentLayout::pdfPagePointToDocumentPoint const): Deleted.
(WebKit::PDFDocumentLayout::pdfPageRectToDocumentRect const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setNeedsRepaintInDocumentRect):
(WebKit::UnifiedPDFPlugin::paintHoveredAnnotationOnPage):
(WebKit::UnifiedPDFPlugin::updateScrollingExtents):
(WebKit::UnifiedPDFPlugin::pageIndexForDocumentPoint const):
(WebKit::UnifiedPDFPlugin::indexForCurrentPageInView const):
(WebKit::UnifiedPDFPlugin::annotationForRootViewPoint const):
(WebKit::UnifiedPDFPlugin::convertUp const):
(WebKit::UnifiedPDFPlugin::convertDown const):
(WebKit::UnifiedPDFPlugin::pdfElementTypesForPluginPoint const):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::documentRectForAnnotation const):
(WebKit::UnifiedPDFPlugin::scrollToPDFDestination):
(WebKit::UnifiedPDFPlugin::scrollToPointInPage):
(WebKit::UnifiedPDFPlugin::scrollToPage):
(WebKit::UnifiedPDFPlugin::beginTrackingSelection):
(WebKit::UnifiedPDFPlugin::updateCurrentSelectionForContextMenuEventIfNeeded):
(WebKit::computeMarqueeSelectionRect):
(WebKit::UnifiedPDFPlugin::continueTrackingSelection):
(WebKit::UnifiedPDFPlugin::existingSelectionContainsPoint const):
(WebKit::UnifiedPDFPlugin::rectForSelectionInRootView const):
(WebKit::UnifiedPDFPlugin::countFindMatches):
(WebKit::UnifiedPDFPlugin::findString):
(WebKit::UnifiedPDFPlugin::collectFindMatchRects):
(WebKit::UnifiedPDFPlugin::rectsForTextMatchesInRect const):
(WebKit::UnifiedPDFPlugin::textIndicatorForSelection):
(WebKit::UnifiedPDFPlugin::performDictionaryLookupAtLocation):
(WebKit::UnifiedPDFPlugin::selectionBoundsForFirstPageInDocumentSpace const):
(WebKit::UnifiedPDFPlugin::showDefinitionForAttributedString):
(WebKit::UnifiedPDFPlugin::lookupTextAtLocation):
(WebKit::UnifiedPDFPlugin::pluginBoundsForAnnotation const):
(WebKit::UnifiedPDFPlugin::convertFromRootViewToDocument const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromPluginToDocument const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromDocumentToPlugin const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromPageToRootView const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromDocumentToPage const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromPageToDocument const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromPageToContents const): Deleted.
(WebKit::UnifiedPDFPlugin::convertFromDocumentToContents const): Deleted.
(WebKit::UnifiedPDFPlugin::offsetContentsSpacePointByPageMargins const): 
Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

[webkit-changes] [WebKit/WebKit] 40fc43: [UnifiedPDF] Determine what kind of repaint a give...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 40fc435f75be31167bf1228055f8f22aa03d3bf6
  
https://github.com/WebKit/WebKit/commit/40fc435f75be31167bf1228055f8f22aa03d3bf6
  Author: Simon Fraser 
  Date:   2024-02-16 (Fri, 16 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Determine what kind of repaint a given annotation change requires
https://bugs.webkit.org/show_bug.cgi?id=269623
rdar://123120061

Reviewed by Sammy Gill.

Some annotation changes, like the blue textfield hover, only require us to 
repaint
the hover overlay. Others, like checkboxes and radio buttons, require a 
regeneration
of the cached tiles.

To distinguish between these, change `ShouldRepaint` into `RepaintRequirement`
which is used in an OptionSet<>. Pass this to `setNeedsRepaintInDocumentRect()`
and have it invalidate the tiles only when necessary.

Implement `repaintRequirementsForAnnotation()` so we know what kinds of repaint
a given annotation requires.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setNeedsRepaintInDocumentRect):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::repaintRequirementsForAnnotation):
(WebKit::UnifiedPDFPlugin::startTrackingAnnotation):
(WebKit::UnifiedPDFPlugin::finishTrackingAnnotation):
(WebKit::UnifiedPDFPlugin::setActiveAnnotation):
(WebKit::AnnotationTrackingState::startAnnotationTracking):
(WebKit::AnnotationTrackingState::finishAnnotationTracking):
(WebKit::UnifiedPDFPlugin::setPDFChangedInDocumentRect): Deleted.
(WebKit::AnnotationTrackingState::handleMouseDraggedOffTrackedAnnotation): 
Deleted. It was just a one-liner.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 28ce0b: [UnifiedPDF] Do more targeted repaints when annota...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 28ce0bd231af1910f25843f7a6cbed856c1aaf78
  
https://github.com/WebKit/WebKit/commit/28ce0bd231af1910f25843f7a6cbed856c1aaf78
  Author: Simon Fraser 
  Date:   2024-02-16 (Fri, 16 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Do more targeted repaints when annotations change
https://bugs.webkit.org/show_bug.cgi?id=269546
rdar://123066080

Reviewed by Sammy Gill.

Replace the call to updateLayerHierarchy() for annotation changes to more 
focused repaints.

First, we have 
`m_annotationTrackingState.startAnnotationTracking`/`finishAnnotationTracking`
go through UnifiedPDFPlugin wrappers, which can do the repaint. Then we change 
those
functions to return a value to indicate if a repaint is needed. This repaint 
needs to also
throw away cached tiles in some cases, so do it via 
`setPDFChangedInDocumentRect()`.

Add `documentRectForAnnotation()`. This rect is then used to do the repaints.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::invalidateTilesForPaintingRect):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setPDFChangedInDocumentRect):
(WebKit::UnifiedPDFPlugin::paintHoveredAnnotationOnPage):
(WebKit::UnifiedPDFPlugin::pageIndexWithHoveredAnnotation const):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::documentRectForAnnotation const):
(WebKit::UnifiedPDFPlugin::startTrackingAnnotation):
(WebKit::UnifiedPDFPlugin::finishTrackingAnnotation):
(WebKit::AnnotationTrackingState::startAnnotationTracking):
(WebKit::AnnotationTrackingState::finishAnnotationTracking):
(WebKit::AnnotationTrackingState::handleMouseDraggedOffTrackedAnnotation):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 062609: [UnifiedPDF] After resizing the window, PDF conten...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0626093f8437aac279859fab6584d2670c5e76c4
  
https://github.com/WebKit/WebKit/commit/0626093f8437aac279859fab6584d2670c5e76c4
  Author: Simon Fraser 
  Date:   2024-02-16 (Fri, 16 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] After resizing the window, PDF content is not centered and hit 
testing is offset
https://bugs.webkit.org/show_bug.cgi?id=269549
rdar://123066513

Reviewed by Tim Horton.

The PDF content is centered in the window via a transform on the 
m_contentsLayer layer.
We need to update this transform both when the scale factor changes, but also 
when
layout is updated.

This is a small change to fix the issue. A larger refactoring of the "update" 
functions
is needed.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayerPositions):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::updateLayout):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f7b645: [UnifiedPDF] Set the scrollability on the main con...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f7b645811ea58be3d4cb17644f2f6cca5e1534ae
  
https://github.com/WebKit/WebKit/commit/f7b645811ea58be3d4cb17644f2f6cca5e1534ae
  Author: Simon Fraser 
  Date:   2024-02-16 (Fri, 16 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Set the scrollability on the main content layer
https://bugs.webkit.org/show_bug.cgi?id=269541
rdar://123063794

Reviewed by Tim Horton.

There are two things we can do to optimize tile size, and tile coverage on the
UnifiedPDFPlugin's main content layer.

First, by calling `setScrollability()`, the TileController can decide between 
512x512 tiles,
and tiles that stretch the width of the layer.

Second, by using a GraphicsLayer type of `PageTiledBacking` when the plugin is 
the main
frame plugin, GraphicsLayerCA makes tile coverage decisions that are more 
appropriate for
the main frame scroller.

* Source/WebCore/platform/ScrollableArea.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::ensureLayers):
(WebKit::UnifiedPDFPlugin::isFullMainFramePlugin const):
(WebKit::UnifiedPDFPlugin::computeScrollability const):
(WebKit::UnifiedPDFPlugin::updateScrollingExtents):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 72c98d: [UnifiedPDF] Paint PDF content off the main thread

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 72c98dc7d00b14e390e83ba0b7723d69c6357bf8
  
https://github.com/WebKit/WebKit/commit/72c98dc7d00b14e390e83ba0b7723d69c6357bf8
  Author: Simon Fraser 
  Date:   2024-02-15 (Thu, 15 Feb 2024)

  Changed paths:
M Source/WebCore/platform/graphics/ImageBuffer.h
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
A Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h
A Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Paint PDF content off the main thread
https://bugs.webkit.org/show_bug.cgi?id=269505
rdar://119632313

Reviewed by Tim Horton.

Enable AsyncPDFRenderer which paints PDF tiles off the main thread. The one 
line at
`asyncRenderer()->setupWithLayer(*m_contentsLayer)` creates the 
AsyncPDFRenderer, and the
rest of the code is conditional on it being non-null.

There are various sources of complexity in managing the cache of tiles, and 
painting them
correctly. First, the TiledBackingClient callbacks are all in terms of tile 
coordinates,
which are independent of the page scale factor that we push onto 
m_contentsLayer (since
TiledBacking has a behavior of mapping back to screen space to create the 
tiles, so they are
always 512x512 in screen space). This complexity is handled by
`convertTileRectToPaintingCoords()` and `tileToPaintingTransform()`. When 
comparing clips
etc we have to take care to map into the right coordinate systems.

Second, we have to not paint tiles that were generated earlier when the scale 
was different,
so AsyncPDFRenderer uses a `ObjectIdentifier` to track 
configurations, and
throws away tiles if the configuration changed while they were painting; this 
is necessary
to avoid lots of issues when resizing.

Painting the cached tiles themselves is done inside the per-page painting loop; 
this is
necessary to clip out pages for which `shouldDisplayPage()` is false, in 
non-continuous
scrolling modes. This is not ideal, because we have (per-tile * per-page * 
per-cached tile)
runtime performance, which will need optimizing.

* Source/WebCore/platform/graphics/ImageBuffer.h:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h:
(WebKit::AsyncPDFRenderer::paintingWorkQueue const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::AsyncPDFRenderer):
(WebKit::AsyncPDFRenderer::~AsyncPDFRenderer):
(WebKit::AsyncPDFRenderer::teardown):
(WebKit::AsyncPDFRenderer::setShowDebugBorders):
(WebKit::AsyncPDFRenderer::willRepaintTile):
(WebKit::AsyncPDFRenderer::willRemoveTile):
(WebKit::AsyncPDFRenderer::willRepaintAllTiles):
(WebKit::AsyncPDFRenderer::layoutConfigurationChanged):
(WebKit::AsyncPDFRenderer::clearRequestsAndCachedTiles):
(WebKit::AsyncPDFRenderer::tileToPaintingTransform):
(WebKit::AsyncPDFRenderer::convertTileRectToPaintingCoords):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintTileOnWorkQueue):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::transferBufferToMainThread):
(WebKit::AsyncPDFRenderer::paintTilesForPaintingRect):
(WebKit::operator<<):
(WebKit::AsyncPDFRenderer::clearCachedTiles): Deleted.
(WebKit::AsyncPDFRenderer::paintTileForClip): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.h: Added.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPageCoverage.mm: Added.
(WebKit::operator<<):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::teardown):
(WebKit::UnifiedPDFPlugin::asyncRenderer):
(WebKit::UnifiedPDFPlugin::asyncRendererIfExists const):
(WebKit::UnifiedPDFPlugin::ensureLayers):
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):
(WebKit::UnifiedPDFPlugin::shouldShowDebugIndicators const):
(WebKit::UnifiedPDFPlugin::didChangeSettings):
(WebKit::UnifiedPDFPlugin::pageCoverageForRect const):
(WebKit::UnifiedPDFPlugin::paintPDFContent):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):

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


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

[webkit-changes] [WebKit/WebKit] 98c763: [UnifiedPDF] Introduce AsyncPDFRenderer

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 98c763e246170ff480978642d91f27ff6bff79e8
  
https://github.com/WebKit/WebKit/commit/98c763e246170ff480978642d91f27ff6bff79e8
  Author: Simon Fraser 
  Date:   2024-02-14 (Wed, 14 Feb 2024)

  Changed paths:
M Source/WebKit/Platform/Logging.h
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
A Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h
A Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h

  Log Message:
  ---
  [UnifiedPDF] Introduce AsyncPDFRenderer
https://bugs.webkit.org/show_bug.cgi?id=269368
rdar://122950491

Reviewed by Tim Horton.

This is the first step to rendering PDF content off the main thread.

AsyncPDFRenderer is a TiledBackingClient, so gets notified when the TileBacking 
needs
to repaint a tile. This causes it to enqueue a request to render a tile 
(identified by
a grid index/tile index pair in `TileForGrid`) on a workqueue (currently 
serial, but likely
concurrent in future). The tile rendering request includes a `PDFPageCoverage`, 
which
describes the set of PDF pages and their geometry which will go into this tile.

Rendering a tile on the work queue involves allocating an in-process 
ImageBuffer, calling
PDFDocument for the PDFPages for this tile, and drawing them (without 
selection). That
ImageBuffer is then transferred back to the main thread, and put into a cache, 
again
keyed by `TileForGrid`.

When a tile render is complete, we need to trigger a repaint so we can paint 
the tile
in the normal painting code path. There's a little trickiness to avoid 
continual repaints,
which is handled by `AsyncPDFRenderer::willRepaintTile()`.

* Source/WebKit/Platform/Logging.h:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::pdfDocument const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h: Added.
(WTF::TileForGridHash::hash):
(WTF::TileForGridHash::equal):
(WTF::HashTraits::emptyValue):
(WTF::HashTraits::deletedValue):
(WTF::HashTraits::constructDeletedValue):
(WTF::HashTraits::isDeletedValue):
(WebKit::AsyncPDFRenderer::paintingWorkQueue const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm: Added.
(WebKit::AsyncPDFRenderer::create):
(WebKit::AsyncPDFRenderer::AsyncPDFRenderer):
(WebKit::AsyncPDFRenderer::~AsyncPDFRenderer):
(WebKit::AsyncPDFRenderer::setupWithLayer):
(WebKit::AsyncPDFRenderer::willRepaintTile):
(WebKit::AsyncPDFRenderer::willRemoveTile):
(WebKit::AsyncPDFRenderer::willRepaintAllTiles):
(WebKit::AsyncPDFRenderer::clearCachedTiles):
(WebKit::AsyncPDFRenderer::enqueuePaintWithClip):
(WebKit::AsyncPDFRenderer::paintTileOnWorkQueue):
(WebKit::AsyncPDFRenderer::paintPDFIntoBuffer):
(WebKit::AsyncPDFRenderer::transferBufferToMainThread):
(WebKit::AsyncPDFRenderer::paintTileForClip):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:

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


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

[webkit-changes] [WebKit/WebKit] 201d69: [UnifiedPDF] Choose a good initial scale, and fix ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 201d691c2124b002de6280430852e50e0f9f997e
  
https://github.com/WebKit/WebKit/commit/201d691c2124b002de6280430852e50e0f9f997e
  Author: Simon Fraser 
  Date:   2024-02-14 (Wed, 14 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Choose a good initial scale, and fix various scaling issues
https://bugs.webkit.org/show_bug.cgi?id=269333
rdar://122907238

Reviewed by Tim Horton.

Fix various scaling issues with PDFs:
1. On first load, try to display at actual size, as long as that doesn't cause 
it to
   zoom in. Otherwise try to fix the entire height in the view. Implemented via 
the
   `AdjustScaleAfterLayout` argument to `updateLayout()`.

2. When changing layout modes, rescale using the same logic as first load.

3. When the PDF content is shorter than the view, vertically center it. 
Implemented
   by renaming and changing `sidePaddingWidth()` to return a FloatSize. It also 
now
   always computes padding, even when scaled above 1.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::installPDFDocument):
(WebKit::UnifiedPDFPlugin::attemptToUnlockPDF):
(WebKit::UnifiedPDFPlugin::updatePageBackgroundLayers):
(WebKit::UnifiedPDFPlugin::scaleForFitToView const):
(WebKit::UnifiedPDFPlugin::initialScale const):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::updateLayout):
(WebKit::UnifiedPDFPlugin::centeringOffset const):
(WebKit::UnifiedPDFPlugin::convertFromPluginToDocument const):
(WebKit::UnifiedPDFPlugin::convertFromDocumentToPlugin const):
(WebKit::UnifiedPDFPlugin::convertFromPageToContents const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):
(WebKit::UnifiedPDFPlugin::sidePaddingWidth const): Deleted.

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


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

[webkit-changes] [WebKit/WebKit] 622b90: [UnifiedPDF] Annotation hover and interaction is b...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 622b90f2c44db97d10326a6970b96588b7394705
  
https://github.com/WebKit/WebKit/commit/622b90f2c44db97d10326a6970b96588b7394705
  Author: Simon Fraser 
  Date:   2024-02-14 (Wed, 14 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Annotation hover and interaction is broken in rotated pages
https://bugs.webkit.org/show_bug.cgi?id=269344
rdar://122929753

Reviewed by Tim Horton.

The transform math in `documentSpaceToPageSpaceTransform()` was wrong, 
resulting in hit-testing
of annotations in rotated pages being wrong.

The page bounds vended by PDFDocumentLayout are normalized, so we can't use 
them for coordinate
conversion. We need to go back to the original page crop boxes. Clarify this by 
renaming
`boundsForPageAtIndex()` to `layoutBoundsForPageAtIndex()` since it is 
normalized, and contains
the layout offset of the page.

Then have PDFDocumentLayout store the original crop box per page. Internally, 
it computes
an AffineTransform from page rotation and crop box, and we use that and some 
coordinate flipping
to convert points.

Remove the FloatRect conversion functions on UnifiedPDFPlugin that I just 
added, because
they were wrong, and unused.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::updateLayout):
(WebKit::PDFDocumentLayout::layoutSingleColumn):
(WebKit::PDFDocumentLayout::layoutTwoUpColumn):
(WebKit::PDFDocumentLayout::layoutBoundsForPageAtIndex const):
(WebKit::PDFDocumentLayout::toPageTransform const):
(WebKit::PDFDocumentLayout::documentPointToPDFPagePoint const):
(WebKit::PDFDocumentLayout::pdfPagePointToDocumentPoint const):
(WebKit::PDFDocumentLayout::boundsForPageAtIndex const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updatePageBackgroundLayers):
(WebKit::UnifiedPDFPlugin::pageCoverageForRect const):
(WebKit::UnifiedPDFPlugin::scaleForActualSize const):
(WebKit::UnifiedPDFPlugin::heightForPage const):
(WebKit::UnifiedPDFPlugin::pageIndexForDocumentPoint const):
(WebKit::UnifiedPDFPlugin::convertFromDocumentToPage const):
(WebKit::UnifiedPDFPlugin::convertFromPageToDocument const):
(WebKit::documentSpaceToPageSpaceTransform): Deleted.

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


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

[webkit-changes] [WebKit/WebKit] 123df1: [UnifiedPDF] Annotation highlight is misplaced

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 123df1a5b3b0f7708a6076067a25817275e90b1f
  
https://github.com/WebKit/WebKit/commit/123df1a5b3b0f7708a6076067a25817275e90b1f
  Author: Simon Fraser 
  Date:   2024-02-13 (Tue, 13 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Annotation highlight is misplaced
https://bugs.webkit.org/show_bug.cgi?id=268359
rdar://121907143

Reviewed by Tim Horton.

Fix painting of the blue rectangle for hovered annotations. The bug was that
we were failing to convert the annotation bounds (which are in the coordinates
of the annotation's page) to the correct bounds for painting.

The natural way to fix this is to paint the annoations inside the
per-page painting loop, since we've already set up the coordinate system.

Make it easy to determine that we have something to paint here by adding
`pageIndexWithHoveredAnnotation()` which returns an optional PageIndex.
We can then check that inside the page-page loop.

I also implemented untested versions of `convertFromPageToDocument(FloatRect)`
and `convertFromPageToContents(FloatRect)` but they are unused in this patch.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h: Re-order 
things to improve logical grouping.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintPDFContent):
(WebKit::textAnnotationHoverColor):
(WebKit::UnifiedPDFPlugin::paintHoveredAnnotationOnPage):
(WebKit::UnifiedPDFPlugin::pageIndexWithHoveredAnnotation const):
(WebKit::UnifiedPDFPlugin::convertFromPageToDocument const):
(WebKit::UnifiedPDFPlugin::convertFromPageToContents const):
(WebKit::AnnotationTrackingState::startAnnotationTracking):
(WebKit::AnnotationTrackingState::finishAnnotationTracking):
(WebKit::UnifiedPDFPlugin::paintPDFOverlays): Deleted.

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


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

[webkit-changes] [WebKit/WebKit] 3f6d7f: Give TiledBacking a TiledBackingClient that allows...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3f6d7f5ff24f92cb8327e9d67a87755d6d3d47a4
  
https://github.com/WebKit/WebKit/commit/3f6d7f5ff24f92cb8327e9d67a87755d6d3d47a4
  Author: Simon Fraser 
  Date:   2024-02-13 (Tue, 13 Feb 2024)

  Changed paths:
M Source/WebCore/platform/graphics/TiledBacking.h
M Source/WebCore/platform/graphics/ca/TileController.cpp
M Source/WebCore/platform/graphics/ca/TileController.h
M Source/WebCore/platform/graphics/ca/TileGrid.cpp
M Source/WebCore/platform/graphics/ca/TileGrid.h
M Source/WebKit/WebProcess/WebPage/wc/GraphicsLayerWC.cpp

  Log Message:
  ---
  Give TiledBacking a TiledBackingClient that allows a client more knowledge of 
tile painting
https://bugs.webkit.org/show_bug.cgi?id=269268
rdar://122850594

Reviewed by Tim Horton.

Introduce TiledBackingClient, a weakly held client of TiledBacking that gets 
informed
when a tile is repainted or removed, and when all tiles are invalidate.

UnifiedPDFPlugin will use this as a basis for caching.

The client is informed about events per tile using TileGridIndex and TileIndex 
to
identify tiles; TileGridIndex is 0 for the main tile grid, and 1 for the 
optional zoomed-out
tile grid.

* Source/WebCore/platform/graphics/TiledBacking.h:
* Source/WebCore/platform/graphics/ca/TileController.cpp:
(WebCore::TileController::setClient):
(WebCore::TileController::willRepaintTile):
(WebCore::TileController::willRemoveTile):
(WebCore::TileController::willRepaintAllTiles):
* Source/WebCore/platform/graphics/ca/TileController.h:
* Source/WebCore/platform/graphics/ca/TileGrid.cpp:
(WebCore::TileGrid::setScale):
(WebCore::TileGrid::setNeedsDisplay):
(WebCore::TileGrid::setTileNeedsDisplayInRect):
(WebCore::TileGrid::removeTiles):
(WebCore::TileGrid::revalidateTiles):
(WebCore::TileGrid::ensureTilesForRect):
* Source/WebCore/platform/graphics/ca/TileGrid.h:
* Source/WebKit/WebProcess/WebPage/wc/GraphicsLayerWC.cpp:

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


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

[webkit-changes] [WebKit/WebKit] 6c12bd: [UnifiedPDF] Prepare for sharing some PDF page pai...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6c12bd338a35f85ab2f42e906e2dfc985c745e7b
  
https://github.com/WebKit/WebKit/commit/6c12bd338a35f85ab2f42e906e2dfc985c745e7b
  Author: Simon Fraser 
  Date:   2024-02-13 (Tue, 13 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Prepare for sharing some PDF page painting data with async 
rendering
https://bugs.webkit.org/show_bug.cgi?id=269270
rdar://122851341

Reviewed by Tim Horton.

Async PDF painting will need to be able to paint the set of pages that intersect
with a given clipRect (corresponding to a tile) in m_contentLayer coordinates,
in a way that does not use the thread-unsafe PDFDocumentLayout.

So make a little data structure, `PDFPageCoverage` to hold enough information 
about
the set of pages that intersect the given rect, and their geometry.

`UnifiedPDFPlugin::pageCoverageForRect()` computes this data, and  
`UnifiedPDFPlugin::paintPDFContent()`
is updated to use it.

Also pass a clipRect to `UnifiedPDFPlugin::paintPDFOverlays()` to avoid filling 
a rect outside the clip,
and make the code easier to read.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::pageCoverageForRect const):
(WebKit::UnifiedPDFPlugin::paintPDFContent):
(WebKit::UnifiedPDFPlugin::paintPDFOverlays):

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


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

[webkit-changes] [WebKit/WebKit] 44ecdd: Fix http/tests/pdf/linearized-pdf-in-iframe to act...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 44ecdd4e8ee1c31d2e2c85cd5665c965199a8857
  
https://github.com/WebKit/WebKit/commit/44ecdd4e8ee1c31d2e2c85cd5665c965199a8857
  Author: Simon Fraser 
  Date:   2024-02-09 (Fri, 09 Feb 2024)

  Changed paths:
M LayoutTests/http/tests/pdf/linearized-pdf-in-iframe-expected.html
M LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html
M LayoutTests/http/tests/resources/network-simulator.py
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm

  Log Message:
  ---
  Fix http/tests/pdf/linearized-pdf-in-iframe to actually test incremental PDF 
loading
https://bugs.webkit.org/show_bug.cgi?id=269102
rdar://122672100

Reviewed by Tim Horton.

Triggering the incremental PDF loading code path requires a fairly exact set of 
conditions
that need to be satisfied by the HTTP server:
1. Support for byte-range requests
2. Multithreading (handle a byte-range request while the main request is also 
being served)
3. Slow enough that a couple of initial byte-range requests complete before the 
main resource request

This PR enhances network-simulator.py to support byte-range requests, and 
tweaks the laoding speed
in the test.

With UnifiedPDF enabled, we hit a couple of `ASSERT(documentFinishedLoading())` 
in the data
provider callbacks on the main thread, under a painting callstack. This happens 
because UnifiedPDF
currently paints on the main thread, so relax those assertions (with some 
logging).

* LayoutTests/http/tests/pdf/linearized-pdf-in-iframe-expected.html:
* LayoutTests/http/tests/pdf/linearized-pdf-in-iframe.html:
* LayoutTests/http/tests/resources/network-simulator.py:
(generate_response):
(file_to_stdout):
(range_of_file_to_stdout):
(chunked_file_to_stdout):
(parse_byte_range):
(temp_path_base):
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::PDFPluginStreamLoaderClient::didReceiveResponse):
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::copyDataAtPosition const):
(WebKit::PDFPluginBase::streamDidReceiveData):
(WebKit::PDFPluginBase::streamDidFinishLoading):

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


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

[webkit-changes] [WebKit/WebKit] 984f02: [UnifiedPDF] Bring the white page background back

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 984f0241f040edefea7b2f1a2a032d9d28c72ef8
  
https://github.com/WebKit/WebKit/commit/984f0241f040edefea7b2f1a2a032d9d28c72ef8
  Author: Simon Fraser 
  Date:   2024-02-09 (Fri, 09 Feb 2024)

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

  Log Message:
  ---
  [UnifiedPDF] Bring the white page background back
https://bugs.webkit.org/show_bug.cgi?id=269110
rdar://122676777

Unreviewed.

Restore a line mistakenly left commented out, and remove a comment
that isn't applicable.

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

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


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

[webkit-changes] [WebKit/WebKit] dbb838: [UnifiedPDF] Make a background layers for each PDF...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dbb83825aeb7df83fc9c46a57eaaa663c47f8d9d
  
https://github.com/WebKit/WebKit/commit/dbb83825aeb7df83fc9c46a57eaaa663c47f8d9d
  Author: Simon Fraser 
  Date:   2024-02-08 (Thu, 08 Feb 2024)

  Changed paths:
M Source/WebCore/platform/graphics/GraphicsLayer.cpp
M Source/WebCore/platform/graphics/GraphicsLayer.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Make a background layers for each PDF page
https://bugs.webkit.org/show_bug.cgi?id=268834


Reviewed by Tim Horton.

When we start drawing PDF off the main thread, we'll need to have 
synchronously-drawn
boxes for where the pages will be. We can do that by making a small layer 
hierarchy
per page consisting of layers with no backing store, but just a white fill 
color,
and shadows.

The PDF continues to be painted into m_contentsLayer, which is higher in 
z-order than
the collection of page background layers.

* Source/WebCore/platform/graphics/GraphicsLayer.cpp:
(WebCore::GraphicsLayer::setIsInWindow):
* Source/WebCore/platform/graphics/GraphicsLayer.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::ensureLayers):
(WebKit::UnifiedPDFPlugin::updatePageBackgroundLayers):
(WebKit::UnifiedPDFPlugin::updateLayerHierarchy):
(WebKit::UnifiedPDFPlugin::didChangeSettings):
(WebKit::UnifiedPDFPlugin::didChangeIsInWindow):
(WebKit::UnifiedPDFPlugin::paintContents):
(WebKit::UnifiedPDFPlugin::paintPDFContent):
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::updateOverflowControlsLayers):
(WebKit::UnifiedPDFPlugin::setActiveAnnotation):

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


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

[webkit-changes] [WebKit/WebKit] 1021d6: Crash under RenderLayer::calculateClipRects() when...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1021d66fe7c33f8661132fbe8803e7bca4e91692
  
https://github.com/WebKit/WebKit/commit/1021d66fe7c33f8661132fbe8803e7bca4e91692
  Author: Simon Fraser 
  Date:   2024-02-08 (Thu, 08 Feb 2024)

  Changed paths:
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog-expected.txt
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog.html
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-expected.txt
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant-expected.txt
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant.html
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen.html
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover-expected.txt
A 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h

  Log Message:
  ---
  Crash under RenderLayer::calculateClipRects() when going into fullscreen
https://bugs.webkit.org/show_bug.cgi?id=268891
rdar://121960496

Reviewed by Alan Baradlay.

A combination of top layer and compositing backing sharing can cause a null 
de-ref when entering fullscreen,
or using modal dialogs or popovers.

The issue occurs when the renderer going into top layer participates in a 
backing sharing sequence, in the
`RenderLayer::paintsIntoProvidedBacking()` sense. What happens in that case is 
that after the top layer
configuration is changed we do a layout, after which 
`RenderLayerBacking::updateAfterLayout()` calls
`RenderLayerBacking::updateCompositedBounds()` (this seems like an odd thing to 
do, because we're going
to do a compositing update anyway, but a comment explains why we do it). This 
call requires that we compute
clip rects, which calls `RenderLayer::canUseOffsetFromAncestor()`, which gets 
confused because the ancestor
layer is no longer an ancestor.

The fix is to clear any relevant backing sharing sequences when going into top 
layer, where "relevant" means
backing sharing sequences in the stacking context of the layer that's going 
into top layer. We do that
by calling into RenderLayerCompositor from 
`RenderLayer::establishesTopLayerWillChange()`. Normally traversing
layers in a stacking context would walk the z-order lists, and this works for 
popover and dialog, but fullscreen
triggers a style update before this code runs, which clears the z-order lists. 
So this stacking context
traversal is written in terms of the RenderLayer tree (like `collectLayers()`).

* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog-expected.txt:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog.html:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-expected.txt:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant-expected.txt:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant.html:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen.html:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover-expected.txt:
 Added.
* 
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover.html:
 Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::establishesTopLayerWillChange):
(WebCore::RenderLayer::calculateClipRects const):
(WebCore::outputPaintOrderTreeLegend):
(WebCore::outputPaintOrderTreeRecursive):
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::establishesTopLayerWillChangeForLayer):
(WebCore::clearBackingSharingWithinStackingContext):
(WebCore::RenderLayerCompositor::clearBackingProviderSequencesInStackingContextOfLayer):
* Source/WebCore/rendering/RenderLayerCompositor.h:

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


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

[webkit-changes] [WebKit/WebKit] 5ffedc: Clarify the role of "mainFrameCanRubberBand" at th...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5ffedc5fb9606192a9b87137b74788c6efa93d70
  
https://github.com/WebKit/WebKit/commit/5ffedc5fb9606192a9b87137b74788c6efa93d70
  Author: Simon Fraser 
  Date:   2024-02-03 (Sat, 03 Feb 2024)

  Changed paths:
M Source/WebCore/page/scrolling/ScrollingTree.cpp
M Source/WebCore/page/scrolling/ScrollingTree.h
M Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm
M 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp
M Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp

  Log Message:
  ---
  Clarify the role of "mainFrameCanRubberBand" at the ScrollingTree level
https://bugs.webkit.org/show_bug.cgi?id=268697
rdar://122242780

Reviewed by Tim Horton.

ScrollingTree::mainFrameCanRubberBandOnSide() is easy to mis-use: it doesn't 
mean that rubber-banding
will happen, only that the client (Safari, Mail etc) has allowed rubber-banding 
to happen on this side.
So rename it accordingly.

This make it clear that 
`ScrollingTreeScrollingNodeDelegateMac::shouldRubberBandOnSide()` isn't
using it correctly. Future changes will fix that.

* Source/WebCore/page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::setClientAllowedMainFrameRubberBandableEdges):
(WebCore::ScrollingTree::clientAllowsMainFrameRubberBandingOnSide):
(WebCore::ScrollingTree::willWheelEventStartSwipeGesture):
(WebCore::ScrollingTree::setMainFrameCanRubberBand): Deleted.
(WebCore::ScrollingTree::mainFrameCanRubberBandOnSide): Deleted.
* Source/WebCore/page/scrolling/ScrollingTree.h:
* Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm:
(WebCore::ScrollingTreeScrollingNodeDelegateMac::shouldRubberBandOnSide const):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::handleWheelEvent):
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp:
(WebKit::RemoteLayerTreeEventDispatcher::determineWheelEventProcessing):
* Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp:
(WebKit::EventDispatcher::internalWheelEvent):

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


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

[webkit-changes] [WebKit/WebKit] 36b398: [UnifiedPDF] Add support for scaling to "Actual Size"

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 36b3983cdb3ffbf14af36378f00937c7f1ec92aa
  
https://github.com/WebKit/WebKit/commit/36b3983cdb3ffbf14af36378f00937c7f1ec92aa
  Author: Simon Fraser 
  Date:   2024-02-02 (Fri, 02 Feb 2024)

  Changed paths:
M Source/WebCore/PAL/pal/spi/cg/CoreGraphicsSPI.h
M Source/WebCore/platform/PlatformScreen.h
M Source/WebCore/platform/ScreenProperties.h
M Source/WebCore/platform/mac/PlatformScreenMac.mm
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Add support for scaling to "Actual Size"
https://bugs.webkit.org/show_bug.cgi?id=268665
rdar://122208262

Reviewed by Tim Horton.

Make it possible to display a PDF at "Actual Size", which results in the 
UnifiedPDFPlugin
choosing a scale that makes the PDF page size match physical screen inches.

To do this we need the screen DPI plumbed through from ScreenData (this will be
read in the UI Process, and fed to the Web Process via ScreenProperties).

Then we read the size of the first PDF page in points, convert to inches using 
the fixed
72DPI resolution that PDFs assume, and then scale via screenDPI.

* Source/WebCore/PAL/pal/spi/cg/CoreGraphicsSPI.h:
* Source/WebCore/platform/PlatformScreen.h:
* Source/WebCore/platform/ScreenProperties.h:
* Source/WebCore/platform/mac/PlatformScreenMac.mm:
(WebCore::collectScreenProperties):
(WebCore::ScreenData::screenDPI const):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::scaleForActualSize const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):

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


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

[webkit-changes] [WebKit/WebKit] 4b1ca4: REGRESSION(268028@main): Graphics artifacts when s...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4b1ca4f3add8483f04957886f45626e1e9b28a80
  
https://github.com/WebKit/WebKit/commit/4b1ca4f3add8483f04957886f45626e1e9b28a80
  Author: Simon Fraser 
  Date:   2024-02-02 (Fri, 02 Feb 2024)

  Changed paths:
A 
LayoutTests/compositing/shared-backing/overflow-scroll/composite-via-negative-z-descendants-interrupts-sequence-expected.html
A 
LayoutTests/compositing/shared-backing/overflow-scroll/composite-via-negative-z-descendants-interrupts-sequence.html
A 
LayoutTests/compositing/shared-backing/overflow-scroll/zero-sized-fixed-interrupts-sharing-sequence-expected.txt
A 
LayoutTests/compositing/shared-backing/overflow-scroll/zero-sized-fixed-interrupts-sharing-sequence.html
A 
LayoutTests/platform/ios-wk2/compositing/shared-backing/overflow-scroll/zero-sized-fixed-interrupts-sharing-sequence-expected.txt
M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  ---
  REGRESSION(268028@main): Graphics artifacts when scrolling Heroku app
https://bugs.webkit.org/show_bug.cgi?id=266926
rdar://120373474

Reviewed by Alan Baradlay.

Backing sharing is used to reduce memory use by allowing multiple RenderLayers 
(normally siblings),
which share the same stacking context ancestor, to render into the same 
compositing layer. This has
to be done in a way that preserves back-to-front paint order. The common case 
where this kicks in is
a non-stacking context overflow:scroll with position:relative descendants.

A backing sharing sequence (a set of layers painting into the same shared 
backing) has to be interrupted
when a layer becomes composited in order to preserve paint order. 268028@main 
inadvertently changed the
condition used to end a backing sharing sequence, breaking rendering with 
various content configurations.

Restore the condition to the previous state, which is to end the sequence if 
the the provider layer
is the same one we had before traversing into descendant layers.

Add two tests which detect the behavior change.

* 
LayoutTests/compositing/shared-backing/overflow-scroll/composite-via-negative-z-descendants-interrupts-sequence-expected.html:
 Added.
* 
LayoutTests/compositing/shared-backing/overflow-scroll/composite-via-negative-z-descendants-interrupts-sequence.html:
 Added.
* 
LayoutTests/compositing/shared-backing/overflow-scroll/zero-sized-fixed-interrupts-sharing-sequence-expected.txt:
 Added.
* 
LayoutTests/compositing/shared-backing/overflow-scroll/zero-sized-fixed-interrupts-sharing-sequence.html:
 Added.
* 
LayoutTests/platform/ios-wk2/compositing/shared-backing/overflow-scroll/zero-sized-fixed-interrupts-sharing-sequence-expected.txt:
 Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateBackingSharingAfterDescendantTraversal):

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


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

[webkit-changes] [WebKit/WebKit] dd64fd: Make the backing sharing logging more readable

[Simon Fraser]

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

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

  Log Message:
  ---
  Make the backing sharing logging more readable
https://bugs.webkit.org/show_bug.cgi?id=268528
rdar://122066519

Reviewed by Matt Woodrow.

Fix the logging indentation to it's easier to match it with the paint-order 
hierarchy.
Always print the layer address first.
Simplify the `BackingSharingState::Provider` output.

* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeCompositingRequirements):
(WebCore::RenderLayerCompositor::traverseUnchangedSubtree):
(WebCore::RenderLayerCompositor::updateBackingSharingBeforeDescendantTraversal):
(WebCore::RenderLayerCompositor::updateBackingSharingAfterDescendantTraversal):
(WebCore::operator<<):
* Source/WebCore/rendering/RenderLayerCompositor.h:

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


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

[webkit-changes] [WebKit/WebKit] f275b6: [UnifiedPDF] Hit-testing is broken in 2-up mode

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f275b68006b0787353414b953310cdcc56682501
  
https://github.com/WebKit/WebKit/commit/f275b68006b0787353414b953310cdcc56682501
  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] Hit-testing is broken in 2-up mode
https://bugs.webkit.org/show_bug.cgi?id=268394
rdar://121941334

Reviewed by Tim Horton.

`nearestPageIndexForDocumentPoint()` had a `notImplemented()` for two-up 
display.
It turns out that we don't need the concept of "nearest" page, so just change
the implementation to `pageBounds.contains(point)` for all layout modes.
Change the naming in `pdfElementTypesForPluginPoint()` to remove the "maybe" 
also.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::pageIndexForDocumentPoint const):
(WebKit::UnifiedPDFPlugin::pdfElementTypesForPluginPoint const):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::nearestPageIndexForDocumentPoint const): Deleted.

Canonical link: https://commits.webkit.org/273802@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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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