Open Bug 921209 Opened 7 years ago Updated 5 years ago

compositionend event fires when it shouldn't

Categories

(Core :: DOM: Events, defect)

24 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: daniel.mcdougall, Unassigned, NeedInfo)

Details

(Keywords: inputmethod)

Attachments

(1 file)

Attached file test.html
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.0 Safari/537.36

Steps to reproduce:

Open a web page that uses composition events and whenever you change anything in the IME it will fire the compositionend event which results in an unnecessary compositionstart event followed by a compositionupdate event then another compositionend event.

The compositionend event should *only* fire when the user has finished a composition.  Firefox appears to be firing the event with every change that occurs in the IME.


Actual results:

In the attached test.html click on the input element and--using an IME (aka software keyboard)--enter any key.  You will see this:

compositionstart:
compositionend: <key you pressed>
compositionstart: <key you pressed>
compositionupdate: <key you pressed>

Next hit the enter key or click somewhere else to end the composition and you'll see this:

compositionend:

The first two lines are what's *most* broken.  The compositionstart followed instantly by compositionend are the bug.  Everything else after that point is correct except for the final compositionend event which should contain the key that was pressed.  I suspect, however, that it does not contain the key because of the first compositionend event that was fired...  Fix that and you'll probably fix the missing text in the final compositionend event.


Expected results:

The correct events can be seen by performing the same test in Chrome (I used Chrome for Android)...  Click on the input element in test.html and then enter any key using the IME (aka software keyboard) and this is what you should see:

compositionstart: <key you pressed>
compositionupdate: <key you pressed>

Then tap the enter key or click somewhere else to end the composition and you'll see this:

compositionend: <key you pressed>
I am having the same problem with mobile Firefox. Desktop Firefox 33 no longer appears to have the issue (I do remember running into it in older versions), but Mobile Firefox 33 on Android does -- when using the on-screen keyboard to build up a word it re-fires compositionstart, compositionupdate, and compositionend for each character typed, whereas it should only fire compositionstart when a new word is started, and compositionend when the word is finished/committed. (This, at least, is the behavior of Chrome Android, and makes it possible to sanely treat mobile typing as IME input.)
I guess that this is platform (or IME) specific bug. I cannot reproduce this bug with Nightly on Ubuntu 14.04 + iBus + Anthy.

I tested in:
https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html

Could you give us the detail of your environment? And If this is really our regression, do you remember which version works well?
Flags: needinfo?(daniel.mcdougall)
(In reply to Marijn Haverbeke from comment #1)
> I am having the same problem with mobile Firefox. Desktop Firefox 33 no
> longer appears to have the issue (I do remember running into it in older
> versions), but Mobile Firefox 33 on Android does -- when using the on-screen
> keyboard to build up a word it re-fires compositionstart, compositionupdate,
> and compositionend for each character typed, whereas it should only fire
> compositionstart when a new word is started, and compositionend when the
> word is finished/committed. (This, at least, is the behavior of Chrome
> Android, and makes it possible to sanely treat mobile typing as IME input.)

As I mentioned in previous comment, such bug should be platform or IME specific bug. Could you file a new bug for Android with your environment information?
Flags: needinfo?(marijnh)
I've opened an Android-specific bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1090977
Flags: needinfo?(marijnh)
This bug might be fixed by a fix of bug 1097238. Could somebody confirm this with the latest Nightly?
You need to log in before you can comment on or make changes to this bug.