951774 - [B2G][PUK] "OK" and "Skip buttons appears when entering into "PUK code screen and they covers the screen

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[sarsenyev]

Attachment: IMG_0461.MOV

Description:
When "PUK" code page appears with two suggestions "Skip" or "OK", the "OK" button is unresponsive that makes impossible to see the PUK code field

Prerequisites:
SIM PIM is set on the device

Repro Steps:
1) Updated Buri to BuildID: 20131218004002
2) Go to "SIM Security" and enter incorrect SIM PIN for 3 times
3) Press the "Power" button
4) On the "PIK" screen enter "OK" button

Actual:
"OK" button is doesn't respond

Expected:
"OK" button response and user is able to see the "Enter PUK code" screen menu

Environmental Variables:
Device: Buri 1.3 Aurora MOZ
BuildID: 20131218004002
Gaia: a99b23e73fe5630a877004746d0e7fcec1b6d653
Gecko: 369bdbff6c38
Version: 28.0a2
RIL Version:
Firmware Version: v1.2_20131115

Notes:
Repro frequency: 100%
Link to failed test case:
https://moztrap.mozilla.org/manage/cases/?filter-id=3438
See attached: screenshot

Comment 1

[sarsenyev]

The bug doesn't reproduce on the latest 1.2 COM RIL

Device: Buri 1.2 COM
BuildID: 20131218004002
Gaia: 38338b31b554cdb8c6242b15a966f171a0e7abaa
Gecko: dcffefec8206
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version:v1.2_20131115

Comment 2

[Bruce Huang [:bhuang] (inactive)]

(In reply to sarsenyev from comment #1)
> The bug doesn't reproduce on the latest 1.2 COM RIL
> 
> Device: Buri 1.2 COM
> BuildID: 20131218004002
> Gaia: 38338b31b554cdb8c6242b15a966f171a0e7abaa
> Gecko: dcffefec8206
> Version: 26.0
> RIL Version: 01.02.00.019.102
> Firmware Version:v1.2_20131115

Need some clarification on the 1.2 repro.  Normally if no text is entered, the OK button cannot be pressed.  It looks like the keyboard is pushing the skip/ok buttons up and covering the text field.  If the page is not scrolling properly then that is a different bug on it's own.
So when you say this doesn't reproduce, do you mean the OK button can be pressed or the skip/ok buttons do not cover the text input field?
Thanks.

Comment 3

[sarsenyev]

On 1.2 "OK" and "Skip" buttons don't appear along with the keyboard. The design is a little different, "OK" button is located on the top right corner and "cancel" appears as "X" on the top left side

Comment 4

[gbennett]

Can this bug be duped to bug 923496? If that bug is fixed the OK button will be greyed out and not allow the user to press an unresponsive OK button.

Comment 5

[Jason Smith [:jsmith]]

(In reply to gbennett from comment #4)
> Can this bug be duped to bug 923496? If that bug is fixed the OK button will
> be greyed out and not allow the user to press an unresponsive OK button.

Don't think so. That bug is targeting a 1.2 problem, while this bug targets the problem seen on 1.3. They are different issues.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hi, when the PUK dialog appeared, can you scroll the dialog page or not?

I am not sure this bug is referring to the text field being covered or the OK button being active but unresponsive, or both. If this issue is about text field being covered AND user CANNOT actually manually scroll dialog to show the text field, than this is definitely a bug need to be fixed.

Comment 7

[Jason Smith [:jsmith]]

Adding qawanted here to get a video to help clarify the bug.

Comment 8

[sarsenyev]

Attachment: Video_attachment(OK,Dismiss)

I hope the video will help clarify the bug, so the bug is not about "OK" button, but about text field being covered, user is able to scroll it but he cannot see, what he is typing in the fields

Comment 9

[J Zimbrick]

Regression Window:

Last Working Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131209053402
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: 9f12a9fab080
Version: 28.0a1
Base Image: V1.2_20131115

First Broken Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131210004003
Gaia: 3452fbdb5e1bed0cd27cc6173136537a03e8072f
Gecko: e0c328d99742
Version: 28.0a2
Base Image: V1.2_20131115

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: This needs more investigation. The symptom is almost identical to bug 870646, but in bug 870646 it is reported that the user is able to manually scroll down and see the text field. But from the video in comment 8 it look like the user will lost focus to the text field whenever she/he try to scroll.

We need to ensure the user is able to see the focus field here.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Need a SIM card with the condition (PUK locked) to recreate the problem here.

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Just tried with the a PUK locked SIM. This looks pretty serious as it indeed confirm my suspicion about the video -- the user will lost focus as soon as she/he try to scroll.

That said, no dialog in System nor anywhere is infected by the issue, so I think there is probably something funny happen in the Gaia code of the dialog that prevents keyboard API from scrolling it effectively. So this is not entirely equal to bug 870646.

That said, the user impact is still low IMHO; it is unlikely user could get her/his card PUK locked, and the user would still unlock the SIM with PUK code in the Settings app.

Since the code is live in System app, over to system fe team for triage.

Comment 14

[Preeti Raghunath(:Preeti)]

Gregor,

Can you please check if this belongs in SFE?

Comment 15

[Michael Henretty [:mikehenrty][:mhenretty]]

What is the correct behavior here? Is it just that the input should not lose focus when the users scrolls?

Comment 16

[Michael Henretty [:mikehenrty][:mhenretty]]

It is still unclear what the actual problem is here. There are two things happening:

1.) Skip/Ok buttons obscure the onscreen form. The keyboard API actually does scroll the form in the same way it did before this regression, but since we now have the buttons anchored to the bottom of the screen we don't see the input it is scrolled to.

2.) Manually scrolling the form causes the input to lose focus, which closes the keyboard and generally makes this form a pain to use. Again, this behavior pre-existed the regression, but it wasn't a problem since the buttons didn't obscure the form.

