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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

RESOLVED FIXED
2.2 S3 (9jan)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- fixed

People

(Reporter: gerard-majax, Assigned: gweng)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image 2014-11-06-15-39-02.png
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.
Attached 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: nobody → gweng
Attachment #8518196 - Flags: review?(timdream) → review+
The patch only encounter one intermittent failure: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=4748f9505489 So I would land this patch.
(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
Closed: 10 years ago
Resolution: --- → FIXED
(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+
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.

Attachment

General

Creator:
Created:
Updated:
Size: