Closed
Bug 1094829
Opened 10 years ago
Closed 10 years ago
Lockscreen slider not cleared when unlocking for Camera
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:2.2+, b2g-v2.2 fixed)
Tracking | Status | |
---|---|---|
b2g-v2.2 | --- | fixed |
People
(Reporter: gerard-majax, Assigned: gweng)
References
Details
(Keywords: regression)
Attachments
(2 files)
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.
Assignee | ||
Comment 1•10 years ago
|
||
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•10 years ago
|
Assignee: nobody → gweng
Updated•10 years ago
|
Attachment #8518196 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 2•10 years ago
|
||
The patch only encounter one intermittent failure:
https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=4748f9505489
So I would land this patch.
Assignee | ||
Comment 3•10 years ago
|
||
master: https://github.com/mozilla-b2g/gaia/commit/a36f52d2398e7b97a32b52dbe258a0a65a1ba98a
Let's see if this bug can stick on master.
Reporter | ||
Comment 4•10 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 ?
Assignee | ||
Comment 5•10 years ago
|
||
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
Closed: 10 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 6•10 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.
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
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
status-b2g-v2.2:
--- → fixed
Target Milestone: --- → 2.2 S3 (9jan)
You need to log in
before you can comment on or make changes to this bug.
Description
•