1088584 - Delete key won't work in Passcode mode

Status: RESOLVED DUPLICATE of bug 927482

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

Description

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

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.

Comment 1

[Eric Chang [:ericcc] [:echang]]

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

Comment 2

[Tony Chung [:tchung]]

[Blocking Requested - why for this release]:
qawanted for branch checks and if regression or not.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

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)

Comment 4

[Joshua Mitchell (Inactive)]

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?

Comment 5

[bhavana bajaj [:bajaj]]

waiting for stephany's feedback on this before making a blocking call.

Comment 6

[Stephany Wilkes]

Flagging Jacqueline, as she owns Lockscreen.

Comment 7

[Gerry Chang [:gchang]]

Agree with comment #6.

Comment 8

[Jacqueline Savory [:jsavory] UX]

Forwarding ni? to Rob as he is currently covering lockscreen.

Comment 9

[Rob MacDonald [:robmac]]

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.

Comment 10

[Andrew Overholt [:overholt]]

UX says not a blocker and some of us triaging agree so I'm moving to backlog.

Comment 11

[Tiffanie Shakespeare [:tif]]

Is this still an issue? Does UX still need to provide a string?

Comment 12

[Andrew Overholt [:overholt]]

Sorry, I can't verify whether or not it's still a problem.

Comment 13

[Tiffanie Shakespeare [:tif]]

Let's give qa a try then. Thanks

Comment 14

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 15

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Andrew please see comment 14.

Comment 16

[Andrew Overholt [: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.