-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
REGRESSION (259904@main): @math operation cannot trigger in Quip app
https://bugs.webkit.org/show_bug.cgi?id=259944 rdar://113229516 Reviewed by Ryosuke Niwa. Currently, the `@math` feature in Quip is broken in Safari with Live Range Selection enabled; this is because Quip's JavaScript editor focuses an input element, and expects `selection.rangeCount` to return `1` instead of `0` (the latter of which causes Quip to believe that the user is no longer editing the text field, and therefore leads to Quip dismissing the input field immediately after presenting it). This happens because the `rangeCount` and ranges we expose on `DOMSelection` are different with live range selection in Safari 17, as opposed to both Safari 16 and Chrome (testing against both stable and canary). Whereas we used to expose a single range that was collapsed to the start of the text field, we now expose no ranges at all. To avoid this incompatibility, we restore shipping behavior when the selection is inside of shadow roots, by exposing a selection range that's equivalent to a caret before the shadow host. See also: <w3c/selection-api#166>. Test: fast/forms/shadow-tree-exposure-live-range.html * LayoutTests/fast/forms/shadow-tree-exposure-live-range-expected.txt: * LayoutTests/fast/forms/shadow-tree-exposure-live-range.html: Rebaseline this layout test, such that it verifies that the ranges exposed via the Selection API have the same behavior without live ranges, vs. with live ranges enabled; this also matches the behavior in latest Chrome Canary. * LayoutTests/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt: * LayoutTests/platform/glib/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt: * LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt: Rebaseline a WPT — attempts to change the selection in a UA shadow root in this test now result in the wrong base/anchor nodes and offsets after this patch, rather than the `IndexSizeError`s we currently get. * Source/WebCore/page/DOMSelection.cpp: (WebCore::selectionShadowAncestor): Remove an assertion that's no longer relevant, now that we use this in both live/legacy codepaths. (WebCore::DOMSelection::type const): Keep both `fast/forms/shadow-tree-exposure-live-range.html` and `editing/selection/user-select-js-property.html` passing by adjusting our logic for returning the selection type. Currently, a selection in a shadow root always results in a type of `None`, but this diverges from Chrome (and Safari 16's) behavior, which returns the actual type of the selected range, regardless of whether it's in the shadow tree. (WebCore::DOMSelection::rangeCount const): This is the main fix — return a `rangeCount` of 1 in the case where there are no associated live ranges, if the range is still inside a shadow root. (WebCore::createLiveRangeBeforeShadowHostWithSelection): (WebCore::DOMSelection::getRangeAt): Keep `getRangeAt` consistent with `rangeCount` by returning the caret range at the start of the shadow host in the case where the selected range is in the shadow tree. (WebCore::DOMSelection::shadowAdjustedNode const): (WebCore::DOMSelection::shadowAdjustedOffset const): These methods need to be adjusted as well, to keep the `(base|anchor|focus|extent)(Node|Offset)` properties consistent with the `rangeCount` and selection ranges in the case where the selection is inside of a shadow root. Since the behavior with or without live ranges when the selection is in a shadow tree is now consistent, we no longer require live-range-specific codepaths, so we can simplify this code a bit by just removing the `liveRangeSelectionEnabled()` checks. Canonical link: https://commits.webkit.org/266781@main
- Loading branch information
Showing
6 changed files
with
82 additions
and
69 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters