WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
215982
Remove comparePositions and make VisiblePosition improvements
https://bugs.webkit.org/show_bug.cgi?id=215982
Summary
Remove comparePositions and make VisiblePosition improvements
Darin Adler
Reported
2020-08-29 20:46:25 PDT
Remove comparePositions and make VisiblePosition improvements
Attachments
Patch
(135.02 KB, patch)
2020-08-29 21:42 PDT
,
Darin Adler
no flags
Details
Formatted Diff
Diff
Patch
(135.01 KB, patch)
2020-09-01 13:00 PDT
,
Darin Adler
sam
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Darin Adler
Comment 1
2020-08-29 21:42:58 PDT
Comment hidden (obsolete)
Created
attachment 407561
[details]
Patch
Darin Adler
Comment 2
2020-08-29 21:46:08 PDT
One thing not explicitly mentioned in the change log that makes this improvement possible is that all the Position operators now consistently work properly with shadow trees. Before, comparePositions would handle shadow trees correctly, but operators like < and > would not. Now they are all consistently correct in this respect so we can switch to the simpler idiom by using the operators directly. In the few cases where this is not possible, we still don't need a comparePositions function: we can call documentOrder or one of the documentOrder-related functions instead.
Darin Adler
Comment 3
2020-09-01 13:00:41 PDT
Created
attachment 407705
[details]
Patch
Sam Weinig
Comment 4
2020-09-01 15:02:50 PDT
Comment on
attachment 407705
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=407705&action=review
> Source/WebCore/editing/ios/EditorIOS.mm:372 > + VisibleSelection selection; > selection.setBase(visiblePos); > selection.setExtent(visiblePos);
Any reason not to use the VisibleSelection constructor that takes VisiblePositions here? e.g. VisibleSelection selection { visiblePos, visiblePos };? I guess the affinity of selection might be different?
Darin Adler
Comment 5
2020-09-01 15:10:05 PDT
Comment on
attachment 407705
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=407705&action=review
>> Source/WebCore/editing/ios/EditorIOS.mm:372 >> selection.setExtent(visiblePos); > > Any reason not to use the VisibleSelection constructor that takes VisiblePositions here? e.g. VisibleSelection selection { visiblePos, visiblePos };? I guess the affinity of selection might be different?
We almost certainly could and should do that.
Darin Adler
Comment 6
2020-09-01 15:11:25 PDT
Comment on
attachment 407705
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=407705&action=review
>>> Source/WebCore/editing/ios/EditorIOS.mm:372 >>> selection.setExtent(visiblePos); >> >> Any reason not to use the VisibleSelection constructor that takes VisiblePositions here? e.g. VisibleSelection selection { visiblePos, visiblePos };? I guess the affinity of selection might be different? > > We almost certainly could and should do that.
Not only that, there’s one that takes a single VisiblePosition and uses it for both base and extent, and we should use that!
Darin Adler
Comment 7
2020-09-01 18:07:38 PDT
This is passing tests. The "failure" on iOS-wk2 is a progression, probably a test doing better after
r266399
that needs an updated expectation for this platform. Sam, looks like you read the patch but didn’t review yet. Should I upload a new version with the VisibleSelection improvement?
Sam Weinig
Comment 8
2020-09-02 09:37:18 PDT
(In reply to Darin Adler from
comment #7
)
> This is passing tests. The "failure" on iOS-wk2 is a progression, probably a > test doing better after
r266399
that needs an updated expectation for this > platform. > > Sam, looks like you read the patch but didn’t review yet. Should I upload a > new version with the VisibleSelection improvement?
No, sorry, was just not on a computer last night. Finishing off the review now, no need to upload a new one.
Sam Weinig
Comment 9
2020-09-02 09:50:18 PDT
Comment on
attachment 407705
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=407705&action=review
> Source/WebCore/editing/TextAffinity.h:31 > +enum Affinity : bool { Upstream, Downstream };
I think these would read clearer at callsites as an enum class, but I could see arguments either way and this is a clear improvement.
> Source/WebCore/editing/VisibleUnits.cpp:1065 > + if (auto box = visiblePosition.inlineBoxAndOffset().box) {
A thought for the future. Given how often callers of inlineBoxAndOffset() want just the box, is there a worthwhile optimization of having a version that doesn't return the offset? Can any computation be avoided?
Darin Adler
Comment 10
2020-09-02 14:02:05 PDT
Committed
r266487
: <
https://trac.webkit.org/changeset/266487
>
Radar WebKit Bug Importer
Comment 11
2020-09-02 14:03:29 PDT
<
rdar://problem/68231268
>
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