WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
211148
[iOS] Implement -markedTextRange
https://bugs.webkit.org/show_bug.cgi?id=211148
Summary
[iOS] Implement -markedTextRange
Daniel Bates
Reported
2020-04-28 15:23:09 PDT
Implement -markedTextRange to return the UITextRange for the marked text so that UIKit clients can query for this info.
Attachments
Patch and tests
(24.93 KB, patch)
2020-04-28 16:01 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch and tests
(24.93 KB, patch)
2020-04-29 10:06 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch and tests
(27.27 KB, patch)
2020-04-29 15:09 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
To land
(26.80 KB, patch)
2020-04-30 09:00 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2020-04-28 15:23:35 PDT
<
rdar://problem/57865890
>
Daniel Bates
Comment 2
2020-04-28 16:01:06 PDT
Created
attachment 397896
[details]
Patch and tests
Daniel Bates
Comment 3
2020-04-28 18:10:59 PDT
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.
Daniel Bates
Comment 4
2020-04-29 10:06:49 PDT
Created
attachment 397973
[details]
Patch and tests
Daniel Bates
Comment 5
2020-04-29 15:09:17 PDT
Created
attachment 397998
[details]
Patch and tests
Wenson Hsieh
Comment 6
2020-04-29 16:46:23 PDT
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.
Daniel Bates
Comment 7
2020-04-30 08:57:51 PDT
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.
Daniel Bates
Comment 8
2020-04-30 08:58:07 PDT
Comment on
attachment 397998
[details]
Patch and tests Thanks for the review!
Daniel Bates
Comment 9
2020-04-30 08:59:37 PDT
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.
Daniel Bates
Comment 10
2020-04-30 09:00:54 PDT
Created
attachment 398056
[details]
To land
Daniel Bates
Comment 11
2020-04-30 09:01:17 PDT
Committed
r260952
: <
https://trac.webkit.org/changeset/260952
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug