Bug 211148

<rdar://problem/57865890>

Created attachment 397896 [details]
Patch and tests

Comment on attachment 397896 [details]
Patch and tests

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

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4126
> +        return markedTextRects.isEmpty() ? CGRectZero : markedTextRects.first().rect();

CGRectZero to match current behavior. Maybe can return RectNull...need to check.

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4136
> +        return markedTextRects.isEmpty() ? CGRectZero : markedTextRects.last().rect();

CGRectZero to match current behavior. Maybe can return RectNull...need to check.

Created attachment 397973 [details]
Patch and tests

Created attachment 397998 [details]
Patch and tests

Comment on attachment 397998 [details]
Patch and tests

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

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4493
> +    if (bool isInHorizontalWritingMode = caretRect.width() < caretRect.height())

I find this variable name a bit misleading, since this isn’t (technically) about writing mode, but the geometry of the caret (i.e. keeping the caret “skinny” in either axis).

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4510
> +    if (bool isInHorizontalWritingMode = caretRect.width() < caretRect.height()) {

Ditto.

Comment on attachment 397998 [details]
Patch and tests

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

>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4493
>> +    if (bool isInHorizontalWritingMode = caretRect.width() < caretRect.height())
> 
> I find this variable name a bit misleading, since this isn’t (technically) about writing mode, but the geometry of the caret (i.e. keeping the caret “skinny” in either axis).

Will rename to isHorizontalCaret

FYI I was trying to explain the origin of the "horizontal" or "vertical" caret. It originates from the writing mode! This code will 100% have to change if caret geometry radically changed (e.g. caret becomes a square or something more exotic) and when the geometry becomes ambiguous then the only truth we have is the writing mode. As I write this it dawns on me that there is no point to explain this.... it's obvious + this code is "theme" code.

Comment on attachment 397998 [details]
Patch and tests

Thanks for the review!

Comment on attachment 397998 [details]
Patch and tests

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

>>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4493
>>> +    if (bool isInHorizontalWritingMode = caretRect.width() < caretRect.height())
>> 
>> I find this variable name a bit misleading, since this isn’t (technically) about writing mode, but the geometry of the caret (i.e. keeping the caret “skinny” in either axis).
> 
> Will rename to isHorizontalCaret
> 
> FYI I was trying to explain the origin of the "horizontal" or "vertical" caret. It originates from the writing mode! This code will 100% have to change if caret geometry radically changed (e.g. caret becomes a square or something more exotic) and when the geometry becomes ambiguous then the only truth we have is the writing mode. As I write this it dawns on me that there is no point to explain this.... it's obvious + this code is "theme" code.

Just for me (because I'm removing this comment before landing):

    // In theory, the writing mode should be sent over with the editor state because
    // the caret could take **any** shape. In practice, the caret is always rectangular
    // and displayed between characters.

Created attachment 398056 [details]
To land

Committed r260952: <https://trac.webkit.org/changeset/260952>