Bug 768572 - Fedora-packaged version of Firefox not acknowledging alphanumeric keypress events when using Chinese/Japanese/Korean regional settings.
Summary: Fedora-packaged version of Firefox not acknowledging alphanumeric keypress ev...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ibus-anthy
Version: 16
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: fujiwara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-17 05:27 UTC by nkeronkow
Modified: 2012-03-29 01:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-29 01:59:21 UTC
Type: ---


Attachments (Terms of Use)
testcase (630 bytes, text/html)
2012-03-28 11:25 UTC, Jan Horak
no flags Details

Description nkeronkow 2011-12-17 05:27:23 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0

When using Fedora with any of the aforementioned East Asian localizations, Firefox will not fire a keypress event in response to alphanumeric keys being entered into a <input type="text"> or <textarea> element. It will trigger it for Caps Lock, Tab, F1-F12, backspace, etc. Changing localization settings to basically any other language immediately restores the correct behavior.

I've followed the instructions on http://fedoraproject.org/wiki/Bug_info_Firefox and the final step of installing Firefox (8.0.1, Japanese) directly from Mozilla's site does indeed correct this. The issue is solely with Fedora's package in the repositories.

Reproducible: Always

Steps to Reproduce:
1. Copy paste the following test case into a blank text file and rename it as a .html file

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
     "http://www.w3.org/TR/html4/strict.dtd">
<html>
<script type="text/javascript">
    function installHandler() {
        var tb = document.getElementById("testbox");
        tb.addEventListener( "keypress",
                             function(e) { alert("Received: " + e.which); },
                             true);
    }
    document.addEventListener('DOMContentLoaded', installHandler, true);
</script>
    <head>
        <title>keypress test</title>
    </head>
    <body>
        <p>Just a test.</p><br/>
        <textarea id="testbox"></textarea>
    </body>
</html>

2. Open the file in Firefox and begin typing in the textarea. Note how every time you type a letter or number you get an annoying alert() prompt telling you the keycode you submitted.
2. Under regional settings set the system language to Japanese (for example)
3. Open the file and type in the textarea. You will not receive any alerts for alphanumeric keys.
Actual Results:  
Keypress will not fire for displayable characters under Japanese language settings.

Expected Results:  
It should have been triggered.

Refer here for additional details/context:
https://forums.mozilla.org/addons/viewtopic.php?f=7&t=4388&sid=4348c7afc3cc9f6b3c4366097ee5643e

Comment 1 Jan Horak 2012-03-28 11:25:36 UTC
Created attachment 573309 [details]
testcase

Comment 2 Jan Horak 2012-03-28 11:30:34 UTC
Thanks for your bug report. This seems to be a problem (or maybe feature) of Japanese characters input by using ibus - Anthy. Reassigning to ibus to let them decide how keypress event are handled/reported when using ibus input.

Comment 3 nkeronkow 2012-03-28 22:16:26 UTC
I forgot I'd opened this. Unless it's still of interest to someone, it can probably be closed as the problem seemed to go away around the time the update to Firefox 10 went out. Thanks for your attention, regardless.

To clarify though, the issue wasn't that Firefox wasn't able to register keypress events while typing uncommitted text while using a Japanese IME. I wouldn't have expected that behavior, anyhow. It was that the keypress event wasn't being triggered even with the IME toggled off, and while typing in plain, half-width, Latin, ASCII characters.

Comment 4 fujiwara 2012-03-29 01:59:21 UTC
Probably I think it would be duplicated of bug 769133 and now is fixed.


Note You need to log in before you can comment on or make changes to this bug.