Implement -markedTextRange to return the UITextRange for the marked text so that UIKit clients can query for this info.
<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>