Closed Bug 1041034 Opened 8 years ago Closed 8 years ago

[B2G][Setting][Firefox Accounts] "Next" button overlaps "Enter your email" text box when the keyboard is present

Categories

(Firefox OS Graveyard :: FxA, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.1 S2 (15aug)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: jdegeus, Assigned: jhirsch)

References

Details

(Whiteboard: [273MB-Flame-Support], [2.0-exploratory])

Attachments

(4 files)

Attached image next_button.png
Description:
When users progress through FTE/FTU, upon reaching the Firefox Account Sign In/Up, users will observe the "Next" button is overlapping the "Enter your email" text box when the keyboard displays after selecting the text field.


Repro Steps:
1) Update a Flame to 20140718000232
2) Settings> Developer> Launch First Time Experience
3) Progress through FTE/FTU to Firefox Accounts
4) Select "Create Account or Sign In"
5) Tap on text field to "Enter your email" and observe the "Next" button is overlapping


Actual:
"Next" button overlaps the "Enter your email" text box when the keyboard is present
Expected:
Page scrolls upwards to allow text box for "Enter your email" to display while "next" button displays

Device: Flame 2.0 (273mb)
Environmental Variables:
Build ID: 20140718000232
Gaia: 34c24749e78496ac1317f4ddb573281c0ef2995e
Gecko: 76309f978531
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro frequency: 
See attached: Logcat and screenshot attached
Logcat_next.txt - Next_button.png
This issue DOES occurs on Flame 2.1 (273mb) and Flame 2.0 (512mb)

Flame 2.1 (273MB)

Environmental Variables:
Device: Flame Master 
Build ID: 20140718040202
Gaia: Unknown
Gecko: e6e8c93a1b6e
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Flame 2.0 (512mb)

Environmental Variables:
Device: Flame 2.0 MOZ ril
Build ID: 20140718000232
Gaia: 34c24749e78496ac1317f4ddb573281c0ef2995e
Gecko: 76309f978531
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual: Users will see the the "Next" button overlapping the email text box

-------------------------------------------------------------------------------------------------

This issue DOES NOT occur on Buri 2.1, Buri 2.0, Open C 2.1, and Open C 2.0

Buri 2.1

Environmental Variables:
Device: Buri Master
BuildID: 20140718040202
Gaia:
Gecko: e6e8c93a1b6e
Version: 33.0a1
Firmware Version: v1.2-device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Buri 2.0

Environmental Variables:
Device: Buri 2.0 MOZ ril
Build ID: 20140718000232
Gaia: 34c24749e78496ac1317f4ddb573281c0ef2995e
Gecko: 76309f978531
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140717040202
Gaia: Unknown
Gecko: a74600665875
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Open C 2.0

Environmental Variables:
Device: Open_C 2.0 MOZ ril
Build ID: 20140717000201
Gaia: aa4f795b81c6147d67c4f06009e166debcf8856e
Gecko: 0ec0b9ac39f0
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

--------------------------------------------------------------------------------

Users are unable to test this on Flame 1.4, Buri 1.4, or Open C 1.4 as Firefox Accounts is not available
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Attached file logcat_next.txt
Attaching Logcat file
Please check the Flame bases since this seems to be a Flame only issue. Also, please make sure to specify the memory of each Flame device tested.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(jdegeus)
Verified Firefox Accounts does not exist on Flame bases v122 (273mb) and v121-2(273mb).
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(jdegeus) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Kevin - I think we need a blocking triage analysis here.
Flags: needinfo?(ktucker)
This is not good for the end user since they will not be able to see what they are typing. Since this in the FTE, I think we should block on this. No-Jun Park, can you weigh in on this please?
Flags: needinfo?(ktucker) → needinfo?(npark)
This looks related to a bug where the fxa system dialog seems too tall, except this is occurring on 2.0, that bug is occurring only in 2.1.

I think we've got a regression in the system window height calculations, I'll bisect and find the bug.

Nominating, since this is bad user experience for 2.0.
blocking-b2g: --- → 2.0?
FYI, bug 1037714 (duplicate of this bug) was nominated for 2.0 but minused at the time because as soon as the user starts typing, next button will not cover the text field anymore. (so the users will be able to type what they are seeing)  But I do agree that it would really improve the appearance if we fix this.
Flags: needinfo?(npark)
We talked about this again in triage. UX mentioned that a lot of our user studies have shown that users won't type into a text field if it's not correctly shown, so there's risk here that users won't decide to setup a FxAccount in the FTE. Given the fact that the FTE has a high quality requirement, we decided to go back to blocking on this.
blocking-b2g: 2.0? → 2.0+
I see a couple of bugs here.

