Bug 252281 - REGRESSION (259904@main): window.getSelection() is empty for selection inside textarea
Summary: REGRESSION (259904@main): window.getSelection() is empty for selection inside...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords: InRadar
Depends on: 216325
Blocks:
  Show dependency treegraph
 
Reported: 2023-02-14 18:50 PST by Yury Semikhatsky
Modified: 2023-04-22 12:21 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yury Semikhatsky 2023-02-14 18:50:54 PST
After https://commits.webkit.org/259904@main the following page shows empty selection when selecting some text inside the textarea, it was selected text before the change.


data:text/html,<textarea>Some text</textarea><div>empty</div>
<script>
document.addEventListener('selectionchange', () => {
  let div = document.querySelector("div");
  div.textContent = window.getSelection().toString();
});
</script>
Comment 1 Ryosuke Niwa 2023-02-14 18:54:19 PST
This is expected behavior change from enabling live range selection.
Comment 2 Darin Adler 2023-02-16 00:05:50 PST
This is behavior that matches other web browsers and an intentional change. I’m not sure there’s anything more to say about this. We may want to close this bug unless there is additional insight about the effects of this.
Comment 3 Yury Semikhatsky 2023-02-16 08:59:27 PST
> This is behavior that matches other web browsers and an intentional change.

In Chromium example above does capture actual selection within the text area. In Firefox it doesn't.

With that said, feel free to close this. If this is an intentional change in the behavior, we'll update our test expectations.
Comment 4 Darin Adler 2023-02-17 13:31:47 PST
I think we should work together to decide what the behavior should be. I had no idea that Chromium and Firefox had different behavior.

We should add coverage in Web Platform Tests, write the behavior in some standard, and make sure all the browsers match for interoperability.
Comment 5 Yury Semikhatsky 2023-02-21 15:41:12 PST
To avoid confusion, when talking about updating our tests I meant Playwright test expectations for WebKit (we noticed the change in the behavior with a recent WebKit roll).
Comment 6 Ryosuke Niwa 2023-04-21 16:47:43 PDT
Looks like at least one Apple internal website is broken due to this behavior difference. We may need to restore the old behavior of WebKit...
Comment 7 Ryosuke Niwa 2023-04-22 00:10:20 PDT
Reopening this bug to restore the old behavior.
Comment 8 Ryosuke Niwa 2023-04-22 00:52:16 PDT
<rdar://107622423>
Comment 9 Ryosuke Niwa 2023-04-22 00:52:18 PDT
Pull request: https://github.com/WebKit/WebKit/pull/13063
Comment 10 EWS 2023-04-22 12:21:35 PDT
Committed 263280@main (b6892f51e01e): <https://commits.webkit.org/263280@main>

Reviewed commits have been landed. Closing PR #13063 and removing active labels.