883930 - Defect - The soft keyboard should not be able to obscure input in dialogs

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: Browser, defect, P2)

Description

[Jim Mathies [:jimm]]

STR:

1) open up the sync config flyout, click set up sync, then click the enter account info link.
2) tap in any of the text inputs

the soft keyboard raises, obscuring the lower edits.

Not sure what UX would like to see here (cc'ing yuan). In some cases like sync the dialog is taller than the content window we have above the keyboard.

Comment 1

[Yuan Wang(:Yuan) – Mobile Firefox Design Lead]

Sync dialog is going to be in flyout panel. So we should be able to scroll the flyout page up to make the text input fields visible.

I don't think right now we have any message dialog that requires text input. Usually message dialog shouldn't require too much typing, since it's about permission, error, etc. Sign in/sign out should not block the users' tasks, so they should be on the side as flyout instead of message dialog. 

If we run into this problem in the future, I would like to reformat the dialog or break it into steps, so that no text fields could be covered by OSK.

Comment 2

[Jim Mathies [:jimm]]

(In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #1)
> Sync dialog is going to be in flyout panel. So we should be able to scroll
> the flyout page up to make the text input fields visible.

Ok great, do we have a bug on converting this over to the flyout filed?

Comment 3

[Yuan Wang(:Yuan) – Mobile Firefox Design Lead]

(In reply to Jim Mathies [:jimm] from comment #2)
> (In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #1)
> > Sync dialog is going to be in flyout panel. So we should be able to scroll
> > the flyout page up to make the text input fields visible.
> 
> Ok great, do we have a bug on converting this over to the flyout filed?

Yes. I believe it's bug 845468. Tim is working on that.

Comment 4

[Allison Naaktgeboren :ally]

is this bug still valud? Tim's bug has been closed.

Comment 5

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

We should check whether the soft keyboard is covering auth prompts and other prompts. I'll do this as part of bug 892575, after bug 886563 is done.

Comment 6

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Attachment: screenshot of issue

Verified that it is possible for the OSK to cover up the input box of a prompt. This will only come up for particularly tall prompts, but the bug exists.

Comment 7

[Rodrigo Silveira [:rsilveira] [:rodms]]

P=2

Comment 8

[Rodrigo Silveira [:rsilveira] [:rodms]]

Attachment: Patch v1

Move dialog up and reduce the size. Tried repositioning based on CAO reported keyboard size but it started getting really hacky and I didn't see much benefit.

Comment 9

[Matt Brubeck (:mbrubeck)]

Comment on attachment 8350738 [details] [diff] [review]
Patch v1

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

r=mbrubeck with some minor nits:

::: browser/metro/base/content/bindings/tabprompts.xml
@@ +14,5 @@
> +    <implementation implements="nsIObserver">
> +      <constructor>
> +        <![CDATA[
> +          Services.obs.addObserver(this, "metro_softkeyboard_shown", false);
> +          Services.obs.addObserver(this, "metro_softkeyboard_hidden", false);

The constructor should also initialize the "osk" attribute based on Services.metro.keyboardVisible.

@@ +21,5 @@
> +
> +      <destructor>
> +        <![CDATA[
> +          Services.obs.removeObserver(this, "metro_softkeyboard_shown", false);
> +          Services.obs.removeObserver(this, "metro_softkeyboard_hidden", false);

Nit: no third argument for removeObserver.

Comment 10

[Rodrigo Silveira [:rsilveira] [:rodms]]

Attachment: Patch v2

#stack already keeps track of keyboard, now this is a CSS only change.

Comment 11

[Rodrigo Silveira [:rsilveira] [:rodms]]

https://hg.mozilla.org/integration/fx-team/rev/49a441e6dace

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/49a441e6dace

Comment 13

[Rodrigo Silveira [:rsilveira] [:rodms]]

Comment on attachment 8350800 [details] [diff] [review]
Patch v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): None
User impact if declined: User can't see input field while on-screen keyboard is up
Testing completed (on m-c, etc.): On m-c since 2013-12-21
Risk to taking this patch (and alternatives if risky): Very low, css only fix.
String or IDL/UUID changes made by this patch: None.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1ff5838f2a32

Comment 15

[u279076]

Kamil, please verify this is fixed in the latest Firefox Nightly and Aurora builds.

Comment 16

[Kamil Jozwiak [:kjozwiak]]

Went through the following issue for verification during iteration #22 testing without any issues. Used the following builds:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-22-00-40-04-mozilla-aurora/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-22-03-05-21-mozilla-central/

I couldn't go through the original issue from comment #0 as the "Sync" portion has been removed from the "Options" flyout. Instead, I used http://dolske.net/mozilla/tests/prompt/sizes.html for verification.

- Ensured that the OSK doesn't overlap the input dialogs when it slides into view
- Ensured that the Navigation App Bar doesn't overlap the input dialogs when sliding in the OSK from the bottom/top of the screen
- Ensured every single type of dialog is moved to the top when the OSK slides into view (alerts, confirms and prompts)
- Ensured that the input dialogs are only resized when the OSK would have overlapped (made sure the other dialogs are moved up but not resized)
- Ensured that you can dismiss all of the dialog boxes without any issues (selecting either "OK" or "Cancel")
- Ensured that the dialogs return to their normal position/size when the OSK is dismissed
- Ensured that the dialog animation/transition to the top is pretty smooth and consistent (made sure there wasn't major jank or other visual issues)
- Ensured that you can dismiss the OSK by pressing "ESC"
- Ensured that everything still works when using a trackpad/mouse
- Went through all of the above test cases in several different snapped variations

Found a few issues while verifying the following fix, will create separate tickets.