Closed Bug 1648944 Opened 4 years ago Closed 3 years ago

document.onselectionchange does not detect changes on input/textarea

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
92 Branch
Tracking Flags:
Tracking Status
firefox92 --- fixed

People

(Reporter: saschanaz, Assigned: saschanaz)

References

(
URL
)

Details

(Keywords: dev-doc-complete)

Attachments

(6 files)

selectionchange.html
(deleted), text/html
Details
Bug 1648944 - Part 1: Split select event flags into each event name r=masayuki
(deleted), text/x-phabricator-request
Details
Bug 1648944 - Part 2: Fire selectionchange at document from text controls r=masayuki
(deleted), text/x-phabricator-request
Details
Bug 1648944 - Part 3: Add tests for flags partially on r=masayuki
(deleted), text/x-phabricator-request
Details
Bug 1648944 - Part 4: Move onselectionchange attribute to GlobalEventHandlers r=masayuki
(deleted), text/x-phabricator-request
Details
Bug 1648944 - Part 5: Add a test for bubbling r=masayuki
(deleted), text/x-phabricator-request
Details
Attached file selectionchange.html (deleted) —
  1. Open the attachment
  2. Click or type anywhere

Firefox: The listener on document listens selection changes for text nodes inside <body>, while listeners on each node listen the selection changes within them
Chrome: The listener on document listens all events, while listeners on each node gets nothing.

Hi Kagami, I wonder what the spec says about the expected behavior here.

Flags: needinfo?(krosylight)

Selection API is the spec.

... the user agent must queue a task to fire an event with the name selectionchange, which does not bubble and is not cancelable, at the document associated with the selection.

So it should always go to document per the spec. This behavior is defined back in 2014 and hasn't changed after that.

Flags: needinfo?(krosylight)
Severity: -- → S3

The relevant discussion: https://github.com/w3c/selection-api/issues/53

There has been no conclusion yet.

Assignee: nobody → krosylight
Status: NEW → ASSIGNED
Attachment #9169402 - Attachment description: Bug 1648944 - Part 1: Split select event flags into each event name r=annevk → Bug 1648944 - Part 1: Split select event flags into each event name

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:saschanaz, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(krosylight)
Flags: needinfo?(krosylight)
No longer depends on: 1713334
Attachment #9169402 - Attachment description: Bug 1648944 - Part 1: Split select event flags into each event name → Bug 1648944 - Part 1: Split select event flags into each event name r=masayuki
Attachment #9169403 - Attachment description: Bug 1648944 - Part 2: Fire selectionchange at document from text controls r=annevk → Bug 1648944 - Part 2: Fire selectionchange at document from text controls r=masayuki
Attachment #9169404 - Attachment description: Bug 1648944 - Part 3: Add tests for flags partially on r=annevk → Bug 1648944 - Part 3: Add tests for flags partially on r=masayuki
Pushed by krosylight@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3f41877ffd14 Part 1: Split select event flags into each event name r=masayuki https://hg.mozilla.org/integration/autoland/rev/a73cfada74cf Part 2: Fire selectionchange at document from text controls r=masayuki,smaug https://hg.mozilla.org/integration/autoland/rev/fb2b9ceb7c69 Part 3: Add tests for flags partially on r=annevk https://hg.mozilla.org/integration/autoland/rev/f464507bef57 Part 4: Move onselectionchange attribute to GlobalEventHandlers r=masayuki,edgar https://hg.mozilla.org/integration/autoland/rev/598789cabb9f Part 5: Add a test for bubbling r=masayuki
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/29717 for changes under testing/web-platform/tests
Upstream PR was closed without merging
Flags: needinfo?(krosylight)
Pushed by krosylight@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bc89ae91a71f Part 1: Split select event flags into each event name r=masayuki https://hg.mozilla.org/integration/autoland/rev/d6e87218e444 Part 2: Fire selectionchange at document from text controls r=masayuki,smaug https://hg.mozilla.org/integration/autoland/rev/e2ae12fa4349 Part 3: Add tests for flags partially on r=annevk https://hg.mozilla.org/integration/autoland/rev/c1b4c369421b Part 4: Move onselectionchange attribute to GlobalEventHandlers r=masayuki,edgar https://hg.mozilla.org/integration/autoland/rev/02e7901e8253 Part 5: Add a test for bubbling r=masayuki
Upstream PR merged by moz-wptsync-bot

