821329 - Input widgets don't accept character input with MacOS's build-in handwriting feature

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[margaretdominic]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

I use Mac to write Chinese Character input in Firefox


Actual results:

the chinese character does not appear on Gmail and url


Expected results:

it use to work until you put in the new compose experience

Comment 1

[Matthias Versen [:Matti]]

You write Chinese character with Firefox and it doesn't work if you for example write a new email in gmail ?

>it use to work until you put in the new compose experience
What Do you mean with this ?
New Firefox version or gmail changes or something else ?

Comment 2

[margaretdominic]

In mac, you can use the touchpad with IME to input chinese character with handwriting.  It was working with Google search and gmail, but it does not work now.  It still works with Microsoft Word and Safari.

Comment 3

[Po-chiang Chao [:bobchao]]

Hi, I can confirm this on two different machine with Fx 17 and the nightly today. (on Fx 16.02 it works well.) All text-input widget on UI or webpage are affected.

To reproduce, you need to enable the handwriting feature first, see http://www.personal.psu.edu/ejp10/blogs/gotunicode/2010/05/chinese-trackpad-handwriting-r.html

Steps to reproduce:

1. Open Firefox, click the address bar
2. Press Ctrl-Shift-Space to open the handwriting panel.
3. Write some Chinese character on your touchpad, try simple ones like "十", "一". The candidates will show up on the right column of the handwriting panel.
4.  Touch the top-right corner of the touchpad to select the first candidate.


Except: the character you wrote was entered in the address bar

Result: Nothing happen.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Adding regressionwindow-wanted (known range = Fx 16.02 ~ Fx 17).

People who is interested can identify the range with mozregression

http://mozilla.github.com/mozregression/

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I tried to run |mozregression --good=2012-07-16 --bad=2012-08-27| without success; it looks like the handwriting IME itself failed to all applications at some point. Whoever is trying that should first verify your handwriting IME is still working before every tests.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I've confirmed this and found the regression range:
firefox-2012-07-20-03-05-49-mozilla-central
firefox-2012-07-21-03-05-55-mozilla-central
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3a05d298599e&tochange=045c11dd41a6

Masayuki's patch for bug 775414 is in this range, and seems the most likely source of trouble.

Masayuki, can you take this?

Comment 7

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

Yep, but sounds very strange why the key event change caused this IME bug.

Comment 8

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

This is a simple mistake and probably the symptom is very serious for some users such as some a11y tool users. The patch is very simple and not risky. We should fix this on all branches.

Comment 9

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

Attachment: Patch

I believe that landing this patch is safer than backing-out the patch of bug 775414 (Perhaps, backing-out the patch for bug 775414 needs us to back out some other patches too).

Comment 10

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

We had set charCode outer of the if/else block. However, bug 775414 causes to set charCode only in the if block via InitKeyEvent(). So, InsertText() needs to set the charCode itself if it's called without native key event.

Comment 11

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

https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=7fdb5b2cd7b7

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 700206 [details] [diff] [review]
Patch

Makes sense to me.

Comment 13

[Alex Keybl [:akeybl]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #8)
> This is a simple mistake and probably the symptom is very serious for some
> users such as some a11y tool users. The patch is very simple and not risky.
> We should fix this on all branches.

Yeah, let's get this on branches if this is very low risk, given the possible a11y impact.

Comment 14

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/0831c937f066

I'll request the approvals for the patch after a couple of days.

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0831c937f066

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0831c937f066

Comment 17

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0831c937f066

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Please nominate for uplift to branches.

Comment 19

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

Comment on attachment 700206 [details] [diff] [review]
Patch

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: 

Chinese users cannot use the handwriting mode input. And if some a11y like tools use insertText message for inputting text and the text is only one character, Gecko fails to handle the text input by this bug.

Fix Landed on Version:

Fixed on m-c on 1/11.

Risk to taking this patch (and alternatives if risky): 

The added code isn't performed at inputting text with keyboard since at that time, the |if| block above is performed instead. Only when the input string length is 1 and the character is printable, this patch sets charCode to the keypress event. This is same behavior before landing bug 775414's patch. So, I believe that the risk is low. And if we tried to backout the patch of bug 775414, perhaps, we need to backout some other patches or merge by hand. It's more risky than landing this aptch.

String or UUID changes made by this patch: 

No.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

[Approval Request Comment]
Bug caused by (feature/regressing bug #):

bug 775414
 
User impact if declined: 

See above.

Testing completed (on m-c, etc.): 

Landed on m-c on 1/11.

Risk to taking this patch (and alternatives if risky): 

See above. I believe that landing this patch is safer than backout the regression cause.

String or UUID changes made by this patch: 

No.

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

Approving for branches as taking this is our best option for fixing the regression.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/9fa6f906758a
https://hg.mozilla.org/releases/mozilla-esr17/rev/514f3cfecee4

This is also in my queue to land on Aurora once it reopens.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/28ecd8d04c24

Comment 23

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

Ryan: Thank you for your checking-in!

Comment 24

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

Will the fix be included in next Tb release? Or, do I need to request something?

Comment 25

[Mark Banner (:standard8)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #24)
> Will the fix be included in next Tb release? Or, do I need to request
> something?

Its landed everywhere that's active in core, so it will be included automatically.

Comment 26

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

(In reply to Mark Banner (:standard8) from comment #25)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #24)
> > Will the fix be included in next Tb release? Or, do I need to request
> > something?
> 
> Its landed everywhere that's active in core, so it will be included
> automatically.

Thank you for your quick reply!

Comment 27

[Bogdan Maris, Desktop QA]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130123083802

Verified as fixed on Mac OS X but with keyboard input. Can someone with a touchpad test this on Beta 19.0b3?
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/19.0b3-candidates/build1/mac/en-US/

Comment 28

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Bogdan Maris [QA] from comment #27)
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101
> Firefox/19.0
> Build ID: 20130123083802
> 
> Verified as fixed on Mac OS X but with keyboard input. Can someone with a
> touchpad test this on Beta 19.0b3?
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/19.0b3-candidates/
> build1/mac/en-US/

I can verify the issue is fixed in this build. Thanks, Masayuki and everyone.

Comment 29

[u279076]

Marking verified based on comment 28. Can someone please against Firefox 20 Aurora, 21 Nightly, and 17.0.3esr builds?

The esr builds are here:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central
ftp://ftp.mozilla.org/pub/firefox/nightly/17.0.3esr-candidates/build1/

Comment 30

[u279076]

> The esr builds are here:

Sorry, this should read "The builds are here". Thanks

Comment 31

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #29)
> ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora
> ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central
> ftp://ftp.mozilla.org/pub/firefox/nightly/17.0.3esr-candidates/build1/

Verify fixed on all versions :)

Comment 32

[u279076]

Thank you very much, Tim.