As far as I see, the fix either to make the scroll happen such that the focused input goes above the buttons, or make the input not lose focus when manually scrolling. I think the first is better from a user perspective.

In any case, Tim you mentioned that other forms in the system app do not lose focus when scrolling. Can you give me an example of that, and perhaps I can figure out what the difference is?



Changeset that introduced the buttons:
https://github.com/mozilla-b2g/gaia/commit/dfd6a873b5cd57943f5988c202b03e17262c52cd#diff-61c16a0a0190e95d51031835f62b30d7R622

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Michael Henretty [:mhenretty] from comment #16)
> As far as I see, the fix either to make the scroll happen such that the
> focused input goes above the buttons, or make the input not lose focus when
> manually scrolling. I think the first is better from a user perspective.
> 

I am not sure if it's possible to fix the automatic scroll; I don't know if there is really a definitive fix within our current approach (scroll the page within injected content script). Not lost focus when scroll is probably easier, if we could identify the issue (see below).

> In any case, Tim you mentioned that other forms in the system app do not
> lose focus when scrolling. Can you give me an example of that, and perhaps I
> can figure out what the difference is?

Hum, I might be wrong here. I can confirm inputs in app frames can be scrolled w/o lost focus, but I don't think there is an example on System app. Also, address bar in the browser app (the one and only in-process app) also lost focus when I scroll the top sites below. This is probably a in-proc/oop focus manager issue; maybe loop :smaug or :kanru after the holiday?

Comment 18

[Michael Henretty [:mikehenrty][:mhenretty]]

Smaug or Kanru, could you give us some advice here? It seems that attempting to scroll a form on in-process content causes form elements to lose focus (and therefore close the keyboard). Any idea's on why this might be happening, and what the fix would be?

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

So where is the focus first and where is it moved to?
Could you call preventDefault() on some mousedown event or something?

Comment 20

[Dale Harvey (:daleharvey)]

So 3 issues: 

1. When the user scrolls with an input field focused, they lose focus and the keyboard dissapears, this means they cant scroll to other fields without dismissing the keyboard

    document.querySelector('#simpin-dialog').addEventListener('mousedown', function(e) {
      if (e.target.nodeName !== 'INPUT') {
        e.preventDefault();
      }
    });

