Closed Bug 1449831 Opened 4 years ago Closed 2 years ago

[Input Events] Implement InputEvent.getTargetRanges()


(Core :: DOM: Events, enhancement, P3)




Tracking Status
firefox75 --- fixed


(Reporter: masayuki, Assigned: masayuki)




(4 files)

InputEvent.getTargetRanges() is important for beforeinput event listeners to check where *will* be modified.
However, we need to support StaticRange first.
Summary: [UI Events] Implement InputEvent.getTargetRanges() → [Input Events] Implement InputEvent.getTargetRanges()
Priority: -- → P3

When I finish my current draft patches for improving mochitest's DnD API and related editor bugs, I'll start to work on this feature.

Assignee: nobody → masayuki

As far as my investigation, we need a lot of risky patches to compute delete ranges which are currently computed at handling deletion. Both Chrome and Safari does not update Selection before dispatching beforeinput event so that InputEvent.getTargetRanges() is the only way to check affected ranges of the input, but on the other hand, the range can guess with InputEvent.inputType value and this API may be used for feature detection of beforeinput event. Therefore, for QA team, we should implement this behind a pref without supporting the deletion ranges for now.

InputEvent.getTargetRanges() can be used only when event type is
beforeinput. So, it may be used for feature detection of beforeinput
event because Chrome does not implement onbeforeinput event handler attribute.
Therefore, this patch makes it behind the pref for beforeinput event.

InputEventOptions should be able to take target ranges for beforeinput
event. However, it requires to include StaticRange.h from nsContentUtils.h
even though most nsContentUtils.h users don't need it. Therefore, this patch
moves it from nsContentUtils.h to new header file.

And makes nsContentUtils::DispatchInputEvent() moves the target ranges
from InputEventOptions to InternalEditorInputEvent.

Depends on D64728

In most cases, InputEvent.getTargetRange() of beforeinput event should
return Selection ranges at dispatching the event.

This patch also handles special cases.

  • composition change - target range should be the previous composition string
    which will be replaced with new composition string.
  • replace text - target range should be the replace range. This is used by
  • drop - target range should be the drop point.

However, the other exception is not handled by this patch. That is, deletions.
The target range(s) should be the range(s) which will be removed. In most
cases, they also matches selection ranges, but may be extended to:

  • surrogate pair boundary
  • grapheme cluster boundary like complex emoji
  • word/line deletion deletion
  • Backspace or Delete from collapsed selection
  • to end of unnecessary whitespaces

For supporting these cases, we need to separate
HTMLEditor::HandleDeleteSelection() and its helper methods and helper class
to range computation part and modifying the DOM tree part. Of course, it
requires big changes and InputEvent.getTargetRanges() may be important for
feature detection of beforeinput event so that we should put off the big
changes to bug 1618457.

Depends on D64729

Pushed by
part 1: Add `InputEvent.getTargetRanges()` r=smaug
part 2: Make `InputEventOptions` be able to take target ranges r=smaug
part 3: Make editor set target ranges of `beforeinput` event if the editor instance is an `HTMLEditor` r=smaug
part 4: Add automated tests for `InputEvent.getTargetRanges()` r=smaug
Depends on: 1619931
Regressions: 1619931
You need to log in before you can comment on or make changes to this bug.