Closed Bug 788412 Opened 12 years ago Closed 7 years ago

Lock screen arrow animation is mistakenly drawn on top of the handle

Categories

(Firefox OS Graveyard :: General, defect, P3)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: timdream, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #788411 +++ STR: 1. Boot up the phone and observe lock screen Exepected: 1. There should be a semi-transparent arrow travels from the handle to the icons, and iterates. The arrow should begin from the position of handle BUT below the handle Actual: 1. It is drawn above the handle Note: * Happens on B2G/Desktop but not on Nightly * Cannot observe the behavior on Otoro since it is not shown at all (bug 788411) * Disable the animation by remove the CSS then it will be correctly shown below the handle again
B2G/Desktop isn't a Basecamp blocker. That doesn't mean we can't fix this, just that we wouldn't hold B2G v1 for it.
blocking-basecamp: ? → -
(In reply to Andrew Overholt [:overholt] from comment #1) > B2G/Desktop isn't a Basecamp blocker. That doesn't mean we can't fix this, > just that we wouldn't hold B2G v1 for it. Right, thought I suspect after bug 788411 is fixed and the arrow will also mistakenly shown on top of the handle on Otoro.
My suspicion is correct: This happens on Otoro too!
blocking-basecamp: - → ?
I've heard this UX is quite important so blocking.
blocking-basecamp: ? → +
Summary: [B2G/Desktop] Lock screen arrow animation is mistakenly drawn on top of the handle → Lock screen arrow animation is mistakenly drawn on top of the handle
Vivien, who should own this?
Assignee: nobody → 21
Do people think this is more important than a P3?
Priority: -- → P3
I can reproduce on an Unagi device. Doesn't happen if I turn off OMTA, so I suspect this is another OMTA bug.
OS: Mac OS X → All
Hardware: x86 → All
dbaron/jet, can someone on the layout team help diagnose this potential OMTA bug?
(In reply to Andrew Overholt [:overholt] from comment #6) > Do people think this is more important than a P3? Really not. I have also heard that this animation may change so it's not even clear this is a blocking in this particular occurence.
(In reply to Vivien Nicolas (:vingtetun) from comment #10) > (In reply to Andrew Overholt [:overholt] from comment #6) > > Do people think this is more important than a P3? > > Really not. I have also heard that this animation may change so it's not > even clear this is a blocking in this particular occurence. This shouldn't be blocking anymore. We are shipping redesigned lock screen handle (bug 806989) it is likely this glitch with async animation will not be seem anymore.
blocking-basecamp: + → ---
Reassign to me. I'll see if I could write up a test case for this possible OMTA bug.
Assignee: 21 → timdream+bugs
Deassign myself since I have failed to produce a testcase for more than a year. Those who interested in creating a test case should check out the Gaia back then and extract the related CSS/HTML/JavaScript.
Assignee: timdream → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.