On-screen panel for candidate bar is in the wrong place when the caret is at the start of a paragraph

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Beth Dakin]

On-screen panel for candidate bar is in the wrong place when the caret is at the start of a paragraph

1. Load any web page with a contenteditable field on a Mac with TouchBar.
2. Click on the editable field so that there is a caret at the beginning but no content yet.
3. Tap and hold on a typing suggestion in the TouchBar.

Expected: There is onscreen UI just belown the blinking caret.
Actual: There is onscreen UI that is arbitrarily far from caret.

This bug only happens when the caret is at the beginning of the paragraph, and it seems to be becuase Range::absoluteTextQuads() returns no quads in this case.

[Beth Dakin]

rdar://problem/29779764

[Beth Dakin]

Created attachment 308602 [details]
Patch

[Tim Horton]

Comment on attachment 308602 [details]
Patch

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

No test? :)

> Source/WebKit2/ChangeLog:13
> +        is because Range::absoluteTextQuads() returns no quads in this case. I think it 
> +        might be correct that absoluteTextQuads() returns no quads in this case, so this 

Should check with Zalan to see if he thinks this is actually correct or a deeper bug.

[Beth Dakin]

Created attachment 308613 [details]
Patch+test

[Tim Horton]

Comment on attachment 308613 [details]
Patch+test

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

> Tools/TestWebKitAPI/Tests/WebKit2Cocoa/WKWebViewCandidateTests.mm:250
> +    EXPECT_EQ(194, candidateRect.origin.y);

Will this change if the font changes? That might be annoying. Could use JS to get the real number, or use Ahem, or ...

[zalan]

(In reply to Tim Horton from comment #3)
> Comment on attachment 308602 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=308602&action=review
> 
> No test? :)
> 
> > Source/WebKit2/ChangeLog:13
> > +        is because Range::absoluteTextQuads() returns no quads in this case. I think it 
> > +        might be correct that absoluteTextQuads() returns no quads in this case, so this 
> 
> Should check with Zalan to see if he thinks this is actually correct or a
> deeper bug.
The editable element is super empty, so there's nothing to return.

[Beth Dakin]

https://trac.webkit.org/changeset/216018/webkit