Closed
Bug 982530
Opened 10 years ago
Closed 10 years ago
[tarako] (fixed in 1.3t-only) incoming call with lock screen overlapped for a while
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:1.3T+, b2g-v1.3T verified)
People
(Reporter: angelc04, Assigned: gweng)
References
Details
Attachments
(3 files)
Test build: 20140312064823 STR: 1. Set Screen lock and Password lock 2. Press power button to lock screen 3. Make a MT call to test device --> You will notice that "Lock screen appears first and then password lock, and incoming call screen appears." If the performance is slow, you will see these layers overlapped.
Reporter | ||
Comment 1•10 years ago
|
||
please see attached steps.
Updated•10 years ago
|
blocking-b2g: --- → 1.3T?
Updated•10 years ago
|
blocking-b2g: 1.3T? → 1.3T+
Updated•10 years ago
|
Flags: needinfo?(alive)
Comment 13•10 years ago
|
||
alive, any idea what might be happening here ?
Updated•10 years ago
|
Component: Gaia → Gaia::System::Lockscreen
Comment 15•10 years ago
|
||
The dialer turns on the screen by request screen lock to show the lockscreen, but it took some time to show and render and transition to incoming call page. I will say this is a UI polish bug.
Flags: needinfo?(alive)
Comment 16•10 years ago
|
||
Without pushing this to platform and performance again and without making big arch change, here is a random idea: 1) Emit the "reason" of screen on through screenchange event in ScreenManager 2) If screen is turned on by attention screen, lock screen should blacken itself to avoid to be seem. 3) When the attention screen is gone/minimized, lock screen should paint itself instantly. (1) might not be the best path -- maybe lock screen can query the existence of the attention screen itself? Greg, what do you think?
Flags: needinfo?(timdream) → needinfo?(gweng)
Assignee | ||
Comment 17•10 years ago
|
||
Conclusion according to the offline discussion: 1. This is a bug caused by performance issue. Gaia works can solve it by these workarounds, but not the root cause. 2. I'll patch v1.3T first. For master, I wish to patch it after the lockscreen and attention window refactoring, so we can follow the new path. 3. ScreenManager.turnScreenOn would add a |reason| argument as Tim suggested.
Flags: needinfo?(gweng)
Comment 18•10 years ago
|
||
Greg, it looks like you are going to work on this. assign to you, please reassign if you feel this is incorrect. thanks
Assignee: nobody → gweng
Assignee | ||
Comment 19•10 years ago
|
||
I'm preparing to send the patch. Upload a video to show the solved case first:
Assignee | ||
Comment 20•10 years ago
|
||
The video was captured on ZTE Open, because my Taroko would not boot after I insert the SIM card. It should not hinder the patch, so I tested it with the Open.
Assignee | ||
Comment 21•10 years ago
|
||
Because it's purely lockscreen modification so I set Tim as the reviewer.
Attachment #8392054 -
Flags: review?(timdream)
Updated•10 years ago
|
Attachment #8392054 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 22•10 years ago
|
||
Travis is green: https://github.com/mozilla-b2g/gaia/pull/17230
Assignee | ||
Comment 23•10 years ago
|
||
v1.3t: https://github.com/mozilla-b2g/gaia/commit/712846a016f807de4a8e6823bbf468c3a220ac0a as I said, master should take a new path to solve this. So I would submit another patch for master.
Assignee | ||
Updated•10 years ago
|
status-b2g-v1.3T:
--- → fixed
Updated•10 years ago
|
Summary: [tarako] incoming call with lock screen overlapped for a while → [tarako] (fixed in 1.3t-only) incoming call with lock screen overlapped for a while
Assignee | ||
Comment 24•10 years ago
|
||
As discussed, I'll closed this bug and open another bug for master, so that we can clear the blocker.
Assignee | ||
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 25•10 years ago
|
||
The bug for master: Bug 985862
Comment 26•10 years ago
|
||
marking status as reopen. This bug shouldnt be marked "RESOLVED FIXED" until it actually lands against master/m-c. When you've landed it there, feel free to change the status then. Thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 27•10 years ago
|
||
Well, I don't think keeping this bug (and the component) under Andreas' blocker dashboard is a good idea. It may cause a strange case that even though I did fix the bug in the blocking branch, the branch would still be blocked (holy...) according to the information people read from those summaries. Of course they can know the details by reading the comments, but there would be some misunderstandings. However if this is our policy to manage solved blockers on a blocking branch, I would follow what you mentioned.
Flags: needinfo?(tchung)
Comment 28•10 years ago
|
||
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #27) > Well, I don't think keeping this bug (and the component) under Andreas' > blocker dashboard is a good idea. It may cause a strange case that even > though I did fix the bug in the blocking branch, the branch would still be > blocked (holy...) according to the information people read from those > summaries. Of course they can know the details by reading the comments, but > there would be some misunderstandings. > > However if this is our policy to manage solved blockers on a blocking > branch, I would follow what you mentioned. If Andreas has a concern with this, i'm happy to consult with him. I have chatted with relmgmt, and Fabrice (1.3 sheriff), and even brought this up in gaia meeting today... all agreed this is an easier way to track what still needs to land on trunk. We just want to make sure none of these patches get dropped when we merge back to trunk (nor cause any trunk regressions) I have been trying to locate other bugs that have 1.3Tfixed + RESO FIXED, and found maybe about 10 or so more. Please work with us to reopen the bugs and then resolve them after landing in master. Thanks!
Flags: needinfo?(tchung)
Assignee | ||
Comment 29•10 years ago
|
||
OK, thanks for the explanation. After I solve the bug in master (which now is another follow-up bug), I will close both two bugs.
Comment 30•10 years ago
|
||
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #29) > OK, thanks for the explanation. After I solve the bug in master (which now > is another follow-up bug), I will close both two bugs. Close as in "resolved fixed" i presume. Thanks Greg!
Comment 31•10 years ago
|
||
If we have another bug to track the version on master, why not close this one?
Comment 32•10 years ago
|
||
Ying, are you okay to uplift it? thanks! -- Keven
Flags: needinfo?(ying.xu)
Comment 33•10 years ago
|
||
I think this has been merged https://github.com/mozilla-b2g/gaia/commit/712846a016f807de4a8e6823bbf468c3a220ac0a
Flags: needinfo?(ying.xu)
Comment 34•10 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #31) > If we have another bug to track the version on master, why not close this > one? I agree. Bug 985862 is filed for master before this bug is reopened.
Comment 35•10 years ago
|
||
Closing since we can track bug 985862
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Verified fixed in today's build 1.3t Environmental Variables: Device: Tarako 1.3t BuildID: 20140429014002 Gaia: b5adc5a943d3abbd6ab070a47c847f2c24891cc5 Gecko: e9890f5d4709 Version: 28.1 Firmware Version: sp6821
You need to log in
before you can comment on or make changes to this bug.
Description
•