706336 - Home and End buttons in Swype don't work

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Keyboards and IME, defect, P3)

Description

[CoJaBo]

1. Type some text in a single-line input, e.g., on Google.com in the search box.
2. Drag from Swype button to the symbols button to open the cursor keyboard.
Try the following-
Put the cursor somewhere in the middle, then press Home. Cursor should move to the beginning, instead, cursor moves one to the left. Same with the End button not moving to the end.
Position the cursor, hit the Select Text button, and use the arrow buttons to navigate. Text should select as it does in other apps.
The Cursor Jump key also does not work, however I am not certain what the correct functionality is (most apps seem to treat it similarly to home/end).

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Alex - Can you confirm this?

Comment 2

[Alex Pakhotin (:alexp)]

Apparently these Skype features don't work well in Fennec. I will investigate, what's going on there.

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Why is this evangelism?

Comment 4

[Alex Pakhotin (:alexp)]

Weird - I didn't even touch those fields.

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

With the tinderbox build: 

Cursor moves with the arrows now with Swiftkey and Swype.  However home does not go to the beginning and end does not go to the end; they go one space back and forward as reported.  Keeping this bug open.

Comment 6

[Chris Peterson [:cpeterson]]

HOME and END are still broken in Swype. I didn't even know Swype had this cursor navigation mode!

Comment 7

[alanomaly]

In latest beta (19), Home and End are still broken. It would be a minor issue if it was possible to scroll left and right with touch in long one-line text input fields, but it's not.

Comment 8

[(inactive) Jim Chen [:jchen] [:darchons]]

Swype sends Home as Ctrl+Left and End as Ctrl+Right, but instead of meta states, it sends the sequences ctrl-down, left-down, left-up, ctrl-up, which are passed directly to Gecko.

However, Gecko seems to only understand meta states, not meta key events, so the ctrl key events are effectively ignored.

One way to fix this is to track the meta states in our KeyListener, and then pass those meta states to Gecko.

Comment 9

[(inactive) Jim Chen [:jchen] [:darchons]]

Taking since I have a patch for it (Last time I talked to cpeterson about this bug, he said he wasn't actively working on it)

Comment 10

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Use meta states from KeyListener (v1)

KeyListener keeps its own meta states, which should be combined with key events on their way to Gecko.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

How safe is the patch to uplift?

Comment 12

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to Mark Finkle (:mfinkle) from comment #11)
> How safe is the patch to uplift?

There's very little risk by itself. It will require uplifting Bug 844290, but that bug is a straightforward refactoring, so it should be relatively safe as well.

So IMO, if we think this is enough of a paper cut, we can uplift to Aurora even at this stage in the release cycle.

Comment 13

[Chris Peterson [:cpeterson]]

Comment on attachment 726726 [details] [diff] [review]
Use meta states from KeyListener (v1)

Review of attachment 726726 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. This patch should be safe to uplift because, AFAIK, few devices are using metastate key combinations today.

::: mobile/android/base/GeckoEvent.java
@@ +202,3 @@
>          mAction = k.getAction();
>          mTime = k.getEventTime();
> +        mMetaState = k.getMetaState() | metaState;

Please add a short comment explaining why the KeyEvent's getMetaState() is incomplete.

Comment 14

[(inactive) Jim Chen [:jchen] [:darchons]]

Addressed review comment.

https://hg.mozilla.org/integration/mozilla-inbound/rev/c920e106fdaf

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c920e106fdaf