Open Bug 676259 Opened 13 years ago Updated 2 years ago

Entering characters with diacritic does not fire a keypress event on Linux

Categories

(Core :: DOM: Events, defect, P5)

All
Linux
defect

Tracking

()

People

(Reporter: exander77, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: When Im entering character with diacritic, I press ´ or ˇ switch and character which I want to have with diacritic. Easily testable in: http://www.quirksmode.org/dom/events/tests/keys.html Actual results: Character appear in the textarea, but keypress event is not fired. This problem only appears on Linux. Expected results: Character appear in the textarea and keypress event is fired. This works fine on Windows.
Addition: This problem appear with Czech diactritic, not tested with others.
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
OS: Windows XP → Linux
Hardware: x86 → x86_64
Addition: The problem is present in Firefox 3.6, 4, 5 and maybe other versions.
Severity: normal → major
Alexander, could you please provide some clear steps to reproduce for this issue-with the exact commands used to trigger the issue? See the following link for general guidelines for steps to reproduce: https://developer.mozilla.org/en/Bug_writing_guidelines
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110915 Firefox/9.0a1 Setting this to resolved until more information is provided.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
Sorry, but there is not mutch to add, when entering diactitic characters into edit field or textarea using two keys ´ or ˇ and character, keypress event is not fired on linux. It is easily reproduceble. Just go on: http://www.quirksmode.org/dom/events/tests/keys.html Select: test text area or test edit field Press: keys ´ or ˇ Press: some a..z character Result: keypress event is not fired, but should be
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
http://img8.imageshack.us/img8/3917/firefoxbug.png See result from quirksmode site. No keypress event fired, when entered character č, using ˇ and c.
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110915 Firefox/9.0a1 Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 1. I added the Czech language via Keyboard-Layouts to my US keyboard in Ubuntu 11.04. 2. I used the Alt key and any letter for entering a diacritic in http://www.quirksmode.org/dom/events/tests/keys.html All keypress events were registered as normal. I was previously confused about the ´ or ˇ switch, but I guess you're using a Czech layout keyboard. Have you tried this issue with a clean profile? http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile If you think there is anything else I can do in order to reproduce, please let me know.
Alt? How exactly you entered the characters? On Czech Keyboard, there is a ´ and ˇ, they are on same key and you create ˇ with use of shift. When you use one of this switches (´ or ˇ), nothing appears, but next inputed character will be changed accordingly a -> á, c -> č. When this character appears, no keypress event is fired, I tested several versions of Firefox on different Linux stations. Maybe it is a problem with inputting characters. Set your keyboard to Czech. Press ´ key. Nothing sould appear on the screen. Press a key. Character á should appear on the screen.
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110915 Firefox/9.0a1 You are using a Czech keyboard, that means that the layout of the keys is different towards my US keyboard. For example, I do not have the ´ and ˇ key you were referring to. instead I have a + and = key. See US and Czech keyboard image search on google. I can reproduce the problem on Ubuntu 11.04. The respective key (the one situated next to backspace, + and = for US keyboard) does not fire keypress events when language is set to Czech-in combination with another letter or not. The key seems to work ok for other browsers. I suppose that is the same behavior on your side too.
Yes, I know, that there is no ´ and ˇ on your "physical" keyboard (we have US layout printed next to our Czech layout, because we use english mutch) and you are right that the label of this key is on US keyboard + and =. Yes, I think you are reproducing it right. When this key is pressed and after it some letter. There is no keypress event fired. This problem does not appear to be in other browser on Linux. And the problem is not present on Windows in any browser including Firefox. It is Firefox on Linux only problem.
GTK views the "´" and "a" key presses as individual keypresses rather than a single á keypress. A GtkIMContext converts these into a single commit event. Because the text committed doesn't match the key pressed, the text is dispatched as a text event instead of a keypress. http://hg.mozilla.org/mozilla-central/annotate/5319b0100025/widget/src/gtk2/nsGtkIMModule.cpp#l1001 This seems reasonable behaviour to me, but interesting to hear that the NT port dispatches a keypress. I wonder whether there is a spec recommending a specific behaviour here. I guess the text event dispatched differs from the textinput event for which this test page is listening. I don't know the details there.
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110915 Firefox/9.0a1 Thank you for the feedback. As the behavior is inconsistent with Windows and other browsers', I'll set it to New for the moment, until more feedback can be provided. STR: 1) Install and select the Czech language from the menu bar. 2) Load the page provided in the URL. 3) In the text area, press the + or = key (US keyboard). No key press event is fired. A key press event is fired when other languages are selected.
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86_64 → All
Version: 5 Branch → 9 Branch
Version: 9 Branch → Trunk
(In reply to Virgil Dicu [QA] from comment #12) > STR: > 1) Install and select the Czech language from the menu bar. > 2) Load the page provided in the URL. > 3) In the text area, press the + or = key (US keyboard). > > No key press event is fired. AIUI, that part is expected. 4) press the 'a' key. Still no keypress event. Reporter expects and NT port generates a keypress event with 'á'
(In reply to Karl Tomlinson (:karlt) from comment #13) > (In reply to Virgil Dicu [QA] from comment #12) > > STR: > > 1) Install and select the Czech language from the menu bar. > > 2) Load the page provided in the URL. > > 3) In the text area, press the + or = key (US keyboard). > > > > No key press event is fired. > > AIUI, that part is expected. > > 4) press the 'a' key. > > Still no keypress event. > > Reporter expects and NT port generates a keypress event with 'á' Exactly.
GTK and Mac users IME for inputting dead key. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-DeadKeys Windows doesn't use IME for dead key processing. When IME is composing, we must not dispatch keypress event. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress Now, we're going to support compositionupdate event in Fx9 and later. Web pages should use them too instead of using only keypress event. I'm not sure whether we should emulate IME events on *Windows*, however, we shouldn't change behavior of Linux and Mac if they work as D3E spec. So, the summary is invalid according to D3E.
> GTK and Mac users IME for inputting dead key. GTK and Mac use IME, I meant.
The problem still exists in firefox 21 (french keyboard: ^ + o -> ô). We could use composition events, but it's another firefox special case to handle: keypress events are correctly sent on firefox for windows and chromium for linux. We already have to deal with keypress events wrongly triggered on non-char keys (tabs, arrows, etc).
It happens still in Firefox 26, at least on Ubuntu (12.04) If you change focus to another window, click and return to the windows, then it works.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.