Find in Note: Dark gray outline (shadow) appears behind gray/yellow highlights when matched text found in HTML note. #25600

megangardner · 2024-03-07T23:34:23Z

`89bc7dd`

Find in Note: Dark gray outline (shadow) appears behind gray/yellow highlights when matched text found in HTML note.
https://bugs.webkit.org/show_bug.cgi?id=270666
rdar://122843511

Reviewed by Aditya Keerthi.

In notes, the WKContentView is transparent, so our original solution of putting an additional
grey layer behind the content view that filled up the empty parts of the scroll view would show
through and make the find ui have a incorrect grey cast. So instead, we make four views that surround
the WKContentView to fill in any part of the scrollView that isn't covered by the contentView.
These are arranged around the content view like so:

----- -----------
|    |          |
|    |----------|
|    |     |    |
|    |     |    |
----- ------    |
|          |    |
|__________|____|

Each view is expanded to reach the edges of the scroll view every time the view is scrolled or the bounds change.
This means that no matter where the content view is scrolled to, there will be a view that gives the correct
grey cast to the scroll view.

* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView scrollViewDidScroll:]):
(-[WKWebView _frameOrBoundsMayHaveChanged]):
(-[WKWebView _updateFindOverlayForOverflowScrollPositions]):
(-[WKWebView _showFindOverlay]):
(-[WKWebView _hideFindOverlay]):
(-[WKWebView _didAddLayerForFindOverlay:]):
(-[WKWebView _updateFindOverlayPosition]): Deleted.

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

e2c2fca

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		✅ 🧪 api-gtk
✅ 🛠 🧪 merge	✅ 🛠 watch
	✅ 🛠 watch-sim

webkit-early-warning-system · 2024-03-07T23:34:30Z

EWS run on previous version of this PR (hash d56bafe)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	❌ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	❌ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	❌ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	❌ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		✅ 🧪 api-gtk
	✅ 🛠 watch
	✅ 🛠 watch-sim

rr-codes · 2024-03-07T23:46:53Z

Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h