I'm documenting this change for FF92, which you will be able to track here: https://github.com/mdn/content/issues/7755

As I understand the spec,

  • the event selectionchanged will be fired on a textarea or input if the selection changes. In this case the event will be fired on the selected element but propagates up to the global event handler GlobalEventHandlers.onselectionchange. It is cancellable and bubblable.
    By selection changes in I mean specifically if you change the caret position (using mouse or by adding new characters) or the number of items selected. But just a focus change is not enough - if you switch back and forth to a text area without changing the caret you won't get the event.
  • selectionchanged will also be fired if you change a selected range outside of a textarea or input. This might mean changing the focus or clicking pretty much anywhere outside the other two text field. In this case though the event is fired on the Document and is not cancelable and bubblable.

Is that about right?

To me that means that the docs changes are:

  1. We already have Document: selectionchange_event but we need to create text_input: selectionchange_eventandinput: selectionchange_event`
  2. We already have a GlobalEventHandlers.onselectionchange handler
    • docs says the captured event is a FocusEvent. Shouldn't this be a selected_change event?
    • The example just uses document.getSelection(). Is that sufficient? Should we be encouraging the user to be looking at the selection and/or event to determine what has been selected?
  3. The changes in this fix also look like they make Firefox compliant with this spec. Do you think it makes sense to add a note to the browser compatibility that this has been fixed in FF92? Something like "Version 92 fixes a bug where selection events were not fired from textarea or input elements?
Flags: needinfo?(krosylight)

(In reply to Hamish Willee from comment #17)

I'm documenting this change for FF92, which you will be able to track here: https://github.com/mdn/content/issues/7755

As I understand the spec,

  • the event selectionchanged will be fired on a textarea or input if the selection changes. In this case the event will be fired on the selected element but propagates up to the global event handler GlobalEventHandlers.onselectionchange. It is cancellable and bubblable.
    By selection changes in I mean specifically if you change the caret position (using mouse or by adding new characters) or the number of items selected. But just a focus change is not enough - if you switch back and forth to a text area without changing the caret you won't get the event.
  • selectionchanged will also be fired if you change a selected range outside of a textarea or input. This might mean changing the focus or clicking pretty much anywhere outside the other two text field. In this case though the event is fired on the Document and is not cancelable and bubblable.

Is that about right?

  1. "selectionchange".
  2. It's never cancelable, but does bubble when it's from textarea or input.
  3. Focusing textarea/input shouldn't fire the event, right.
  4. Clicking generally changes selection and thus should fire the event outside of textarea/input, yes. Focusing doesn't always change selection, though. (Right-clicking a link sets the focus (document.activeElement) but does not change the selection (getSelection().focusNode).)

To me that means that the docs changes are:

  1. We already have Document: selectionchange_event but we need to create text_input: selectionchange_eventandinput: selectionchange_event`
  2. We already have a GlobalEventHandlers.onselectionchange handler
    • docs says the captured event is a FocusEvent. Shouldn't this be a selected_change event?
    • The example just uses document.getSelection(). Is that sufficient? Should we be encouraging the user to be looking at the selection and/or event to determine what has been selected?
  3. The changes in this fix also look like they make Firefox compliant with this spec. Do you think it makes sense to add a note to the browser compatibility that this has been fixed in FF92? Something like "Version 92 fixes a bug where selection events were not fired from textarea or input elements?
  1. FocusEvent is wrong indeed, it should just be Event.
  2. document.getSelection() is indeed not helpful in textarea/input case since getSelection() says nothing about their selection. It should rather use textarea.selectionStart etc.
  3. I'd say it's a feature rather than a bug, since it's a recent change to allow the event from textarea/input: https://github.com/w3c/selection-api/pull/141
Flags: needinfo?(krosylight)

Thanks very much! FYI

Review welcomed.

Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: