752709 - Keyboard overlaps text input fields

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Gabriela [:gaby2300]]

Web page or screen you were on when you saw the issue: 
hotmail.com

Steps to reproduce:
1. Browse to hotmail.com
2. Sign in
3. Notice the keyboard overlapping text input fields

What you expected: 
I expected to be able to enter my username and my password as usual, not having the keyboard overlapping text input fields.

Comment 1

[Gabriela [:gaby2300]]

I found this bug in my Galaxy S2 phone, using Android 2.3.4 and build 20120207

Comment 2

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

dup of 717695?

Comment 3

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

or maybe bug 705106 or bug 717361 or bug 737823 ?

Comment 4

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

Oops.  not bug 705106. probably not 737823.

Comment 5

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

Not quite bug 717361, either.  I think it may be a dup of bug 717695

Comment 6

[Gabriela [:gaby2300]]

(In reply to Naoki Hirata :nhirata from comment #5)
> Not quite bug 717361, either.  I think it may be a dup of bug 717695

Maybe but bug 717695 requires high zoom level, the one I reported doesn't.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Hotmail screenshot

This is what I see when I load hotmail using the latest aurora build on the Galaxy S2. The text input boxes are both visible; when I zoom in and tap on either they both behave normally and as I would expect. Are you seeing something different?

Comment 8

[Gabriela [:gaby2300]]

(In reply to Kartikaya Gupta (:kats) from comment #7)
> Created attachment 623752 [details]
> Hotmail screenshot
> 
> This is what I see when I load hotmail using the latest aurora build on the
> Galaxy S2. The text input boxes are both visible; when I zoom in and tap on
> either they both behave normally and as I would expect. Are you seeing
> something different?

I was going to say it seemed fixed in today's build till I logged in to add this comment and having the issue again. And the same happens when I'm actually. writing. this comment.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

I'm still not able to repro; both the bugzilla login and comment entry work fine for me on the sgs2. there's lots of font inflation problems on bugzilla pages but that doesn't affect text entry particularly. could you post a screenshot/picture of what you're seeing?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Attachment: Screenshot of bugzilla comment entry

Screenshots I took while posting the last entry.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Attachment: Screenshot of bugzilla login

Comment 13

[Gabriela [:gaby2300]]

I see just the same as when I reported the bug, I uploaded a screenshot then and I'm still having the same issue

Comment 14

[Kartikaya Gupta (email:[e-mail])]

I don't recall seeing a screenshot for this problem; could you point me to it? The only attachments on this bug are the ones I uploaded showing what I see on my devices.

Comment 15

[Gabriela [:gaby2300]]

I'm sorry, I'm afraid you are right. I'd really thought I had uploaded my screenshot but I haven't done so. I won't be able to do so till next week but I will do so then.

Comment 16

[Gabriela [:gaby2300]]

Attachment: Keyboard overlaps text input field

Comment 17

[Gabriela [:gaby2300]]

I was able to take a new screenshot in my phone, so I've just attached it.

Comment 18

[Gabriela [:gaby2300]]

It was taken with the latest Aurora build and I'm having exactly the same issue as I'm adding this comment:  the virtual keyboard is overlapping the input text field.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Thanks, that helps a lot. I didn't realize the keyboard took up that much space on the screen. We'll have to do something about that.

Comment 20

[Gabriela [:gaby2300]]

It was does take a lot of space, that's why I filed the bug :)

Comment 21

[Kartikaya Gupta (email:[e-mail])]

CCing ibarlow for ux feedback. Please see screenshot in comment 16; we have limited control over the android keyboard so I'm not sure what the best course of action is here.

Comment 22

[Aaron Train [:aaronmt]]

Definitely not stock keyboard in the screenshot -- should probably go full-screen keyboard in landscape.

Comment 23

[Ian Barlow (:ibarlow)]

We do have plans to implement a way for the header to scroll of the screen, which would certainly buy us a small (but valuable) amount of space here. 

As for using a full screen keyboard in landscape, it would indeed be useful here with a smaller screen / larger keyboard, but we've deliberately not used the full screen keyboard elsewhere to allow for a better awesomescreen / form field navigation experience on phones with larger screens. Do we have any kind of control over using the full screen keyboard on some phones but not all phones?

Comment 24

[Kartikaya Gupta (email:[e-mail])]

(In reply to Ian Barlow (:ibarlow) from comment #23)
> Do we have
> any kind of control over using the full screen keyboard on some phones but
> not all phones?

Yeah, that should doable. We have code that explicitly disables the full-screen view every time the keyboard comes up, so we could make that conditional based on screen size.

(Also cc'ing :cpeterson since this is wandering into IME territory and I'd like to keep him in the loop).

Comment 25

[Ian Barlow (:ibarlow)]

> Yeah, that should doable. We have code that explicitly disables the
> full-screen view every time the keyboard comes up, so we could make that
> conditional based on screen size.

Ok, I would be open to trying this approach then

Comment 26

[Kartikaya Gupta (email:[e-mail])]

Attachment: (1/2) Refactor duplicated code to get display metrics

Comment 27

[Kartikaya Gupta (email:[e-mail])]

Attachment: (2/2) Show fullscreen keyboard when screen height is above a certain size

This seems to work, but doesn't switch from onscreen to fullscreen keyboard on device rotation. I noticed that the awesomebar keyboard entry does do that on my S2, is there a hook for that?

Comment 28

[Chris Peterson [:cpeterson]]

Comment on attachment 626018 [details] [diff] [review]
(1/2) Refactor duplicated code to get display metrics

LGTM

Comment 29

[Chris Peterson [:cpeterson]]

Comment on attachment 626019 [details] [diff] [review]
(2/2) Show fullscreen keyboard when screen height is above a certain size

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

::: mobile/android/base/GeckoInputConnection.java
@@ +770,5 @@
>              outAttrs.imeOptions = EditorInfo.IME_ACTION_SEND;
>          else if (mIMEActionHint != null && mIMEActionHint.length() != 0)
>              outAttrs.actionLabel = mIMEActionHint;
>  
> +        if (GeckoApp.mAppContext.getDisplayMetrics().heightPixels > INLINE_IME_DISPLAY_HEIGHT_THRESHOLD) {

1. metrics height and width are swapped when the device rotates. If you compare min(height, width) > threshold, then you would know the IME flags would be appropriate for either orientation.

I tested your patch on my Galaxy S II (and Note). If I invoke the IME VKB when my S II is in landscape orientation, then your patch handles device orientation correctly.

2. Did you want > or >= threshold?

Comment 30

[Kartikaya Gupta (email:[e-mail])]

(In reply to Chris Peterson (:cpeterson) from comment #29)
> 1. metrics height and width are swapped when the device rotates. If you
> compare min(height, width) > threshold, then you would know the IME flags
> would be appropriate for either orientation.

But doing min(height, width) would mean the full-screen keyboard would be shown even if the height is fine, and the width is narrow. That's different from what I was looking for; on the Galaxy SII the keyboard is shown in fullscreen in landscape on the awesomebar but as soon as you rotate to portrait it goes to the onscreen version.

> I tested your patch on my Galaxy S II (and Note). If I invoke the IME VKB
> when my S II is in landscape orientation, then your patch handles device
> orientation correctly.

It'll handle the initial device orientation, but not orientation changes while the keyboard is up.

> 2. Did you want > or >= threshold?

I thought > made sense, so we get the full-screen keyboard for 480 pixel-wide devices in landscape. However, I was talking with blassey yesterday and he said it would be better to cache the actual keyboard height when it comes up and see how big it is, because some third-party keyboards are massive and take up most of the space even on a tall screen. I'll experiment with that and post an updated patch.

Comment 31

[Chris Peterson [:cpeterson]]

(In reply to Kartikaya Gupta (:kats) from comment #30)
> But doing min(height, width) would mean the full-screen keyboard would be
> shown even if the height is fine, and the width is narrow. That's different
> from what I was looking for; on the Galaxy SII the keyboard is shown in
> fullscreen in landscape on the awesomebar but as soon as you rotate to
> portrait it goes to the onscreen version.

I tested the Galaxy SII without the NO_EXTRACT_UI/NO_FULLSCREEN flags. It seems to work for me:

1. If I open the VKB in portrait orientation, the VKB is the onscreen/half-height version. If I rotate to landscape orientation with the VKB still open, the VKB changes to fullscreen.

2. If I open the VKB in landscape orientation, the VKB is fullscreen. If I rotate to portrait orientation with the VKB still open, the VKB changes to the onscreen/half-height version.


> I thought > made sense, so we get the full-screen keyboard for 480
> pixel-wide devices in landscape. However, I was talking with blassey
> yesterday and he said it would be better to cache the actual keyboard height
> when it comes up and see how big it is, because some third-party keyboards
> are massive and take up most of the space even on a tall screen. I'll
> experiment with that and post an updated patch.

If you are caching the keyboard height, what if the user switches to a VKB with a different height? Checking min(height,width) > 480 sounds good enough to me.

Comment 32

[Kartikaya Gupta (email:[e-mail])]

(In reply to Chris Peterson (:cpeterson) from comment #31)
> I tested the Galaxy SII without the NO_EXTRACT_UI/NO_FULLSCREEN flags. It
> seems to work for me:
> 
> 1. If I open the VKB in portrait orientation, the VKB is the
> onscreen/half-height version. If I rotate to landscape orientation with the
> VKB still open, the VKB changes to fullscreen.
> 
> 2. If I open the VKB in landscape orientation, the VKB is fullscreen. If I
> rotate to portrait orientation with the VKB still open, the VKB changes to
> the onscreen/half-height version.

Ah, I see. I thought you were trying it with my patch and I misunderstood what you were describing. I see this too, if I just take out the flags completely.

> If you are caching the keyboard height, what if the user switches to a VKB
> with a different height?

I would update the cache if the VKB changed heights. However, when trying to implement this I found that on my Galaxy SII in landscape, if the keyboard comes up in on-screen mode it doesn't resize the main activity, and so we have no way of knowing how tall the keyboard actually is. This might be because I have Cyanogenmod installed on this device; I don't see the same behaviour on the Galaxy Nexus. Supposedly this behaviour is controlled by the windowSoftInputMode="adjustResize" attribute in the AndroidManifest, but for some reason it isn't taking effect in landscape mode, which is very odd.

I've googled around and can't seem to find a solution to this problem, so for now I think it's probably not a good idea to rely on adjustResize too heavily. We already do rely on it somewhat to send the ScrollTo:FocusedInput event, but getting the keyboard height would add additional dependencies on it.

Based on this I think I'll stick with the simpler screen-dimension check, and use the min(width, height) like you suggested, since that makes sense given the behaviour. Updated patch coming shortly.

Comment 33

[Kartikaya Gupta (email:[e-mail])]

Attachment: (2/2) Allow showing fullscreen keyboard in landscape on devices with small screens

The 480 is still kind of arbitrary; this will need to bake for a while before uplifting to make sure people aren't running into problems with it.

Comment 34

[Chris Peterson [:cpeterson]]

Comment on attachment 626527 [details] [diff] [review]
(2/2) Allow showing fullscreen keyboard in landscape on devices with small screens

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

LGTM!

Comment 35

[Chris Peterson [:cpeterson]]

Comment on attachment 626527 [details] [diff] [review]
(2/2) Allow showing fullscreen keyboard in landscape on devices with small screens

One nit: your commit message says "less than 480 pixels", but your code checks "> 480 pixels" (i.e. "less than or equal to 480 pixels").

Comment 36

[Chris Peterson [:cpeterson]]

^ i.e. "less than or equal to 480 pixels" in the commit message! :)

Comment 37

[Kartikaya Gupta (email:[e-mail])]

Good catch, thanks :)

Comment 38

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c92e24898667
https://hg.mozilla.org/integration/mozilla-inbound/rev/3236e415c662

Comment 39

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c92e24898667
https://hg.mozilla.org/mozilla-central/rev/3236e415c662

Comment 40

[Gabriela [:gaby2300]]

I´m afraid I still see the bug in landscape mode in today's build, only for the Hotmail username login though, not for the pasword one.

Comment 41

[Chris Peterson [:cpeterson]]

Gabriela, Kats' fix missed last night's build, but it should be in tonight's build (Nightly 15.0a1 2012-05-25).

Comment 42

[Gabriela [:gaby2300]]

Ah, ok Chris, many thanks for telling me this! I'll try again tomorrow then and I'll report my results here.

Comment 43

[Gabriela [:gaby2300]]

Chris, please remember I filed the bug for Aurora (14.0a2), not for Nightly. I'm sorry I keep seeing the bug in today`s build (14.0a2, 2012-05-25) just for the Hotmail username login, not for the password one.

Comment 44

[Kartikaya Gupta (email:[e-mail])]

The fix is currently in Nightly, but I wanted to let it bake there for a few more days. I'll request an uplift to Aurora on monday, and it should show up in an Aurora update shortly after that.

Comment 45

[Gabriela [:gaby2300]]

I'm seeing quite a weird issue while entering my Hotmail password in today's Nightly 15.0a1 2012-05-25.
The cursor sort of switches back an forth. I mean I can see the my password's first character for a few seconds as usual. Then I type the second one, I cannot see the typed character all and the cursor blinks at the left of the line. The same happens with all the characters I type after the first one and when I tap login I get a message about my password not being correct.
Please try and see if you get the same. If not, I'll try to take some screenshots. I know a screencast would be best but I've tried before for another bug, regretfully the file was too big to upload here or its format was not supported.

Comment 46

[Chris Peterson [:cpeterson]]

Gabriela, I suspect you are seeing a variant of bug 755599. If you have any more details (such as the particular Hotmail login URL), can you add them to that bug? It's assigned to me.

Comment 47

[Gabriela [:gaby2300]]

I've done so just now.

Comment 48

[Gabriela [:gaby2300]]

I've done so just now.

Comment 49

[Gabriela [:gaby2300]]

Attachment: VKB overlapps input text field in Facebook

Comment 50

[Gabriela [:gaby2300]]

Sorry, I've added the screenshot before making the comment but still... I'm seeing this bug in Firefox Beta while writing a Facebook comment as you can see in the above comment and screenshot.

Comment 51

[Gabriela [:gaby2300]]

The URL is the following:

https://m.facebook.com/groups/325826697436708?view=permalink&id=433850206634356&src=email_notif

Comment 52

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 626018 [details] [diff] [review]
(1/2) Refactor duplicated code to get display metrics

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: none
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): mobile only; future patches may depend on this
String or UUID changes made by this patch: none

Comment 53

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 626527 [details] [diff] [review]
(2/2) Allow showing fullscreen keyboard in landscape on devices with small screens

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: keyboard may overlap text fields making it hard to see what you're typing
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): mobile-only. low risk; the behaviour should be strictly better than it used to be, even if it doesn't fix it in all cases
String or UUID changes made by this patch: none

Comment 54

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/releases/mozilla-aurora/rev/de5e49beafa7
https://hg.mozilla.org/releases/mozilla-aurora/rev/2bd4d69806b9

Comment 55

[Cristian Nicolae (:xti)]

I cannot reproduce this issue anymore on any branch. 
Closing bug as verified fixed on:

Firefox 15.0a1 (2012-05-31)
Firefox 14.0a2 (2012-05-31)
Firefox 14.0b4 (2012-05-31)

Device: Samsung Galaxy Nexus
OS: Android 4.0.2

Comment 56

[Kartikaya Gupta (email:[e-mail])]

The Galaxy Nexus is probably not the best device to verify this bug on, since this bug was never seen on that device. Please try on the SII with a few non-stock keyboards.

Comment 57

[Gabriela [:gaby2300]]

In the S2 I can verify the fix for Firefox 15.0a1 (2012-05-31), though I have Bug 755599 and/or Bug 759857 so I cannot sign in correctly.
The same for Firefox 14.0a2 (2012-05-31).

Comment 58

[Catalin Suciu [:csuciu]]

Unable to reproduce on:
Nightly 15.0a1 (2012-05-31)
Aurora 14.0a2 (2012-05-31)
Beta 14.0b4 Build 1
Device: Samsung Galaxy SII (2.3.4)

I used Swype, Samsung keypad and Hacker's keyboard for testing. All this are displayed as full screen keyboards in landscape mode.