Closed
Bug 956959
Opened 11 years ago
Closed 11 years ago
User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus
Categories
(Marketplace Graveyard :: Payments/Refunds, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
2014-04-29
People
(Reporter: krupa.mozbugs, Assigned: scolville)
References
Details
Attachments
(1 file)
(deleted),
video/quicktime
|
Details |
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.
Updated•11 years ago
|
Assignee: nobody → scolville
Priority: -- → P3
Comment 1•11 years ago
|
||
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.
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.
I've raised bug 959525 for the UX to be looked at.
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.
Summary: User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus → [blocked] User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus
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.
Reporter | ||
Comment 6•11 years ago
|
||
Note that this behavior also happens on 1.4 firefoxos phones.
Comment 7•11 years ago
|
||
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.
No longer depends on: 837289
PR: for webpay to backport the styles from Spartacus.
https://github.com/mozilla/webpay/pull/413
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.
Summary: [blocked] User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus → User needs to manually tap on the Create/Confirm/Enter PIN section to bring focus
Assignee | ||
Comment 10•11 years ago
|
||
PR here https://github.com/mozilla/webpay/pull/43 for a new workaround hack.
Assignee | ||
Comment 11•11 years ago
|
||
(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
Assignee | ||
Comment 12•11 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•11 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 14•11 years ago
|
||
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
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•11 years ago
|
||
Here's the most recent commit: https://github.com/mozilla/webpay/commit/5302c84ef1a6572299c9245399209d4a71e09c6f
Assignee | ||
Comment 16•11 years ago
|
||
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
Assignee | ||
Comment 17•11 years ago
|
||
Additional QA notes if testing on -dev.
* You'll need to set region to mexico to find :paid apps
Comment 18•11 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 19•11 years ago
|
||
This fix isn't on stage yet. You should be able to verify on -dev though.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•