RESOLVED FIXED 173860
[iOS DnD] Text indicators for dragged links should always be legible if the link is legible
https://bugs.webkit.org/show_bug.cgi?id=173860
Summary [iOS DnD] Text indicators for dragged links should always be legible if the l...
Wenson Hsieh
Reported 2017-06-26 20:47:34 PDT
Attachments
Patch (2.62 KB, patch)
2017-06-26 20:58 PDT, Wenson Hsieh
no flags
Patch (6.97 KB, patch)
2017-06-26 22:53 PDT, Wenson Hsieh
no flags
Patch (7.67 KB, patch)
2017-06-30 16:25 PDT, Wenson Hsieh
thorton: review+
Patch for landing (7.66 KB, patch)
2017-06-30 18:26 PDT, Wenson Hsieh
no flags
Wenson Hsieh
Comment 1 2017-06-26 20:58:06 PDT
Tim Horton
Comment 2 2017-06-26 21:08:22 PDT
Comment on attachment 313893 [details] Patch Do we really want to paintAllContent always? We’re going to end up painting text outside the requested range now (even in the simple case), leading to more weird intrusions, and also background images and stuff. I dunno. Something conditional seems less crazy.
Tim Horton
Comment 3 2017-06-26 21:09:21 PDT
(Test on pages with tight leading, or links with no space between them and text.
Wenson Hsieh
Comment 4 2017-06-26 21:19:24 PDT
This is true. There's certainly a chance now of grabbing bits of nearby content that would be unwanted, but I considered this better than certain cases (such as the one in this bug) where the link isn't legible at all. Really, what would be nice to do is compare the text color of the link against the estimated background color before taking the snapshot, and only use TextIndicatorOptionPaintAllContent if the text color is too close to the estimated background color, otherwise use TextIndicatorOptionUseBoundingRectAndPaintAllContentForComplexRanges. I'm not sure what constitutes "too close" though. Maybe something like differenceSquared(textColor, backgroundColor) > minColorDifference? Seems hacky, but might work well in practice.
Wenson Hsieh
Comment 5 2017-06-26 21:47:58 PDT
Comment on attachment 313893 [details] Patch I'll be going with a more nuanced approach here.
Wenson Hsieh
Comment 6 2017-06-26 22:53:25 PDT
Tim Horton
Comment 7 2017-06-26 23:08:51 PDT
Comment on attachment 313899 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=313899&action=review > Source/WebCore/page/TextIndicator.cpp:238 > for (; !!renderer; renderer = renderer->parent()) { This is climbing upwards; what if the text color comes from a child of the common ancestor instead of a parent? Should see if Antti has any ideas about how to do this well, it seems right up his alley
Wenson Hsieh
Comment 8 2017-06-30 16:25:19 PDT
Tim Horton
Comment 9 2017-06-30 16:36:26 PDT
Comment on attachment 314315 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314315&action=review > Source/WebCore/page/TextIndicator.cpp:230 > + auto& color = node->renderer()->style().color(); Any need for a renderer null check? Any chance to get here with an anonymous element?
Wenson Hsieh
Comment 10 2017-06-30 16:37:17 PDT
Comment on attachment 314315 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314315&action=review Thanks! >> Source/WebCore/page/TextIndicator.cpp:230 >> + auto& color = node->renderer()->style().color(); > > Any need for a renderer null check? Any chance to get here with an anonymous element? The is<RenderText>() check above should take care of this, since is<> bails on null.
Tim Horton
Comment 11 2017-06-30 16:38:30 PDT
Comment on attachment 314315 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314315&action=review >>> Source/WebCore/page/TextIndicator.cpp:230 >>> + auto& color = node->renderer()->style().color(); >> >> Any need for a renderer null check? Any chance to get here with an anonymous element? > > The is<RenderText>() check above should take care of this, since is<> bails on null. Ah, sure.
Wenson Hsieh
Comment 12 2017-06-30 18:26:03 PDT
Created attachment 314343 [details] Patch for landing
Wenson Hsieh
Comment 13 2017-06-30 18:45:08 PDT
Note You need to log in before you can comment on or make changes to this bug.