998398 - Swiftkey/Kii/Swype input interaction issues in the URL bar

Status: RESOLVED FIXED

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

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

I have a Galaxy S4 running KitKat on stock firmware.

However, I notice that Firefox doesn't seem to play well with third-party keyboards on the search bar. This has happened since I purchased my S4 about one year ago, and even after numerous factory resets and firmware upgrades etc. the problem still persists. This is the main reason why I moved away from Firefox. So I thought one year on, Firefox would be better, but nada.

I've tried the latest release version, the BETA as well as nightlies.

On the default Google and Samsung keyboards it seems to work just fine, but I use third-party keyboards on a daily basis.

On Kii Keyboard and Swype, I get the following issue on the search bar:

When I click on the search bar and start typing,

On Kii Keyboard and Swype: 
- The first word turns out fine. For the second word, it turns out fine as well. However, once I spacebar after the second word, the underline below the second word disappears, but a space is not entered. Therefore, I have to spacebar twice for the space to appear.

On SwiftKey (in current and BETA versions): 
- Words are generally eaten up. So when I type 'SwiftKey' usually something like 'Swky' comes out instead. Only when I type real slowly do my words not get eaten up.

On SwiftKey (nightly build): Behaviour is the same as with Swype and Kii


I don't get this performance issue on other web browsers like Chrome and Dolphin so I thought Firefox is the main culprit here.



Actual results:

See above.


Expected results:

All keystrokes should've been registered, and a space should always occur when spacebar is pressed.

Comment 1

[Aaron Train [:aaronmt]]

Thanks for the report. There are a number of aforementioned issues here concerning each keyboard mentioned. We treat each third party keyboard as grounds for investigation into wether it's something we're doing or a bug in the keyboard.

Comment 2

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

Attachment: Don't reset keyboard to change input type

I think it's time to stop resetting the keyboard during URL entry. The reason we reset the keyboard at all was to change the input type so that the keyboard displays a search icon when the user is entering a search. However, this confuses keyboards a lot. It's becoming a pain to special-case different keyboards and keybaords still break because of it. So I think it's time to get rid of it.

Comment 3

[Wesley Johnston (:wesj)]

Comment on attachment 8410460 [details] [diff] [review]
Don't reset keyboard to change input type

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

I'm fine with this. You might want to run it by UX or mfinkle?

::: mobile/android/base/toolbar/ToolbarEditText.java
@@ +283,5 @@
>          return false;
>      }
>  
>      private void setTextType(TextType textType) {
>          mToolbarTextType = textType;

It doesn't look like anyone uses this even. Can we remove all of it?

@@ +289,2 @@
>          if (mTextTypeListener != null) {
>              mTextTypeListener.onTextTypeChange(this, textType);

Not your bug, but if the go button is going away, we can probably kill this too. :)

Comment 4

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

Attachment: Don't reset keyboard to change input type; r=wesj

For checkin.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/3e0ff6c29303

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3e0ff6c29303