Closed
Bug 1069877
Opened 10 years ago
Closed 10 years ago
[AccessFu] Entering SIM PIN broken, focus gets taken from password entry field
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla35
People
(Reporter: MarcoZ, Assigned: yzen)
References
Details
(Keywords: regression, Whiteboard: [b2ga11y p=1])
Attachments
(2 files, 1 obsolete file)
1.17 KB,
patch
|
eeejay
:
review+
lmandel
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
6.42 MB,
video/mp4
|
Details |
[Blocking Requested - why for this release]: This bug has resurfaced in the 2.2 Master and 2.1 Aurora branches of B2G. Aurora regression range: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=e2a4798c3f91&tochange=e20869e87e23 Good build: 34.0a2 (201409160008) Bad build: 34.0a2 (201409161602) STR: 1. Flash build onto a device that has a SIM card which is PIN protected. 2. Step through the FTU, skipping the SIM PIN entry. 3. Turn on screen reader. 4. Reboot phone via the Power Down menu. 5. Find and double-tap Unlock. 6. SIM PIN dialog comes up. 7. Find the password field and double-tap. Expected: Keyboard comes up, PIN can be entered. Actual: After a second or so, focus gets redirected to the dialog header, and the keyboard disappears. Repeatedly focusing and double-tapping the SIM PIN password field yields the same result. In the good build, the focus goes to the password field, the keyboard comes up and stays up. In the above regression range, bug 1062016 landed, which is an AccessFu bug that is supposed to make editing mode more persistent. But it looks like it might have broken this entry. This PIN entry can also be seen when selecting "Skip", then opening the Phone app and being asked for the SIM PIN again. Gaia revision of good build: 713448b8963cd53c561f4b38640f8c63b655ce33 Gaia revision of bad build: 47939f4c41d0c941e5047e5d1af74a79b7d8e0d5
Assignee | ||
Comment 1•10 years ago
|
||
Same happens in the Firefox Accounts setup email entry.
Assignee | ||
Comment 2•10 years ago
|
||
Another debugging observation: I am getting a lot of DOCUMENT_LOAD_COMPLETE events when focusing on the Entry.
Comment 3•10 years ago
|
||
(In reply to Yura Zenevich [:yzen] from comment #2) > Another debugging observation: I am getting a lot of DOCUMENT_LOAD_COMPLETE > events when focusing on the Entry. it might be useful to check logging A11YLOG=doclifecycle, log visualizer might be helpful as well https://github.com/asurkov/tools/tree/master/logs
Assignee | ||
Comment 4•10 years ago
|
||
Seems to work for me
Reporter | ||
Comment 5•10 years ago
|
||
Any update on this?
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8492300 -
Attachment is obsolete: true
Attachment #8495445 -
Flags: review?(eitan)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → yzenevich
Comment 7•10 years ago
|
||
Comment on attachment 8495445 [details] [diff] [review] 1069877 patch. Review of attachment 8495445 [details] [diff] [review]: ----------------------------------------------------------------- Great!
Attachment #8495445 -
Flags: review?(eitan) → review+
Assignee | ||
Comment 8•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/94aab508db2d
Comment 9•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/94aab508db2d
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Assignee | ||
Comment 10•10 years ago
|
||
Comment on attachment 8495445 [details] [diff] [review] 1069877 patch. Approval Request Comment [Feature/regressing bug #]: improvement [User impact if declined]: B2G screen reader users will not be able to use form entry fields in most interfaces because of the focus jumping. [Describe test coverage new/current, TBPL]: manual testing on b2g-2.1 and b2g-2.2 [Risks and why]: Minimal, added a check for already present screen reader focus position. [String/UUID change made/needed]: none
Attachment #8495445 -
Flags: approval-mozilla-aurora?
Comment 11•10 years ago
|
||
Not a 2.1 blocker since it can just be uplifted to aurora and be in 34.
blocking-b2g: 2.1? → ---
Comment 12•10 years ago
|
||
Comment on attachment 8495445 [details] [diff] [review] 1069877 patch. Aurora+
Attachment #8495445 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 13•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/adf6215f8a6a
Comment 14•9 years ago
|
||
This issue has been verified successfully on Flame 2.1, 2.2. See attachment: 516.MP4 Reproducing rate: 0/5 Step: 1. Flash build onto a device that has a SIM card which is PIN protected. 2. Step through the FTU, skipping the SIM PIN entry. 3. Turn on screen reader. 4. Reboot phone via the Power Down menu. 5. Drag the icon to Unlock. 6. SIM PIN dialog comes up. 7. Find the password field and double-tap. Actual result: Keyboard comes up, PIN can be entered. Flame 2.1 version: Gaia-Rev ccb49abe412c978a4045f0c75abff534372716c4 Gecko-Rev https://hg.mozilla.org/releases/mozilla-2g34_v2_1/rev/18fb67530b22 Build-ID 20141202001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141202.034824 FW-Date Tue Dec 2 03:48:34 EST 2014 Bootloader L1TC00011880 Flame 2.2 version: Gaia-Rev 725685831f5336cf007e36d9a812aad689604695 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/2c9781c3e9b5 Build-ID 20141202040207 Version 37.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141202.072347 FW-Date Tue Dec 2 07:23:58 EST 2014 Bootloader L1TC00011880
Updated•9 years ago
|
Comment 15•9 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•