Closed Bug 883930 Opened 7 years ago Closed 6 years ago

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

Categories

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

x86_64
Windows 8.1
defect

Tracking

(firefox28 verified, firefox29 verified)

VERIFIED FIXED
Firefox 29
Tracking Status
firefox28 --- verified
firefox29 --- verified

People

(Reporter: jimm, Assigned: rsilveira)

References

Details

(Whiteboard: [beta28] feature=defect c=tbd u=tbd p=2)

Attachments

(2 files, 1 obsolete file)

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.
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.
(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?
(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.
Blocks: 886563
No longer blocks: metrov1triage
Summary: Inputs in dialogs can be obscured by the soft keyboard → Defect - The soft keyboard should not be able to obscure input in dialogs
Summary: Defect - The soft keyboard should not be able to obscure input in dialogs → Work - The soft keyboard should not be able to obscure input in dialogs
Whiteboard: feature=work
No longer blocks: 886563
Blocks: 892575
is this bug still valud? Tim's bug has been closed.
Whiteboard: feature=work → feature=work [preview-triage]
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.
Whiteboard: feature=work [preview-triage] → feature=work
Attached image 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.
Whiteboard: feature=work → feature=work [preview-triage]
Whiteboard: feature=work [preview-triage] → feature=work [triage]
Summary: Work - The soft keyboard should not be able to obscure input in dialogs → Defect - The soft keyboard should not be able to obscure input in dialogs
Blocks: metrov1backlog
No longer blocks: 892575
Whiteboard: feature=work [triage] → feature=defect c=tbd u=tbd p=0
Whiteboard: feature=defect c=tbd u=tbd p=0 → [triage] feature=defect c=tbd u=tbd p=0
Whiteboard: [triage] feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=0
Whiteboard: feature=defect c=tbd u=tbd p=0 → [release28] feature=defect c=tbd u=tbd p=0
P=2
Assignee: nobody → rsilveira
Status: NEW → ASSIGNED
Blocks: metrov1it21
No longer blocks: metrov1backlog
Priority: -- → P2
QA Contact: jbecerra
Whiteboard: [release28] feature=defect c=tbd u=tbd p=0 → [beta28] feature=defect c=tbd u=tbd p=0
Whiteboard: [beta28] feature=defect c=tbd u=tbd p=0 → [beta28] feature=defect c=tbd u=tbd p=2
Attached patch Patch v1 (obsolete) — Splinter Review
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.
Attachment #8350738 - Flags: review?(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.
Attachment #8350738 - Flags: review?(mbrubeck) → review+
Attached patch Patch v2Splinter Review
#stack already keeps track of keyboard, now this is a CSS only change.
Attachment #8350738 - Attachment is obsolete: true
Attachment #8350800 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/49a441e6dace
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
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.
Attachment #8350800 - Flags: approval-mozilla-aurora?
Attachment #8350800 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Kamil, please verify this is fixed in the latest Firefox Nightly and Aurora builds.
Flags: needinfo?(kamiljoz)
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.
Status: RESOLVED → VERIFIED
Flags: needinfo?(kamiljoz)
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.