One bug is that the FxA frame is shifted downward by the height of the status bar - looks like it may have been introduced by the recent CSS changes in bug 1013522.

Even with that fixed, though, the input field is partially obscured. I suspect this is related to the fix for bug 994725, but not totally sure yet--basically, when the input gets focus, the keyboard is drawn, but the system is not correctly detecting that the input is partially overlapped by the keyboard.

More tomorrow.
This is a really tough bug, because we're trying to position UI inside an iframe in response to the keyboard popping up over the parent page.

Discussed with jgruen and he suggested just getting rid of the firefox logo, so that the input would never be obscured by the keyboard--going to try that in the PR here.
To clarify a bit further, jgruen suggests we find a better solution for 2.1, but use this approach for 2.0.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Duplicate of this bug: 1050959
Attached file Github PR 22849
Hi Fernando,

Mind taking a look at this 2.0 blocker?

Because FxA lives inside an iframe, it's actually incredibly complicated to position the email input such that it is not blocked when the keyboard is shown. I talked this over with jgruen a while ago, and the idea of just getting rid of the FF logo came up--so that's what I've done in this patch.

Thanks!
Attachment #8472593 - Flags: review?(ferjmoreno)
Comment on attachment 8472593 [details] [review]
Github PR 22849

I'd like to take a different approach if possible.

We can hide the FxA logo when the keyboard is up and show it otherwise. I believe we just need to listen for "focus" and "blur" events on the email input element. You can see an example at [1]

[1] https://github.com/ferjm/tokfox-firefoxos-demo/blob/master/js/ui_manager.js#L37
Attachment #8472593 - Flags: review?(ferjmoreno)
Comment on attachment 8472593 [details] [review]
Github PR 22849

Hey Fernando,

Nice idea! I figured focus/blur would be horribly buggy across iframes, but it seems to work perfectly on my Flame.

I've updated the PR.

By the way, any idea who could help with FxA 2.0 blockers while you're on vacation?

Cheers,

Jared
Attachment #8472593 - Flags: review?(ferjmoreno)
Comment on attachment 8472593 [details] [review]
Github PR 22849

Thanks Jared. LGTM.
Attachment #8472593 - Flags: review?(ferjmoreno) → review+
(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #18)
> By the way, any idea who could help with FxA 2.0 blockers while you're on
> vacation?
> 

You can try with any of the system app peers [1] and you can also ask for feedback to Borja.

[1] https://wiki.mozilla.org/Modules/FirefoxOS#System
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage+][lead-review+][2.0-signoff-need]
QA Whiteboard: [QAnalyst-Triage+][lead-review+][2.0-signoff-need] → [QAnalyst-Triage+][lead-review+][2.0-signoff-need+]
Great, thanks Fernando.

Master: https://github.com/mozilla-b2g/gaia/commit/5ec84bcd85ace7879eabe5b36a7f97529bd073dd
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S2 (15aug)
I tested it on the latest version of Gaia and It does not work.
Besides, In this solution firefox's logo disappears and I think it is not a good idea. Better is that content of it is scroll to up. Similar to the page: "About B2G OS".
Flags: needinfo?(6a68)
Hmm, it's working just fine on Gaia for me. Feel free to open a new bug with a screenshot of the unexpected behavior on your device.
Flags: needinfo?(6a68)
This issue has been verified successfully on Flame 2.0,2.1
Step:
1) Settings> Developer> Launch First Time Experience
2) Progress through FTE/FTU to Select a network.
3) Connection a Wifi.
4) Tap Next button  to Firefox Accounts.
5) Select "Create Account or Sign In"
6) Tap on text field to "Enter your email" and observe the "Next" button.
**Page scrolls upwards to allow text box for "Enter your email" to display while "next" button displays.

See attachment: Verify_video.3gp
Reproducing rate: 0/5
FLame 2.0 build:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141202000201
Version         32.0
Flame 2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141202001201
Version         34.0
Status: RESOLVED → VERIFIED
Attached video Verify_video.3gp
You need to log in before you can comment on or make changes to this bug.