[Webkit-unassigned] [Bug 93998] New: [chromium] More Android changes to WebFrameImpl::selectRange

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=93998

           Summary: [chromium] More Android changes to
                    WebFrameImpl::selectRange
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebKit API
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: husky at chromium.org
                CC: abarth at webkit.org


Followup to https://bugs.webkit.org/show_bug.cgi?id=92513

WebFrameImpl::selectRange() is still missing some functionality needed on the Android platform:

1. When dragging the selection handles, we shouldn't be able to collapse the selection; it should always be at least one character wide.

2. But we also need a way of explicitly switching to a collapsed selection (that is, an insertion caret rather than a highlighted selection). Currently the Android code uses the convention of calling selectRange with start == end, but this is fragile because the user could do so accidentally (thus failing requirement 1, above).

I think an API change might be useful:

- The editing code distinguishes between base and extent, not just start and end. To get the correct behaviour when the selection is editable, I had to clumsily set the endpoints one at a time.

- The unit tests in WebFrameTest call selectionBounds(), then call selectRange() with the same values, expecting to end up with the same selection range. I think that's a reasonable expectation, but it doesn't actually work in practice! There's an off-by-one pixel error at the lower-right of the selection range; and there may be other reasons why selectionBounds() and selectRange() aren't round-trip robust.

On Android, there are draggable handles around the selection range, and typically only one handle at a time is moved. So maybe the API could be updated to allow one endpoint to be moved, the other remaining fixed. That doesn't directly fix the off-by-one thing, but you would at least be able to say "move the start handle to here, leave the end handle where it is".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.