Closed Bug 1037714 Opened 10 years ago Closed 10 years ago

[B2G][Flame][FTU] Text field is covered on Firefox Accounts screen.

Categories

(Firefox OS Graveyard :: FxA, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED DUPLICATE of bug 1041034
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: ychung, Unassigned)

Details

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

Attachments

(2 files)

Attached image TextFieldCoverd.png
Description:
When the user tap the text field to enter email address on Firefox Accounts screen, the text field is covered when the keyboard pops up.

Repro Steps:
1) Updated Flame to Build ID: 20140711000201
2) Go through FTU until Firefox Accounts screen.
3) Select "Create Account or Sign In".
4) Tap on the "Enter your email" field.
5) Observe the text field when the keyboard pops up.

Actual:
The screen does not adjust, and the text field is covered when the keyboard pops up.

Expected:
The screen adjusts to display the full view of the text field. 

Flame 2.0 (273mb)

Environmental Variables:
Device: Flame 2.0
BuildID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
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: 100%
See attached: screenshot, logcat
This issue also reproduces on Flame 2.0 (512mb), Flame 2.1 (273mb):

Flame 2.0 (512mb)

Environmental Variables:
Device: Flame 2.0
BuildID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 2.1 (273mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

The screen does not adjust, and the text field is covered when the keyboard pops up.
---------------------------------------------------
This issue does NOT reproduces on Buri 2.0, Buri 2.1, Open C 2.0, Open C 2.1:

Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
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

Buri 2.1

Environmental Variables:
Device: Buri Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
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
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
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

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
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

The screen adjusts to display the full view of the text field. 
==========================================================

"Firefox Accounts" page on FTU does NOT exist in v.1.4:

Environmental Variables:
Device: Flame 1.4
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?]
Whiteboard: [2.0-daily-testing] → [2.0-daily-testing] [273MB-Flame-Support] [2.0-exploratory]
nomming for 2.0, pretty serious issue, user might be prevented from signing up for a Firefox account; might be a cert issue? in any case, we don't want any bugs so closely associated with our brand.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Component: Gaia::First Time Experience → Gaia::Keyboard
blocking-b2g: 2.0? → 2.0+
Hi Rudy, please help on this, thank you.
Assignee: nobody → rlu
This is similar to Bug 969230, and for this kind of issues, we should fix it in forms.js of Gecko and in the app itself.

When I tested this case, I found that the keyboard would not block the email input field, and the input field was covered by the [Next] button after the window is resized, so I think maybe we should try to address this issue in FTU first.

Fernando, do you think we could apply a similar fix here as Bug 969230?
Assignee: rlu → nobody
Component: Gaia::Keyboard → Gaia::First Time Experience
Flags: needinfo?(fernando.campo)
Yeah, it looks the same to me. I wouldn't like to have hack like this for each of the screens that needs to scroll, but until gecko gets a fix for all, I'm happy with scrollTop option.

I think can make a quick patch later today, if nobody else is gonna take it.
Flags: needinfo?(fernando.campo)
humm, after checking the code, saw that it's part of system, being called from FTE with IAC (never checked fxAccounts before), so I'm gonna try to ping Borja to learn a little about it before jump in, it might be better with a different approach, as there's no resizing on here.
Flags: needinfo?(borja.bugzilla)
Component: Gaia::First Time Experience → FxA
I just flashed the new build on my Flame, and I can indeed reproduce it. Fernando, if there is any update from your conversation with Borja, it would be great if you could share it with us. Thank you.
If this can be scrollable, we suggest to minus this bug. Mark qawanted.
Keywords: qawanted
(In reply to Kevin Hu [:khu] from comment #8)
> If this can be scrollable, we suggest to minus this bug. Mark qawanted.

I disagree. The FTU UX experience *must* be solid. That's a requirement of our triage criteria.
Keywords: qawanted
what happens here is that once the field is selected, the 'next' button covers the half of the text field.  But as the user starts typing, the screen scrolls up to show the entire text field.  At the moment the ability to sign on is not affected, so not sure whether this should be the 2.0 blocker, unless we decide that the visibility issue is hurting user experience seriously.
I just tried it again, and yes, what :njpark matched to what I experienced. Anyway, I suggest to minus it, and fix it in the next version. But, we still need to keep this bug going.
(In reply to No-Jun Park [:njpark] from comment #10)
> what happens here is that once the field is selected, the 'next' button
> covers the half of the text field.  But as the user starts typing, the
> screen scrolls up to show the entire text field.  At the moment the ability
> to sign on is not affected, so not sure whether this should be the 2.0
> blocker, unless we decide that the visibility issue is hurting user
> experience seriously.

If the problem fixes itself upon typing, then we can unblock it.
blocking-b2g: 2.0+ → ---
(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #12)
> (In reply to No-Jun Park [:njpark] from comment #10)
> > what happens here is that once the field is selected, the 'next' button
> > covers the half of the text field.  But as the user starts typing, the
> > screen scrolls up to show the entire text field.  At the moment the ability
> > to sign on is not affected, so not sure whether this should be the 2.0
> > blocker, unless we decide that the visibility issue is hurting user
> > experience seriously.
> 
> If the problem fixes itself upon typing, then we can unblock it.

Yes that's what happens here, the problem shows once the user selects the text field, and disappears on its own when the user starts typing.  No additional action is needed compared to the nominal scenario.
(In reply to Kevin Hu [:khu] from comment #7)
> I just flashed the new build on my Flame, and I can indeed reproduce it.
> Fernando, if there is any update from your conversation with Borja, it would
> be great if you could share it with us. Thank you.
He agrees on the scroll approach, but proposed an alternative that seems more elegant: we could hide the image on top when the keyboard is showing (while input is focused), and show it again when losing the focus, which would give us space enough to show the input in all screen sizes.

On the other hand, and reading latest comments, specially comment 12, if this is not longer a blocker, I'm afraid I need to focus on other bugs now, so not gonna assign it to myself.
Flags: needinfo?(borja.bugzilla)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: