903746 - Missing textinput event

Status: RESOLVED FIXED

(Core :: DOM: Events, enhancement)

Description

[Joe Eagar]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

I'm been coding a WebGL app, and I need a way to access Unicode input events.  Unfortunately, I've not had much luck.  For some reason, it seems Firefox supports the DOM event api for handling IME events, but not the textinput　event.  I don't quite understand the rationale behind this; does the keypress and composition events really cover all possible ways that users can input text?

Also, why does the wikipage for keypress say that event is deprecated in favor of the input event—which is part of the HTML editors API, and thus won't work for WebGL use cases?

Anyway, any help would be appreciated.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=622245#c36

Unless textInput will be added back to some spec, this is invalid.

Comment 2

[Joe Eagar]

I'd still like to know how, exactly, we're supposed to use the input event—which is only relevant for HTML text editors—to catch character input events outside of said editors.

I'll comment on 622245, too.

Comment 3

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 4

[Thomas Wisniewski [:twisniewski]]

This is causing issues for WhatsApp Web, for their chat input when used with the MacOS Emoji picker, as per https://webcompat.com/issues/13503

Basically, they are listening for textInput events (Chrome/WebKit) or compositionend events (Firefox). When they see one they try to call preventDefault on the event to stop the emoji from appearing, and then add their own annotated version of the emoji with document.execCommand("insertHTML") instead.

But of course compositionend events cannot be preventDefaulted, so they end up getting two emoji in their chat input instead (and then a third, because the insertHTML will cause another compositionend to fire, since the first was not preventDefaulted).

It's unclear to me how widespread this sort of code would be, but it's worth investigating to see whether textInput needs to be supported by Firefox.

Comment 5

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 6

[Adam Stevenson [:adamopenweb]]

The original issue with WhatsApp https://webcompat.com/issues/13503 is now fixed by the website so I'm removing the from see also.

We haven't seen new issues in the wild related to this bug for some time now.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Blink's TextEvent interface is here:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/text_event.idl

Definition and declaration are:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/text_event.h
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/text_event.cc

Looks like that it just exposes data attribute, and sets string value except when pasting rich format.

Just random thoughts. If we exposes TextEvent interface and ontextinput attribute to the web, web apps may start to use different path from currently running on Firefox. And it seems that we don't need to support untrusted event for it. If so, just dispatching textInput event might solve the compatibility issue of DraftJS with minimum change.

Ideally, if we can now whether running DraftJS or not in JSActor, dispatching synthesized event from beforeinput event listener might be the safest and smallest fix.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

I don't quite understand why supporting untrusted event affects anything here. In Chrome one can create the event using document.createEvent("textevent").

It feels rather risky to expose just textInput, but not the rest of the setup Chrome has.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #8)

I don't quite understand why supporting untrusted event affects anything here. In Chrome one can create the event using document.createEvent("textevent").

In my idea, if and only if DraftJS wants textInput event and it does not require untrusted one, dispatching fake textInput events on it from chrome script is enough (comparing with implementing it for all web apps).

It feels rather risky to expose just textInput, but not the rest of the setup Chrome has.

If other web apps which do not have any problems with Firefox might be broken if we fully support textInput event because I experienced a lot that web apps use feature detection for not corresponding feature... Therefore, I don't want to implement new but non-standard features only for a few web apps...

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Of course, excepting the case that implementing such feature is the only way to make our users happy.

Comment 11

[James Graham [:jgraham]]

Setting this to be re-triaged for webcompat priority, since we're shipping a draft.js intervention that maps textinput onto beforeinput.

Comment 12

[James Graham [:jgraham]]

https://bugs.chromium.org/p/chromium/issues/detail?id=382814 from 2014 is about removing textinput, and I can't see evidence that's ever going to be fixed. It's hard to tell how many sites actually depend on the event; the Chromium use counter suggests 1.2% of page loads fire this event. Based on the other entries I think that's only if there's actually a listener for the event, but I'm not totally sure.

Comment 13

[Ksenia Berezina [:ksenia]]

Since we're shipping interventions for this breakage to alleviate the impact, let's add a webcompat priority P2.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to James Graham [:jgraham] from comment #12)

It's hard to tell how many sites actually depend on the event; the Chromium use counter suggests 1.2% of page loads fire this event. Based on the other entries I think that's only if there's actually a listener for the event, but I'm not totally sure.

Currently, only the major breakage reports come with Draft.js which should be replaced with Lexical in the future.

Therefore, I'm still thinking that using intervention addon is more reasonable for now than implementing this since dispatching additional events makes the web a little bit slower.

Comment 15

[Thomas Wisniewski [:twisniewski]]

There has been another case found at SantanderBank, which should be fixable with the same draftJS intervention (using beforeinput as a drop-in replacement for textInput).

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 903746 - part 1: Add `TextEvent` r=smaug!,#dom-core

Unfortunately, we returned a CompositionEvent for
Document.createEvent("textevent") because we had a text event which we stopped
exposing to the web and was replaced with eCompositionChange event.
Therefore, this change could potentially have a compatibility risk.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 903746 - part 2: Add `textInput` event and make `EditorBase` dispatch it as a default action of `beforeinput` r=smaug!,#dom-core

Depends on D200120

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

TODO:

• Add WPT for the basic behavior tests
• Add mochitests for DnD and IME composition
• (Although I'm not sure whether we can fix it,) fix todo_isnot in window_composition_text_querycontent.xhtml

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

First opt builds for testers who want to check:

• Linux
• macOS
• Win x64

Comment 20

[Simon Pieters [:zcorpan]]

Spec changes for UIEvents and DOM and corresponding tests have landed:

• https://github.com/w3c/uievents/pull/362
• https://github.com/web-platform-tests/wpt/pull/44472
• https://github.com/whatwg/dom/pull/1254
• https://github.com/web-platform-tests/wpt/pull/44467

Drag and drop is not yet specified, issue:

• https://github.com/w3c/uievents/issues/367

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0ac710612d09
part 1: Add `TextEvent` r=smaug
https://hg.mozilla.org/integration/autoland/rev/c80afc8b7c2a
part 2: Add `textInput` event and make `EditorBase` dispatch it as a default action of `beforeinput` r=smaug

Comment 22

[Cosmin Sabou [:CosminS]]

Backed out for causing non-unified build bustages on nsIPrincipal.h

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=c80afc8b7c2accf1a6574a0830657c0fa533bc7a&selectedTaskRun=EYXDSdrNRnKr82WkNkGsXw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=453857477&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/0df64aacdb659dc872d85fe396508457cdff7be7

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8d59698478cb
part 1: Add `TextEvent` r=smaug
https://hg.mozilla.org/integration/autoland/rev/99fd7832396d
part 2: Add `textInput` event and make `EditorBase` dispatch it as a default action of `beforeinput` r=smaug

Comment 24

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8d59698478cb
https://hg.mozilla.org/mozilla-central/rev/99fd7832396d