[webkit-changes] [WebKit/WebKit] 77eafb: REGRESSION (278263 at main): [UnifiedPDF] Using Find-...

Abrar Rahman Protyasha noreply at github.com
Wed May 8 14:41:50 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 77eafb20baed5e72c36099fb632a4388bfe5c821
      https://github.com/WebKit/WebKit/commit/77eafb20baed5e72c36099fb632a4388bfe5c821
  Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
  Date:   2024-05-08 (Wed, 08 May 2024)

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

  Log Message:
  -----------
  REGRESSION (278263 at main): [UnifiedPDF] Using Find-in-page results in stuck text selections
https://bugs.webkit.org/show_bug.cgi?id=273891
rdar://127678373

Reviewed by Sammy Gill.

We gate our interactions with the selection layer behind a selector
check for `enumerateRectsAndTransformsForPage:usingBlock:` on the current
selection. When the current selection gets nulled, because, say,
Find-in-page is dismissed, canPaintSelectionIntoOwnedLayer() returns
false. This causes the selection rect invalidation to target the content
layer and not the selection layer.

This means that since 278263 at main, we’ve been getting a hodgepodge of
painting selection rects on both the content layer and the selection
layer, which is clearly incorrect.

The fix here is to not perform the selector check on the current
selection, but instead to perform an instancesRespondToSelector check on
the PDFSelection class itself, since all we care about is the runtime
availability of the `enumreateRectsAndTransformsForPage:usingBlock:` API.

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

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



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


More information about the webkit-changes mailing list