Bug 768572

Summary:

Fedora-packaged version of Firefox not acknowledging alphanumeric keypress events when using Chinese/Japanese/Korean regional settings.

Product:

[Fedora] Fedora

Reporter:

nkeronkow

Component:

ibus-anthy

Assignee:

fujiwara <tfujiwar>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

medium

Docs Contact:

Priority:

unspecified

Version:

CC:

gecko-bugs-nobody, i18n-bugs, jhorak, shawn.p.huang, tagoh, tfujiwar

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2012-03-29 01:59:21 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Attachments:

Description	Flags
testcase	none

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.