@@ -201,6 +201,15 @@ struct PerWebProcessState {

 #endif // PLATFORM(IOS_FAMILY)

+#if HAVE(UIFINDINTERACTION)
+enum FindOverlayView {


should this be an enum class : uint8_t ?

or maybe it should just be a struct instead of an enum + a loosely-ordered vector? like

struct FindOverlayViews { RetainPtr<UIView> left; // etc }

pxlcoder · 2024-03-07T23:47:43Z

Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h

@@ -201,6 +201,15 @@ struct PerWebProcessState {

 #endif // PLATFORM(IOS_FAMILY)

+#if HAVE(UIFINDINTERACTION)
+enum FindOverlayView {


Suggested change

enum FindOverlayView {

enum class FindOverlayViewPosition : uint8_t {

Probably best to also move this to the .mm file, since it isn't needed outside of it.

pxlcoder · 2024-03-07T23:49:56Z

Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h

@@ -247,7 +256,7 @@ struct PerWebProcessState {

    BOOL _findInteractionEnabled;
 #if HAVE(UIFINDINTERACTION)
-    RetainPtr<UIView> _findOverlay;
+    Vector<RetainPtr<UIView>> _findOverlaysForOverflowScroll; // Top, right, bottom, left


"OverflowScroll" is bit of an overloaded term here, since this is not really about overflow: scroll.

_findOverlaysOutsideContentView might be more accurate.

aprotyas

The fix LGTM actually -- I'm suggesting an alternative approach to manage the overlays

aprotyas · 2024-03-07T23:38:58Z

Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h

@@ -201,6 +201,15 @@ struct PerWebProcessState {

 #endif // PLATFORM(IOS_FAMILY)

+#if HAVE(UIFINDINTERACTION)
+enum FindOverlayView {


Make this an enum class please?

Oh, I see why you did it like this. My other comment speaks in a different direction if you want to consider that.

aprotyas · 2024-03-07T23:41:52Z

Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h

@@ -247,7 +256,7 @@ struct PerWebProcessState {

    BOOL _findInteractionEnabled;
 #if HAVE(UIFINDINTERACTION)
-    RetainPtr<UIView> _findOverlay;
+    Vector<RetainPtr<UIView>> _findOverlaysForOverflowScroll; // Top, right, bottom, left


The overlay ordering enforcement is a little fragile... particularly since it's documented through a comment. What do you think about introducing a structure that captures what is going on?

struct OverflowScrollOverlays { RetainPtr<UIView> top; RetainPtr<UIView> right; RetainPtr<UIView> bottom; RetainPtr<UIView> left; }; OverflowScrollOverlays _findOverlaysForOverflowScroll;

That way you can also get rid of enum FindOverlayView?

aprotyas · 2024-03-07T23:46:13Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

+    auto topView = _findOverlaysForOverflowScroll[FindOverlayView::Top].get();
+    auto rightView = _findOverlaysForOverflowScroll[FindOverlayView::Right].get();
+    auto bottomView = _findOverlaysForOverflowScroll[FindOverlayView::Bottom].get();
+    auto leftView = _findOverlaysForOverflowScroll[FindOverlayView::Left].get();


Our smart pointer guidelines suggest these should remain as smart pointers on the stack, so I think we prefer:

Suggested change

auto topView = _findOverlaysForOverflowScroll[FindOverlayView::Top].get();

auto rightView = _findOverlaysForOverflowScroll[FindOverlayView::Right].get();

auto bottomView = _findOverlaysForOverflowScroll[FindOverlayView::Bottom].get();

auto leftView = _findOverlaysForOverflowScroll[FindOverlayView::Left].get();

RetainPtr topView = _findOverlaysForOverflowScroll[FindOverlayView::Top];

RetainPtr rightView = _findOverlaysForOverflowScroll[FindOverlayView::Right];

RetainPtr bottomView = _findOverlaysForOverflowScroll[FindOverlayView::Bottom];

RetainPtr leftView = _findOverlaysForOverflowScroll[FindOverlayView::Left];

aprotyas · 2024-03-07T23:47:18Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

-        UIColor *overlayColor = [UIColor colorWithRed:(26. / 255) green:(26. / 255) blue:(26. / 255) alpha:(64. / 255)];
-        [_findOverlay setBackgroundColor:overlayColor];
+    UIColor *overlayColor = [UIColor colorWithRed:(26. / 255) green:(26. / 255) blue:(26. / 255) alpha:(64. / 255)];
+    if (!_findOverlaysForOverflowScroll.size()) {


Nit: _findOverlaysForOverflowScroll.isEmpty() is a little easier to read

pxlcoder · 2024-03-07T23:51:32Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

-        _findOverlay = adoptNS([[UIView alloc] init]);
-        UIColor *overlayColor = [UIColor colorWithRed:(26. / 255) green:(26. / 255) blue:(26. / 255) alpha:(64. / 255)];
-        [_findOverlay setBackgroundColor:overlayColor];
+    UIColor *overlayColor = [UIColor colorWithRed:(26. / 255) green:(26. / 255) blue:(26. / 255) alpha:(64. / 255)];


This can be moved inside the if.

pxlcoder · 2024-03-07T23:53:11Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm


    if (CALayer *contentViewFindOverlayLayer = [self _layerForFindOverlay]) {
-        [[_findOverlay layer] removeAllAnimations];
-        [contentViewFindOverlayLayer removeAllAnimations];
+        for (RetainPtr overlay : _findOverlaysForOverflowScroll) {


Given the repetition of this loop, we could have a method like _updateFindOverlaysOutsideContentView: that takes a block, and calls the block on each view.

or just make it an initializer list like for (RetainPtr overlay : { _findOverlaysForOverflowScroll.left, _findOverlaysForOverflowScroll.right, etc {) ?

pxlcoder · 2024-03-08T00:15:24Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm


        [strongSelf _removeLayerForFindOverlay];
    }];

    [contentViewFindOverlayLayer addAnimation:animation forKey:@"findOverlayFadeOut"];
-    [findOverlayLayer addAnimation:animation forKey:@"findOverlayFadeOut"];
+    for (RetainPtr overlay : _findOverlaysForOverflowScroll)
+        [overlay addAnimation:animation forKey:@"findOverlayFadeOut"];


Suggested change

[overlay addAnimation:animation forKey:@"findOverlayFadeOut"];

[[overlay layer] addAnimation:animation forKey:@"findOverlayFadeOut"];

webkit-early-warning-system · 2024-03-08T04:05:32Z

EWS run on previous version of this PR (hash 9ff9300)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	⏳ 🧪 wpe-wk2
✅ 🧪 webkitperl	~~🧪 ios-wk2~~	~~🧪 api-mac~~	⏳ 🧪 api-wpe
	⏳ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	~~🧪 api-ios~~	~~🧪 mac-wk2~~	✅ 🛠 gtk
	~~🛠 tv~~	⏳ 🧪 mac-AS-debug-wk2	⏳ 🧪 gtk-wk2
	~~🛠 tv-sim~~		⏳ 🧪 api-gtk
	✅ 🛠 watch
	~~🛠 watch-sim~~

rr-codes · 2024-03-08T04:06:28Z

Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h

@@ -247,7 +247,13 @@ struct PerWebProcessState {

    BOOL _findInteractionEnabled;
 #if HAVE(UIFINDINTERACTION)
-    RetainPtr<UIView> _findOverlay;
+    struct findOverlays {


nit: should be FindOverlays

pxlcoder · 2024-03-08T04:07:31Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm


    [CATransaction commit];

    contentViewFindOverlayLayer.opacity = 0;
-    findOverlayLayer.opacity = 0;
+    [_findOverlaysOutsideContentView.value().top layer].opacity = 0;


Anywhere you use value() should just be ->.

But please also try to do this #25600 (comment), so that only needs to happen in one place.

webkit-early-warning-system · 2024-03-08T04:42:15Z

EWS run on previous version of this PR (hash 9d068dd)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	⏳ 🧪 wpe-wk2
✅ 🧪 webkitperl	~~🧪 ios-wk2~~	~~🧪 api-mac~~	⏳ 🧪 api-wpe
	⏳ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	~~🧪 api-ios~~	~~🧪 mac-wk2~~	✅ 🛠 gtk
	~~🛠 tv~~	✅ 🧪 mac-AS-debug-wk2	⏳ 🧪 gtk-wk2
	~~🛠 tv-sim~~		⏳ 🧪 api-gtk
	❌ 🛠 watch
	~~🛠 watch-sim~~

webkit-early-warning-system · 2024-03-08T05:02:16Z

EWS run on previous version of this PR (hash 58f0910)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	❌ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		✅ 🧪 api-gtk
	✅ 🛠 watch
	✅ 🛠 watch-sim

pxlcoder · 2024-03-08T05:39:05Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

        [self _addLayerForFindOverlay];
    }
 }

 - (void)_hideFindOverlay
 {
    CALayer *contentViewFindOverlayLayer = [self _layerForFindOverlay];
-    CALayer *findOverlayLayer = [_findOverlay layer];
+    CALayer *findOverlayLayer = [_findOverlaysOutsideContentView.value().top layer];


What guarantees _findOverlaysOutsideContentView is not std::nullopt here? I think you need to update the check of line 3430 to check for that, and then move this line after the early return – otherwise this is a change in logic.

pxlcoder · 2024-03-08T05:39:58Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

        [self _addLayerForFindOverlay];
    }
 }

 - (void)_hideFindOverlay
 {
    CALayer *contentViewFindOverlayLayer = [self _layerForFindOverlay];
-    CALayer *findOverlayLayer = [_findOverlay layer];
+    CALayer *findOverlayLayer = [_findOverlaysOutsideContentView.value().top layer];


Also -> rather than value().

pxlcoder · 2024-03-08T05:41:12Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

@@ -3559,20 +3608,33 @@ - (_UIDataOwner)_effectiveDataOwner:(_UIDataOwner)clientSuppliedDataOwner
    return _UIDataOwnerUndefined;
 }

+#if HAVE(UIFINDINTERACTION)
+- (void)_updateFindOverlaysOutsideContentView:(void(^)(RetainPtr<UIView>))updateFindOverlays


Suggested change

- (void)_updateFindOverlaysOutsideContentView:(void(^)(RetainPtr<UIView>))updateFindOverlays

- (void)_updateFindOverlaysOutsideContentView:(void(^)(UIView *))updateFindOverlays

This should be UIView * rather than RetainPtr to avoid ref-churn.

pxlcoder · 2024-03-08T05:42:06Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

+    updateFindOverlays(_findOverlaysOutsideContentView->top);
+    updateFindOverlays(_findOverlaysOutsideContentView->bottom);
+    updateFindOverlays(_findOverlaysOutsideContentView->left);
+    updateFindOverlays(_findOverlaysOutsideContentView->right);


Suggested change

updateFindOverlays(_findOverlaysOutsideContentView->top);

updateFindOverlays(_findOverlaysOutsideContentView->bottom);

updateFindOverlays(_findOverlaysOutsideContentView->left);

updateFindOverlays(_findOverlaysOutsideContentView->right);

updateFindOverlay(_findOverlaysOutsideContentView->top);

updateFindOverlay(_findOverlaysOutsideContentView->bottom);

updateFindOverlay(_findOverlaysOutsideContentView->left);

updateFindOverlay(_findOverlaysOutsideContentView->right);

pxlcoder · 2024-03-08T05:43:40Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

        [contentViewFindOverlayLayer setOpacity:1];
    } else {
-        [_findOverlay setAlpha:0];
+        if (_findOverlaysOutsideContentView) {


I don't think this check is necessary? The variable is always initialized by this method.

webkit-early-warning-system · 2024-03-08T17:56:19Z

EWS run on previous version of this PR (hash 2ccc05f)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	~~🧪 api-mac~~	~~🧪 api-wpe~~
	~~🧪 ios-wk2-wpt~~		✅ 🛠 wpe-skia
	~~🧪 api-ios~~	~~🧪 mac-wk2~~	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	⏳ 🧪 gtk-wk2
	~~🛠 tv-sim~~		~~🧪 api-gtk~~
	~~🛠 watch~~
	~~🛠 watch-sim~~

webkit-early-warning-system · 2024-03-08T18:28:18Z

EWS run on previous version of this PR (hash b299aa4)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	~~🧪 api-mac~~	~~🧪 api-wpe~~
	~~🧪 ios-wk2-wpt~~		~~🛠 wpe-skia~~
	~~🧪 api-ios~~	~~🧪 mac-wk2~~	✅ 🛠 gtk
	✅ 🛠 tv	~~🧪 mac-AS-debug-wk2~~	~~🧪 gtk-wk2~~
	~~🛠 tv-sim~~		✅ 🧪 api-gtk
	✅ 🛠 watch
	~~🛠 watch-sim~~

pxlcoder · 2024-03-08T18:32:35Z

Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

@@ -3404,22 +3445,28 @@ - (void)_hideFindOverlay
        if (!strongSelf)
            return;

-        if ([strongSelf->_findOverlay alpha])
-            return;
+        [strongSelf _removeLayerForFindOverlay];


Shouldn't this be after the early return, as it was before?

I think this is in the right place, I added the other early return to check of the new overlays are in place before calling remove from them. It's possible, but unlikely, that we have an overlay layer without the overlay views, and I don't want to not remove the layer just because the views aren't there. (Or I could be misunderstanding your concern.)

It's possible to have the overlay views outside the content view without the PageOverlay layer, but not vice-versa. This is because _showFindOverlay always creates the overlay views outside the content view, before creating the PageOverlay.

I think the existing structure of the code is necessary in order to guard against scenarios where the find overlay is brought up again as it's animating out – which is possible due to the async nature of the code.

So the way this code needs to be written to preserve the existing structure is:

bool hasOverlaysOutsideContentView = strongSelf->_findOverlaysOutsideContentView.has_value(); if (hasOverlaysOutsideContentView && [strongSelf->_findOverlaysOutsideContentView->top alpha]]) return; [strongSelf _removeLayerForFindOverlay]; if (hasOverlaysOutsideContentView) { [strongSelf _updateFindOverlaysOutsideContentView:^(UIView *view) { [view removeFromSuperview]; }]; strongSelf->_findOverlaysOutsideContentView.reset(); }

webkit-early-warning-system · 2024-03-08T19:17:34Z

EWS run on previous version of this PR (hash 7c64366)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	⏳ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	⏳ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	❌ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		✅ 🧪 api-gtk
	✅ 🛠 watch
	✅ 🛠 watch-sim

webkit-early-warning-system · 2024-03-09T07:03:24Z

EWS run on current version of this PR (hash e2c2fca)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt		✅ 🛠 wpe-skia
	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		✅ 🧪 api-gtk
✅ 🛠 🧪 merge	✅ 🛠 watch
	✅ 🛠 watch-sim

webkit-ews-buildbot · 2024-03-09T09:40:26Z

Safe-Merge-Queue: Build #14419.

…ighlights when matched text found in HTML note. https://bugs.webkit.org/show_bug.cgi?id=270666 rdar://122843511 Reviewed by Aditya Keerthi. In notes, the WKContentView is transparent, so our original solution of putting an additional grey layer behind the content view that filled up the empty parts of the scroll view would show through and make the find ui have a incorrect grey cast. So instead, we make four views that surround the WKContentView to fill in any part of the scrollView that isn't covered by the contentView. These are arranged around the content view like so: ----- ----------- | | | | |----------| | | | | | | | | ----- ------ | | | | |__________|____| Each view is expanded to reach the edges of the scroll view every time the view is scrolled or the bounds change. This means that no matter where the content view is scrolled to, there will be a view that gives the correct grey cast to the scroll view. * Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h: * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm: (-[WKWebView scrollViewDidScroll:]): (-[WKWebView _frameOrBoundsMayHaveChanged]): (-[WKWebView _updateFindOverlayForOverflowScrollPositions]): (-[WKWebView _showFindOverlay]): (-[WKWebView _hideFindOverlay]): (-[WKWebView _didAddLayerForFindOverlay:]): (-[WKWebView _updateFindOverlayPosition]): Deleted. Canonical link: https://commits.webkit.org/275873@main

webkit-commit-queue · 2024-03-09T09:47:00Z

Committed 275873@main (89bc7dd): https://commits.webkit.org/275873@main

Reviewed commits have been landed. Closing PR #25600 and removing active labels.

megangardner requested a review from cdumez as a code owner March 7, 2024 23:34

megangardner self-assigned this Mar 7, 2024

megangardner added the WebKit Misc. For miscellaneous bugs in the WebKit framework (and not JavaScriptCore or WebCore). label Mar 7, 2024

megangardner requested review from smfr, hortont424, whsieh, pxlcoder, rr-codes and aprotyas March 7, 2024 23:36

rr-codes reviewed Mar 7, 2024

View reviewed changes

pxlcoder reviewed Mar 7, 2024

View reviewed changes

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 7, 2024

aprotyas reviewed Mar 7, 2024

View reviewed changes

pxlcoder reviewed Mar 7, 2024

View reviewed changes

pxlcoder reviewed Mar 8, 2024

View reviewed changes

megangardner removed the merging-blocked Applied to prevent a change from being merged label Mar 8, 2024

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from d56bafe to 9ff9300 Compare March 8, 2024 03:59

megangardner requested review from pxlcoder, rr-codes and aprotyas March 8, 2024 04:00

rr-codes reviewed Mar 8, 2024

View reviewed changes

pxlcoder reviewed Mar 8, 2024

View reviewed changes

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from 9ff9300 to 9d068dd Compare March 8, 2024 04:42

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 8, 2024

megangardner removed the merging-blocked Applied to prevent a change from being merged label Mar 8, 2024

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from 9d068dd to 58f0910 Compare March 8, 2024 04:54

pxlcoder reviewed Mar 8, 2024

View reviewed changes

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 8, 2024

megangardner removed the merging-blocked Applied to prevent a change from being merged label Mar 8, 2024

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from 58f0910 to 2ccc05f Compare March 8, 2024 17:44

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from 2ccc05f to b299aa4 Compare March 8, 2024 18:21

pxlcoder approved these changes Mar 8, 2024

View reviewed changes

pxlcoder reviewed Mar 8, 2024

View reviewed changes

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from b299aa4 to 7c64366 Compare March 8, 2024 19:12

megangardner added the safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks label Mar 8, 2024

megangardner force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from 7c64366 to e2c2fca Compare March 9, 2024 07:03

webkit-ews-buildbot added merge-queue Applied to send a pull request to merge-queue and removed safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks labels Mar 9, 2024

webkit-commit-queue force-pushed the eng/Find-in-Note-Dark-gray-outline-shadow-appears-behind-grayyellow-highlights-when-matched-text-found-in-HTML-note- branch from e2c2fca to 89bc7dd Compare March 9, 2024 09:46

webkit-commit-queue merged commit 89bc7dd into WebKit:main Mar 9, 2024

webkit-commit-queue removed the merge-queue Applied to send a pull request to merge-queue label Mar 9, 2024

	enum FindOverlayView {
	enum class FindOverlayViewPosition : uint8_t {

	[overlay addAnimation:animation forKey:@"findOverlayFadeOut"];
	[[overlay layer] addAnimation:animation forKey:@"findOverlayFadeOut"];

	- (void)_updateFindOverlaysOutsideContentView:(void(^)(RetainPtr<UIView>))updateFindOverlays
	- (void)_updateFindOverlaysOutsideContentView:(void(^)(UIView *))updateFindOverlays

Find in Note: Dark gray outline (shadow) appears behind gray/yellow highlights when matched text found in HTML note. #25600

Find in Note: Dark gray outline (shadow) appears behind gray/yellow highlights when matched text found in HTML note. #25600

Conversation

megangardner commented Mar 7, 2024 • edited by webkit-early-warning-system Loading

webkit-early-warning-system commented Mar 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aprotyas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

webkit-early-warning-system commented Mar 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

webkit-early-warning-system commented Mar 8, 2024 • edited Loading

webkit-early-warning-system commented Mar 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

webkit-early-warning-system commented Mar 8, 2024 • edited Loading

webkit-early-warning-system commented Mar 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pxlcoder Mar 8, 2024 • edited Loading

Choose a reason for hiding this comment

webkit-early-warning-system commented Mar 8, 2024 • edited Loading

webkit-early-warning-system commented Mar 9, 2024 • edited Loading

webkit-ews-buildbot commented Mar 9, 2024

webkit-commit-queue commented Mar 9, 2024

megangardner commented Mar 7, 2024 •

edited by webkit-early-warning-system

Loading

webkit-early-warning-system commented Mar 7, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 8, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 8, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 8, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 8, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 8, 2024 •

edited

Loading

pxlcoder Mar 8, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 8, 2024 •

edited

Loading

webkit-early-warning-system commented Mar 9, 2024 •

edited

Loading