Keyboard overlaps text input fields

VERIFIED FIXED in Firefox 14

Status

()

Firefox for Android
General
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: gaby2300, Assigned: kats)

Tracking

(Blocks: 1 bug, {uiwanted})

14 Branch
Firefox 15
ARM
Android
uiwanted
Points:
---

Firefox Tracking Flags

(firefox14 verified, firefox15 verified, blocking-fennec1.0 +)

Details

(Whiteboard: [MTD], URL)

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

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

Updated

6 years ago
Whiteboard: [MTD] → [MTD], DUPEME
Assignee: nobody → bugmail.mozilla
blocking-fennec1.0: --- → ?
dup of 717695?
Oops.  not bug 705106. probably not 737823.
Not quite bug 717361, either.  I think it may be a dup of bug 717695
(Reporter)

Comment 6

6 years ago

(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.
blocking-fennec1.0: ? → +
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?
(Reporter)

Comment 8

6 years ago
(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.

Updated

6 years ago
Duplicate of this bug: 755119
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?
Created attachment 624022 [details]
Screenshot of bugzilla comment entry

Screenshots I took while posting the last entry.
Attachment #624022 - Attachment description: Screenshot of bugzilla login → Screenshot of bugzilla comment entry
Created attachment 624023 [details]
Screenshot of bugzilla login
(Reporter)

Comment 13

6 years ago
I see just the same as when I reported the bug, I uploaded a screenshot then and I'm still having the same issue
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.
(Reporter)

Comment 15

6 years ago
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.
(Reporter)

Comment 16

6 years ago
Created attachment 625232 [details]
Keyboard overlaps text input field
(Reporter)

Comment 17

6 years ago
I was able to take a new screenshot in my phone, so I've just attached it.
(Reporter)

Comment 18

6 years ago
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.
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.
(Reporter)

Comment 20

6 years ago
It was does take a lot of space, that's why I filed the bug :)
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.
Keywords: uiwanted
Definitely not stock keyboard in the screenshot -- should probably go full-screen keyboard in landscape.

Updated

6 years ago
Whiteboard: [MTD], DUPEME → [MTD]
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?
(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).
> 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
Created attachment 626018 [details] [diff] [review]
(1/2) Refactor duplicated code to get display metrics
Attachment #626018 - Flags: review?(cpeterson)
Created attachment 626019 [details] [diff] [review]
(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?
Attachment #626019 - Flags: review?(cpeterson)
Comment on attachment 626018 [details] [diff] [review]
(1/2) Refactor duplicated code to get display metrics

LGTM
Attachment #626018 - Flags: review?(cpeterson) → review+
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?
Attachment #626019 - Flags: review?(cpeterson) → review-
(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.
(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.
(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.
Created attachment 626527 [details] [diff] [review]
(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.
Attachment #626019 - Attachment is obsolete: true
Attachment #626527 - Flags: review?(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!
Attachment #626527 - Flags: review?(cpeterson) → review+
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").
^ i.e. "less than or equal to 480 pixels" in the commit message! :)
Good catch, thanks :)
https://hg.mozilla.org/integration/mozilla-inbound/rev/c92e24898667
https://hg.mozilla.org/integration/mozilla-inbound/rev/3236e415c662
status-firefox14: --- → affected
status-firefox15: --- → fixed
Target Milestone: --- → Firefox 15
https://hg.mozilla.org/mozilla-central/rev/c92e24898667
https://hg.mozilla.org/mozilla-central/rev/3236e415c662
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 40

6 years ago
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.
Gabriela, Kats' fix missed last night's build, but it should be in tonight's build (Nightly 15.0a1 2012-05-25).
(Reporter)

Comment 42

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

Comment 43

6 years ago
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.
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.
(Reporter)

Comment 45

6 years ago
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.
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.
(Reporter)

Comment 47

6 years ago
I've done so just now.
(Reporter)

Comment 48

6 years ago
I've done so just now.
(Reporter)

Comment 49

6 years ago
Created attachment 627498 [details]
VKB overlapps input text field in Facebook
(Reporter)

Comment 50

6 years ago
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 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
Attachment #626018 - Flags: approval-mozilla-aurora?
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
Attachment #626527 - Flags: approval-mozilla-aurora?
Attachment #626018 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #626527 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Blocks: 759856
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
Status: RESOLVED → VERIFIED
status-firefox14: fixed → verified
status-firefox15: fixed → verified
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.
(Reporter)

Comment 57

6 years ago
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).
Status: VERIFIED → RESOLVED
Last Resolved: 6 years ago6 years ago
status-firefox14: verified → affected
status-firefox15: verified → fixed
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.
Status: RESOLVED → VERIFIED
status-firefox14: affected → verified
status-firefox15: fixed → verified
Duplicate of this bug: 737823
You need to log in before you can comment on or make changes to this bug.