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.
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.
Don't we have UIScriptController stuff to get selection rects?
(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.
(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
(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.
(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.
(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!
Created attachment 354397 [details] Layout Tests
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.
<rdar://problem/45958625>
Created attachment 354531 [details] WIP (needs tests)
Created attachment 354648 [details] First pass
Created attachment 354650 [details] Add missing layout test.
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.
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.
Created attachment 354689 [details] Patch for EWS
Created attachment 354691 [details] Patch for EWS
Comment on attachment 354691 [details] Patch for EWS Clearing flags on attachment: 354691 Committed r238146: <https://trac.webkit.org/changeset/238146>