956959 - User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P2)

Description

[krupa raj[:krupa]]

Attachment: screencast.MOV

Samsung tablet/Android 4.0.4

steps to reproduce:
1. Load https://marketplace.allizom.org on the latest firefox mobile nightly
2. Start the purchase of a paid app
3. Sign in using persona
4. Enter PIN screen loads. Notice that the first block seems to be in focus
6. Enter your PIN

expected behavior:
User can enter the PIN without having to manually tap on the Create PIN section

observed behavior:
User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus

See attached video.

Comment 1

[Aaron Train [:aaronmt]]

Ran into this today. There's a blue focus ring around the field so this is kind of deceiving. On Android, on focus, there is also no blinking cursor which again looks like the field has no focus on tap.

Comment 2

[[e-mail]]

What looks like a focused input isn't actually an input which is why it's a bit deceiving and doesn't really denote focus per se it's more this is the character that will be entered.

This is something that could be changed in Webpay with the move to a single page app. 

Having started to experiment with changing this in the single page app I noticed when you have 4 separate inputs for each character the caret flashing away does feel clunky which is perhaps why this was built this way in the first place. Still I think this should be looked at again with UX to see if we can do this a better way and move to using browser elements rather than doing things that look like browser elements but aren't. I'll raise a separate bug for that.

For now though this bug can be fixed by ensuring the underlying hidden input is focused when the pseudo inputs look like they are ready for input.

Comment 3

[[e-mail]]

I've raised bug 959525 for the UX to be looked at.

Comment 4

[[e-mail]]

Looking into this further looks to me like focus is firing correctly because the keyboard is raised.

If you refresh the tab and go back into webpay it works fine. However starting over makes it stop working again as per the STR. 

I think this is likely to be a platform issue. I will see about creating a standalone test case to get this looked at and raise a new bug for that.

Comment 5

[[e-mail]]

Plan is to re-invent the Pin UI in SPArtacus closely following the Gaia UI to try and workaround this issue. Hence making this depend on bug 837289.

Comment 6

[krupa raj[:krupa]]

Note that this behavior also happens on 1.4 firefoxos phones.

Comment 7

[Andy McKay]

Let's see if we can backport this in from spartacus rather than wait because timelines won't match up with the release of Android.

Comment 8

[[e-mail]]

PR: for webpay to backport the styles from Spartacus.

https://github.com/mozilla/webpay/pull/413

Comment 9

[[e-mail]]

Merged: https://github.com/mozilla/webpay/commit/d59b42c86e6e026dd22aaa3cca6302ad85d63f21

Tested this on 1.3 Keon - and it's not working on first load. Looks like we're going to need to backport more of the pin code from Spartcus.

Comment 10

[[e-mail]]

PR here https://github.com/mozilla/webpay/pull/43 for a new workaround hack.

Comment 11

[[e-mail]]

(In reply to Stuart Colville [:scolville] from comment #10)
> PR here https://github.com/mozilla/webpay/pull/43 for a new workaround hack.

Sorry that should have been: https://github.com/mozilla/webpay/pull/435

Comment 12

[[e-mail]]

https://github.com/mozilla/webpay/commit/3aa236bcee0e5dcabe617bbf30fc0b69de0ca3f8

STQA: 

 * Using both FF Android and FFOS 1.3+
 * Start the payment flow.
 * Check you can enter the pin without focusing first. 

Notes:

 * First load is mostly when this bug was happening so it's worth being in mind the need to start from a fresh load of the entire browser / marketplace to ensure it's fixed.

Comment 13

[[e-mail]]

Trying this on -dev is still not working for me on both b2g and Android. Not sure if that's the difference between remote vs local as it was working great locally. Might be the timeout needs bumping up to be longer to counter a slower load from a remote server.

Back to the drawing board! Will test more next week with Charles to throttle.

Comment 14

[[e-mail]]

Ok I found why this wasn't working for real. The actual focus happens after hiding the progress and showing the form. The problem was that the setTimeout was wrapping the call that does the show/hiding and then the focus not the focus directly. The local test page doesn't do that hence why it worked locally and not as deployed.

Moving the timeout to wrap the underlying focus call looks to have fixed the problem.

I've tested this on b2g 1.3 (keon) and Nightly on FF  android (s3) and it looks to be working on -dev.

STQA still as comment 12

Comment 15

[[e-mail]]

Here's the most recent commit: https://github.com/mozilla/webpay/commit/5302c84ef1a6572299c9245399209d4a71e09c6f

Comment 16

[[e-mail]]

If it's possible to confirm this - then this could be one to cherry-pick for tomorrow's push. The rev needing to be cherry-picked would be 5302c84

Comment 17

[[e-mail]]

Additional QA notes if testing on -dev.

* You'll need to set region to mexico to find :paid apps

Comment 18

[Iulian Timis]

I can still reproduce this issue in https://marketplace.allizom.org/ on FF31 (Android 4.2.1) and MP-stage (FF OS 1.4)
The PIN field is still not focused after the page is loaded and I have to manually tap on it first to get it focused.

Comment 19

[[e-mail]]

This fix isn't on stage yet. You should be able to verify on -dev though.