Lockscreen slider not cleared when unlocking for Camera

RESOLVED FIXED in 2.2 S3 (9jan)

Status

defect
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: gerard-majax, Assigned: gweng)

Tracking

({regression})

unspecified
2.2 S3 (9jan)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Reproduced on Flame master.

STR:
 0. Unlock by pushing slider to Camera
 1. Once Camera is displayed, press power to lock
 2. Press power to unlock

Expected:
 Slider should be as clean as on boot.

Actual:
 Drawing of the user sliding the slider to the Camera side is still present. Confere attachment.
Posted file Patch
I remembered the original handle no activate to left is I want to move the logic of activating Camera from Lockscreen to state, and then it should use another state rather than direct to the same unlocking state. But since now the logic is still not moved and this is a regression, and we now try to refactor the state design, patch this with the way.
Attachment #8518196 - Flags: review?(timdream)
(Assignee)

Updated

5 years ago
Assignee: nobody → gweng
The patch only encounter one intermittent failure:

https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=4748f9505489

So I would land this patch.
(Reporter)

Comment 4

5 years ago
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #3)
> master:
> https://github.com/mozilla-b2g/gaia/commit/
> a36f52d2398e7b97a32b52dbe258a0a65a1ba98a
> 
> Let's see if this bug can stick on master.

So you landed a patch with a broken Gu, and not waiting for your retriggered Gu to be green ?
If you take a look at the patch, they're totally irrelevant. And it passed perfectly on local. So, the intermittent failure is the tests' problem, not my code's, especially my new patch is newer than the already existing intermittent failure, with the exactly same symptom that described in Bug 1095057, which now seems still occur.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 6

5 years ago
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #5)
> If you take a look at the patch, they're totally irrelevant. And it passed
> perfectly on local. So, the intermittent failure is the tests' problem, not
> my code's, especially my new patch is newer than the already existing
> intermittent failure, with the exactly same symptom that described in Bug
> 1095057, which now seems still occur.

You could have rebased on top of this patch, which landed 9 hours ago, and get a green try.
Blocking 2.2+ for all fixed regressions.
blocking-b2g: 2.2? → 2.2+

Comment 8

5 years ago
This issue still reproduces on Flame 2.2. Filed a new bug 1104351.  

Flame 2.2
Device: Flame 2.2 (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141121040204
Gaia: 25388c6bce932657ebf93adedf31881bfaf88c15
Gecko: 3366c0fcf9c2
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?][failed-verification]
Depends on: 1104351
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Target Milestone: --- → 2.2 S3 (9jan)
You need to log in before you can comment on or make changes to this bug.