Closed
Bug 630576
Opened 14 years ago
Closed 12 years ago
Fennec should send key events to content even without input focus
Categories
(Firefox for Android Graveyard :: Keyboards and IME, defect, P2)
Tracking
(firefox9-, blocking-fennec1.0 -)
RESOLVED
INCOMPLETE
People
(Reporter: wesj, Assigned: cpeterson)
References
()
Details
(Whiteboard: [VKB])
Attachments
(2 files)
536 bytes,
text/html
|
Details | |
3.89 KB,
patch
|
Details | Diff | Splinter Review |
Spinning off from 614202. Key events traveling down the IME code paths aren't firing key events in either parent or child processes. Since we don't get the key events on Android, we should at least look at the IME ones and try our best to determine what was pressed in order to simulate the correct key events.
Comment 1•14 years ago
|
||
Nominating blocking because this might break Google Docs (bug 624163).
tracking-fennec: --- → ?
Updated•14 years ago
|
Assignee: nobody → alexp
tracking-fennec: ? → 2.0+
Updated•14 years ago
|
Comment 3•14 years ago
|
||
I'm trying to understand, what we really want and can do here.
What is the main purpose of this bug? Fix Google Docs? Which other sites require this change?
Characters entered through an IME do not register through keyCode or charCode - this is how Gecko DOM is designed, as far as I understand. Are we going to replace IME events with key press events? This doesn't sound right. What are the other options?
Can you guys share your thoughts on this please?
Thanks.
Comment 4•14 years ago
|
||
Un-nominating as blocking, and moving the Google-Docs-specific discussion back to bug 624163.
tracking-fennec: 2.0+ → ---
Comment 7•14 years ago
|
||
As suggested in a separate thread that was marked duplicate: "oninput" is buggy too and only starts propagating after pressing enter or delete and then works as designed.
Blocks: 636339
Comment 9•14 years ago
|
||
For information it looks like Webkit is firing IME/key events simultaneously.
https://bugs.webkit.org/show_bug.cgi?id=43020
http://joone4u.blogspot.com/2010/07/composition-events-are-handled_27.html
Comment 11•13 years ago
|
||
Updated•13 years ago
|
tracking-firefox9:
--- → ?
Comment 12•13 years ago
|
||
Alex - What's the status of this bug? Why would we want to track this issue? (Martijn)
Comment 13•13 years ago
|
||
It's causing sites like ebay and google autocomplete to not work (see duped bugs).
Comment 14•13 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #12)
> Alex - What's the status of this bug?
The issue was discussed a while ago, but as far as I remember there was no final decision on what to do with it. The other issues, which seemed to be depending on this one were fixed some other way.
Apparently there are still cases where these key events are required, so I guess it needs one more approach. I'll try to unstuck it while looking into my queue of IME bugs.
Reporter | ||
Comment 15•13 years ago
|
||
I saw we recently checked in bug 543789 which also should provide a workaround (compositionupdate events) for websites running into this problem.
Updated•13 years ago
|
Comment 16•13 years ago
|
||
If commitText generates key message by sendKeyEvent(), this may be resolved.
BaseInputConnection.commitText on Android framework uses same idea w/ fullEditor=false.
Updated•13 years ago
|
Whiteboard: [VKB]
Updated•13 years ago
|
Priority: -- → P4
Comment 17•13 years ago
|
||
Some very useful information from Masayuki Nakano:
I guess that you want to send key events for compatibility with some web pages which are handling only key events, right?
If so, we MUST not dispatch keypress event during composition. It has banned by D3E.
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress
The reason is that keypress event indicates one or more characters are inputted by a key. So, if you have dispatched composition events already, it's false.
If web developers wants to catch updating the composition string of IME, they should use compositionupdate event which was implemented on Mozilla9 and later.
https://bugzilla.mozilla.org/show_bug.cgi?id=543789
On the other hand, there are keydown and keyup events. They should be dispatched during composition too (by D3E). However, unfortunately, we're not dispatching them during composition because some internal code is broken by doing that. I think that most handlers are NOT thinking about composition. For example, arrow keys move caret outside of the composing string. This is a major problem which blocks implementing TSF on Windows. If you want to send these events during composition too, you must check all keydown/keyup handlers of our tree. This is in my job queue, but the priority isn't high.
However, there is an exception. If IME commits a character immediately after first keypress, you can dispatch keypress event *instead* of compositionstart, compositionupdate, compositionend and text events. GTK2 widget is dosing so.
http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsGtkIMModule.cpp?mark=403-405,413-413,444-444,1002-1002,1011-1011,1015-1015#369
http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsGtkIMModule.cpp?mark=403-405,413-413,444-444,1002-1002,1011-1011,1015-1015#968
# Calling gtk_im_context_filter_keypress() causes nsGtkIMModule::OnCommitCompositionNative().
There is another event, textinput. This is fired immediately before editing text by keypress, compositionend, d&d, paste, script (e.g., element.value = "foo") and other reasons. D3E recommends that web developers should use this event rather than keypress event. I'll implement it Mozilla11 or 12 or later.
https://bugzilla.mozilla.org/show_bug.cgi?id=622245
FYI: We'll kill support inputting text via untrusted keypress event. You should know this bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=698949
Comment 18•13 years ago
|
||
Some work in progress.
The key-down/up events are generated, but they clash with IME text input events, so there are still issues to be fixed: a single key press needs to be detected better and we have to make sure the IME composition is not screwed up.
Updated•13 years ago
|
tracking-fennec: --- → ?
Updated•13 years ago
|
Assignee: alexp → nobody
Product: Fennec → Fennec Native
Comment 20•13 years ago
|
||
If I understand correctly, a proper fix to this depends on the changes in many other parts of Firefox code.
Comment 21•13 years ago
|
||
(In reply to Alex Pakhotin (:alexp) from comment #20)
> If I understand correctly, a proper fix to this depends on the changes in
> many other parts of Firefox code.
are bugs on file?
Updated•13 years ago
|
tracking-fennec: ? → +
Updated•13 years ago
|
tracking-fennec: + → ?
Priority: P4 → P2
Updated•13 years ago
|
tracking-fennec: ? → 11+
Updated•13 years ago
|
Keywords: fennecnative-releaseblocker
Updated•13 years ago
|
Assignee: nobody → cpeterson
Updated•13 years ago
|
blocking-fennec1.0: --- → +
Updated•13 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•13 years ago
|
Component: General → IME
Assignee | ||
Comment 22•13 years ago
|
||
For comparison, here are test results for different platforms:
* Firefox, Chrome, and Safari on Mac OS X 10.7:
keydown
keypress
input
keyup
* Stock browser on the Galaxy Nexus, Galaxy S2, and Droid Pro:
keydown
keypress
input
keyup
* Chrome on the Galaxy Nexus:
keydown
input
keyup
* Fennec on the Galaxy Nexus:
input
* Fennec on the Samsung S2:
input
input
* Fennec on the Droid Pro:
input
keyup
Assignee | ||
Comment 23•13 years ago
|
||
* And Fennec on the Kindle Fire:
input
Comment 24•13 years ago
|
||
(In reply to Chris Peterson (:cpeterson) from comment #22)
> * Fennec on the Samsung S2:
> input
> input
this is bug 735806
Assignee | ||
Comment 25•13 years ago
|
||
This bug should just address the key events when an input form is not focused (such as gmail keyboard shortcuts)
I split off bug 737658 to address the key down/press/up event sequence when we have input focus.
Summary: Fennec should send key events to content → Fennec should send key events to content even without input focus (such as gmail keyboard shortcuts)
Assignee | ||
Comment 26•13 years ago
|
||
gmail keyboard shortcuts do work correctly. However, Google serves Fennec a basic mobile version of gmail that does not use keyboard shortcuts.
If you install the Phony addon, switch your User-Agent String to "Android (Nexus One)", and reload gmail, you will get a more advanced mobile version of gmail. If then switch your User-Agent String back to "Default", gmail will continue to serve you the advanced mobile version and the J/K keyboard shortcuts will work correctly.
We might want to contact Google and ask them to check for Fennec's (new) User-Agent String and serve us the advanced mobile version of gmail.
I tested with my Droid Pro's HKB.
Comment 27•13 years ago
|
||
really nice to have, but won't hold the release
Updated•13 years ago
|
blocking-fennec1.0: + → soft
Updated•13 years ago
|
blocking-fennec1.0: soft → ---
Updated•13 years ago
|
blocking-fennec1.0: --- → -
Assignee | ||
Comment 28•13 years ago
|
||
Removed some unrelated bugs from the blocking list.
Blocked bug 686360 (JSLinux) is probably the best test case for this bug.
No longer blocks: 693338
Summary: Fennec should send key events to content even without input focus (such as gmail keyboard shortcuts) → Fennec should send key events to content even without input focus
Updated•12 years ago
|
tracking-fennec: 11+ → 16+
Updated•12 years ago
|
tracking-fennec: 16+ → ?
Assignee | ||
Comment 29•12 years ago
|
||
I'm not sure what to do with this bug. It's a vague meta bug from XUL Fennec that has acquired many "could be related to this" dependent bugs over the past 17 months.
I recommended that we retire this meta bug and retest the dependent bugs individually.
Comment 30•12 years ago
|
||
Let's file new bugs for specific cases.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Updated•11 years ago
|
tracking-fennec: ? → ---
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•