RESOLVED FIXED215982
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
Patch (135.01 KB, patch)
2020-09-01 13:00 PDT, Darin Adler
sam: review+
Darin Adler
Comment 1 2020-08-29 21:42:58 PDT Comment hidden (obsolete)
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
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
Radar WebKit Bug Importer
Comment 11 2020-09-02 14:03:29 PDT
Note You need to log in before you can comment on or make changes to this bug.