fixes it, however it prevents is from disregarding the form, I could put in swipe detection however that seems bad, the form does already have a skip / ok button, so the user wont be stuck on that screen.

2. When a field as focus, the keyboard hides the input until we type something, at which point it scrolls into view, seems fixable, but likely not a block

3. The buttons overlay the bottom input field, this means they are barely usable, simple css fix

Comment 21

[Dale Harvey (:daleharvey)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/15946

I suggest fixing the fact that the input fields are overlayed, this allows the user to enter the fields and complete the form, the keyboard will deactivate as they scroll between inputs, however it will still be possible.

We can file bugs to fix the 1. autoscroll, 2. keyboard dismissed on scroll, I assume we will want to move the system dialogs into an out of process frame?

Comment 22

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 23

[Dale Harvey (:daleharvey)]

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=968175 as a follow up, if we move the system dialogs to now be shown within the system app we wont have the scroll problem that we currently do

This patch fixes it so the form can at least be completed

Comment 24

[Dale Harvey (:daleharvey)]

https://github.com/mozilla-b2g/gaia/commit/4062fea3d44f66d2927af884b7b58e1e9bf36c34

Comment 25

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 4062fea3d44f66d2927af884b7b58e1e9bf36c34 to:
v1.3: ed8e558f6396cd1644d1ff5d9a405894c9486d76

Comment 26

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Dale Harvey (:daleharvey) from comment #23)
> I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=968175 as a follow
> up, if we move the system dialogs to now be shown within the system app we
> wont have the scroll problem that we currently do
> 
> This patch fixes it so the form can at least be completed

There's still a issue when the dialog is in-process right?

Comment 27

[Loli (:lolimartinezcr)]

Tested (02/06/2014) and not working
1.3
Gecko 1fe8aca
Gaia fb35a67

Comment 28

[Loli (:lolimartinezcr)]

For me it isn't working, please could someone review it?

Tested (02/10/2014)
1.3
Gecko b71e4b8
Gaia bg79fe1

Comment 29

[Jason Smith [:jsmith]]

(In reply to Loli from comment #28)
> For me it isn't working, please could someone review it?
> 
> Tested (02/10/2014)
> 1.3
> Gecko b71e4b8
> Gaia bg79fe1

Can open a followup for this?

Comment 30

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #29)
> (In reply to Loli from comment #28)
> > For me it isn't working, please could someone review it?
> > 
> > Tested (02/10/2014)
> > 1.3
> > Gecko b71e4b8
> > Gaia bg79fe1
> 
> Can open a followup for this?

followup bug specifically I mean

Comment 31

[Loli (:lolimartinezcr)]

Tested (02/24/2014) and not working:
1.3
Gecko cf974e3
Gaia 5084b83

Repro Steps:
2) Go to "SIM Security" and enter incorrect SIM PIN for 3 times
3) Press the "Power" button
4) On the "PIK" screen enter "OK" button

Actual:
"OK" button is doesn't respond

Expected:
"OK" button response and user is able to see the "Enter PUK code" screen menu

Comment 32

[Dale Harvey (:daleharvey)]

That sounds like a completely different bug?

But will take it

Comment 33

[Jason Smith [:jsmith]]

Loli - Can you file a followup bug for comment 31?

Comment 34

[Loli (:lolimartinezcr)]

(In reply to Dale Harvey (:daleharvey) from comment #32)
> That sounds like a completely different bug?
> 
> But will take it

You can see this steps also in https://bugzilla.mozilla.org/show_bug.cgi?id=951774#c0

Comment 35

[Loli (:lolimartinezcr)]

Attachment: VID_0001.3gp

Comment 36

[Loli (:lolimartinezcr)]

Tested (02/25/2014) and working
Gecko: 9eaf096
Gaia: dd2e075

Comment 37

[Chris Kreinbring [:CKreinbring]]

Bug 978231 has been entered in regards to the fact that the OK button is not disabled when the textboxes lack the requested data (PUK code and PIN codes).