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

Status: VERIFIED FIXED

(Firefox OS Graveyard :: FxA, defect)

Description

[Jordan de Geus(JordanD)]

Attachment: 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

Comment 1

[Jordan de Geus(JordanD)]

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

Comment 2

[Jordan de Geus(JordanD)]

Attachment: logcat_next.txt

Attaching Logcat file

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

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.

Comment 4

[Jordan de Geus(JordanD)]

Verified Firefox Accounts does not exist on Flame bases v122 (273mb) and v121-2(273mb).

Comment 5

[Jason Smith [:jsmith]]

Kevin - I think we need a blocking triage analysis here.

Comment 6

[KTucker [:KTucker][Inactive 3/4/2016]]

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?

Comment 7

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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.

Comment 9

[No-Jun Park [:njpark]]

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.

Comment 10

[Jason Smith [:jsmith]]

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.

Comment 11

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Sounds good, thanks Jason.

Comment 12

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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.

Comment 13

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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.

Comment 14

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

To clarify a bit further, jgruen suggests we find a better solution for 2.1, but use this approach for 2.0.

Comment 16

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Attachment: 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!

Comment 17

[Fernando Jiménez Moreno [:ferjm]]

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

Comment 18

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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

Comment 19

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8472593 [details] [review]
Github PR 22849

Thanks Jared. LGTM.

Comment 20

[Fernando Jiménez Moreno [:ferjm]]

(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

Comment 21

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Great, thanks Fernando.

Master: https://github.com/mozilla-b2g/gaia/commit/5ec84bcd85ace7879eabe5b36a7f97529bd073dd

Comment 22

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/e0de536a496be733785e00a9cf0b59edb00fcfaf

Comment 24

[robert.sajdok]

I tested it on the latest version of Gaia and It does not work.

Comment 25

[robert.sajdok]

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".

Comment 26

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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.

Comment 27

[Paladin]

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

Comment 28

[Paladin]

Attachment: Verify_video.3gp