Closed Bug 982530 Opened 6 years ago Closed 6 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)

Other
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T verified)

RESOLVED FIXED
blocking-b2g 1.3T+
Tracking Status
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.
Attached video STR video
please see attached steps.
Duplicate of this bug: 982528
Duplicate of this bug: 982526
Duplicate of this bug: 982519
Duplicate of this bug: 982518
Duplicate of this bug: 982517
Duplicate of this bug: 982516
Duplicate of this bug: 982514
Duplicate of this bug: 982510
Duplicate of this bug: 982508
Duplicate of this bug: 982507
Duplicate of this bug: 982505
blocking-b2g: --- → 1.3T?
blocking-b2g: 1.3T? → 1.3T+
Flags: needinfo?(alive)
alive, any idea what might be happening here ?
ni? Tim as well
Flags: needinfo?(timdream)
Component: Gaia → Gaia::System::Lockscreen
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)
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)
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)
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
I'm preparing to send the patch. Upload a video to show the solved case first:
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.
Attached file Patch
Because it's purely lockscreen modification so I set Tim as the reviewer.
Attachment #8392054 - Flags: review?(timdream)
Attachment #8392054 - Flags: review?(timdream) → review+
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.
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
As discussed, I'll closed this bug and open another bug for master, so that we can clear the blocker.
Blocks: 985862
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
The bug for master: Bug 985862
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 → ---
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)
(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)
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.
(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!
If we have another bug to track the version on master, why not close this one?
Ying, are you okay to uplift it? thanks!

--
Keven
Flags: needinfo?(ying.xu)
I think this has been merged

https://github.com/mozilla-b2g/gaia/commit/712846a016f807de4a8e6823bbf468c3a220ac0a
Flags: needinfo?(ying.xu)
(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.
Closing since we can track bug 985862
Status: REOPENED → RESOLVED
Closed: 6 years ago6 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
Depends on: 1010418
You need to log in before you can comment on or make changes to this bug.