Open Bug 1149076 Opened 6 years ago Updated 2 years ago

Event.target is not set correctly in contentEditable

Categories

(Core :: DOM: Events, defect, P5)

37 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: brunoaiss, Unassigned)

References

()

Details

Attachments

(1 file)

When attaching events to the DOM inside a contentEditable, the events thrown (at least for keypress, keyup and keydown) don't have the correct value for the target attribute.

In the example, try typing anything anywhere and see the target value result of the event in the javascript logs.
The Element in the Event.target of the event callback is the Element where contentEditable is set to true (and, by chance, the same Element where the event was attached).

Instead, the element in the Event.target should be the actual innermost element where the event happened, which is where the event bubbling actually started.
Attachment #8585362 - Attachment mime type: text/plain → text/html
I see the same behavior in other browsers too, and given the contenteditable element is the
activeElement, key events should go there.

Why you think this behavior is incorrect?

Perhaps you want to use DOM0 UIEvent's rangeParent + rangeOffset properties?
For example, I want to detect user clicks in a button that is inserted as part of the WYSIWYG such that when the editable button is clicked, it causes certain javascript to run.
Ofc, any javascript the user writes is useless when the data is sent to the server (it is ignored)
QA Whiteboard: [triaged]
Bulk priority change, per :mdaly
Priority: P3 → P5
Duplicate of this bug: 1503532
This is BUG (not a feature) - in all browsers :(

Test case: https://codepen.io/anon/pen/zmVRZL

Reason? Why provide target click information is no problem, but provide proper target information for typing is problem? It should be similar (and similar) - but currently it is not trivial to get that information exactly on which element user type text :(
You need to log in before you can comment on or make changes to this bug.