Closed Bug 1088584 Opened 5 years ago Closed 4 years ago

Delete key won't work in Passcode mode

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED DUPLICATE of bug 927482
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: allstars.chh, Unassigned)

References

()

Details

(Whiteboard: [2.1-bug-bash][TPE], ux-tracking)

Gaia-Rev        1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/09fb60a37850
Build-ID        20141023001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880

STR:
1. Enable passcode lock
2. Press Power key to lock the screen
3. press any key randomly
4. press delete key

Actualt result:
Delete key cannot work

Expected Result:
Delete key could delete characters.
Whiteboard: [2.1-FC-bug-bash][TPE]
STR:
1. Enable passcode lock
2. Press Power key to lock the screen
3. press any key randomly until the 4 boxes become RED and before the passcode clears itself.
4. press delete key --> no response

from 00:12
http://youtu.be/pwcYTJJgkvs

Gaia-Rev        0f76e0baac733cca56d0140e954c5f446ebc061f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/7d78ff7d25b6
Build-ID        20141023161200
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141023.194921
FW-Date         Thu Oct 23 19:49:35 EDT 2014
Bootloader      L1TC00011880 - v188
Whiteboard: [2.1-FC-bug-bash][TPE] → [2.1-bug-bash][TPE]
[Blocking Requested - why for this release]:
qawanted for branch checks and if regression or not.
Keywords: qawanted
I've dealt with this issue before and I believe this is a feature which is working as intended. Please read this comment https://bugzilla.mozilla.org/show_bug.cgi?id=927482#c10

Setting tracking flags based on the history of bug 927482 (it's been happening since 1.3)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
NI to Gerry (Lockscreen owner) and Stephany (commenter on bug being referenced) for input on this issue - it does seem like by that comment referenced this current behavior is intended design?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(swilkes)
Flags: needinfo?(jmitchell)
Flags: needinfo?(gchang)
waiting for stephany's feedback on this before making a blocking call.
Flagging Jacqueline, as she owns Lockscreen.
Flags: needinfo?(swilkes) → needinfo?(jsavory)
Agree with comment #6.
Flags: needinfo?(gchang)
Forwarding ni? to Rob as he is currently covering lockscreen.
Flags: needinfo?(jsavory) → needinfo?(rmacdonald)
I would reiterate Steph's comments in https://bugzilla.mozilla.org/show_bug.cgi?id=927482#c10. If we're going to disable a feature, we need to notify the user. This would require a string, which isn't feasible for 2.1.

I will add this to our UX list for 2.2. In the meantime I wouldn't consider this blocking but please keep us informed of any user facing features going forward.
Flags: needinfo?(rmacdonald)
UX says not a blocker and some of us triaging agree so I'm moving to backlog.
blocking-b2g: 2.1? → backlog
Blocks: 1098041
Blocks: 994991
Whiteboard: [2.1-bug-bash][TPE] → [2.1-bug-bash][TPE], ux-most-wanted-nov2014
blocking-b2g: backlog → ---
Is this still an issue? Does UX still need to provide a string?
Flags: needinfo?(overholt)
Whiteboard: [2.1-bug-bash][TPE], ux-most-wanted-nov2014 → [2.1-bug-bash][TPE], ux-tracking
Sorry, I can't verify whether or not it's still a problem.
Flags: needinfo?(overholt)
Let's give qa a try then. Thanks
Keywords: qawanted
There seems to be some misunderstanding on this bug. Please just read bug 927482. This bug should just be duped to bug 927482 because it describes the behavior and the reason on why it does that much clearer.

This bug is asking for a bug. It will be a bug if user can avoid the brute force attack protection by hitting the delete key.

This behavior is still present in current master:

Device: Aries 2.6 Master
BuildID: 20151120133504
Gaia: 94a821b49f4dca3f9321cd80e13c44c4a6696952
Gecko: ec628289d8b4ed310463a0729c3e60a7798dfcac
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
Andrew please see comment 14.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(overholt)
Sorry, I have no knowledge of this bug; I was just involved in triaging potential blockers when this was +'d ~1 year ago :)

I'll just do what Pi Wei recommends in comment 14.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(overholt)
Resolution: --- → DUPLICATE
Duplicate of bug: 927482
You need to log in before you can comment on or make changes to this bug.