Bug 191442 – [iOS] Do not show selection UI for editable elements with opacity near zero

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Daniel Bates]

Pages on iCloud.com implement their own selection UI that interferes with the native iOS selection UI. Pages uses an editable element with CSS opacity set to value near 0 as a means to opt-out of selection painting on Mac. However, on iOS UIKit is responsible for painting the selection and providing selection assistance (i.e. the lollipops) and does not know about CSS opacity. I propose that we pass information about the editable node's opacity to the UIProcess so that we may opt-out of UIKit selection assistance and selection painting if the opacity is near 0.

[Daniel Bates]

Created attachment 354289 [details]
Patch

I am open to ideas on how to fix this bug as well as suggestions on the design in this proposed patch. I was unclear how to write a test for this change.

[Simon Fraser (smfr)]

Don't we have UIScriptController stuff to get selection rects?

[Daniel Bates]

(In reply to Simon Fraser (smfr) from comment #2)
> Don't we have UIScriptController stuff to get selection rects?

Does this tell us the UIView selection rect? This patch is all about painting. We want UIKit to know what text is selected. We just don’t want UIKit to paint the selection. Show the lollipops or a callout bar.

[Wenson Hsieh]

(In reply to Daniel Bates from comment #3)
> (In reply to Simon Fraser (smfr) from comment #2)
> > Don't we have UIScriptController stuff to get selection rects?
> 
> Does this tell us the UIView selection rect? This patch is all about
> painting. We want UIKit to know what text is selected. We just don’t want
> UIKit to paint the selection. Show the lollipops or a callout bar.

See:

UIHelper.getUISelectionRects()
UIHelper.getSelectionStartGrabberViewRect()

etc.

IIRC, there are some examples in editing/selection/ios

[Wenson Hsieh]

(In reply to Daniel Bates from comment #1)
> Created attachment 354289 [details]
> Patch
> 
> I am open to ideas on how to fix this bug as well as suggestions on the
> design in this proposed patch. I was unclear how to write a test for this
> change.

I had a patch to fix this not too long ago.

I remember one mildly tricky thing to get right is handling hidden contenteditable subframes. For example, typing and editing in the hidden area in <https://whsieh.github.io/examples/hidden-contenteditable> shouldn't cause native selection UI to pop up.

[Wenson Hsieh]

(In reply to Wenson Hsieh from comment #4)
> (In reply to Daniel Bates from comment #3)
> > (In reply to Simon Fraser (smfr) from comment #2)
> > > Don't we have UIScriptController stuff to get selection rects?
> > 
> > Does this tell us the UIView selection rect? This patch is all about
> > painting. We want UIKit to know what text is selected. We just don’t want
> > UIKit to paint the selection. Show the lollipops or a callout bar.
> 
> See:
> 
> UIHelper.getUISelectionRects()
> UIHelper.getSelectionStartGrabberViewRect()
> 
> etc.
> 
> IIRC, there are some examples in editing/selection/ios

Oh, do you mean we want to detect when the view is transparent, even if it has a nonzero frame?

It seems reasonable to add this functionality to UIScriptController, if what we have now doesn't suffice.

[Daniel Bates]

(In reply to Wenson Hsieh from comment #5)
> (In reply to Daniel Bates from comment #1)
> > Created attachment 354289 [details]
> > Patch
> > 
> > I am open to ideas on how to fix this bug as well as suggestions on the
> > design in this proposed patch. I was unclear how to write a test for this
> > change.
> 
> I had a patch to fix this not too long ago.
> 

Please post your patch!

[Daniel Bates]

Created attachment 354397 [details]
Layout Tests

[Daniel Bates]

Wenson is willing to take over this bug since he has an existing patch.

@Wenson: Here are some tests. Feel free to use them or scrap them.

[Radar WebKit Bug Importer]

<rdar://problem/45958625>

[Wenson Hsieh]

Created attachment 354531 [details]
WIP (needs tests)

[Wenson Hsieh]

Created attachment 354648 [details]
First pass

[Wenson Hsieh]

Created attachment 354650 [details]
Add missing layout test.

[Simon Fraser (smfr)]

Comment on attachment 354650 [details]
Add missing layout test.

View in context: https://bugs.webkit.org/attachment.cgi?id=354650&action=review

> Source/WebCore/rendering/RenderObject.cpp:1525
> +        if (layerRenderer.style().opacity() < minimumVisibleOpacity)
> +            return true;

Opacity is multiplicative, so ideally you'd multiply it during your tree walk. For example, try ten nested divs with opacity 0.1.

[Wenson Hsieh]

Comment on attachment 354650 [details]
Add missing layout test.

View in context: https://bugs.webkit.org/attachment.cgi?id=354650&action=review

>> Source/WebCore/rendering/RenderObject.cpp:1525
>> +            return true;
> 
> Opacity is multiplicative, so ideally you'd multiply it during your tree walk. For example, try ten nested divs with opacity 0.1.

Oh, good point! I'll multiply on the way up, and add another layout test for this scenario as well.

[Wenson Hsieh]

Created attachment 354689 [details]
Patch for EWS

[Wenson Hsieh]

Created attachment 354691 [details]
Patch for EWS

[WebKit Commit Bot]

Comment on attachment 354691 [details]
Patch for EWS

Clearing flags on attachment: 354691

Committed r238146: <https://trac.webkit.org/changeset/238146>