Closed Bug 821329 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: Widget: Cocoa, defect)

17 Branch
x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla21
Tracking Status
firefox17 --- wontfix
firefox18 --- wontfix
firefox19 + verified
firefox20 + verified
firefox21 + verified
firefox-esr10 --- unaffected
firefox-esr17 19+ verified

People

(Reporter: margaretdominic, Assigned: masayuki)

References

Details

(Keywords: intl, regression)

Attachments

(1 file)

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
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 ?
Flags: needinfo?(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.
Flags: needinfo?(margaretdominic)
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
Summary: Chinese character with Mac 10.6 → Input widgets don't accept character input with MacOS's build-in handwriting feature
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/
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.
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?
Yep, but sounds very strange why the key event change caused this IME bug.
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.
Assignee: nobody → masayuki
Blocks: 775414
Status: NEW → ASSIGNED
Keywords: regression
Attached patch PatchSplinter Review
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).
Attachment #700206 - Flags: review?(smichaud)
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 on attachment 700206 [details] [diff] [review]
Patch

Makes sense to me.
Attachment #700206 - Flags: review?(smichaud) → review+
(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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0831c937f066

I'll request the approvals for the patch after a couple of days.
https://hg.mozilla.org/mozilla-central/rev/0831c937f066
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Please nominate for uplift to branches.
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.
Attachment #700206 - Flags: approval-mozilla-esr17?
Attachment #700206 - Flags: approval-mozilla-beta?
Attachment #700206 - Flags: approval-mozilla-aurora?
Attachment #700206 - Flags: approval-mozilla-esr17?
Attachment #700206 - Flags: approval-mozilla-esr17+
Attachment #700206 - Flags: approval-mozilla-beta?
Attachment #700206 - Flags: approval-mozilla-beta+
Attachment #700206 - Flags: approval-mozilla-aurora?
Attachment #700206 - Flags: approval-mozilla-aurora+
Approving for branches as taking this is our best option for fixing the regression.
Ryan: Thank you for your checking-in!
Will the fix be included in next Tb release? Or, do I need to request something?
Flags: needinfo?(mbanner)
(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.
Flags: needinfo?(mbanner)
(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!
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/
(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.
Status: RESOLVED → VERIFIED
> The esr builds are here:

Sorry, this should read "The builds are here". Thanks
Thank you very much, Tim.
You need to log in before you can comment on or make changes to this bug.