982530 - [tarako] (fixed in 1.3t-only) incoming call with lock screen overlapped for a while

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Peipei Cheng (needinfo if you need my action)]

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.

Comment 1

[Peipei Cheng (needinfo if you need my action)]

Attachment: STR video

please see attached steps.

Comment 13

[bhavana bajaj [:bajaj]]

alive, any idea what might be happening here ?

Comment 14

[Joe Cheng [:jcheng] (please needinfo)]

ni? Tim as well

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

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.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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?

Comment 17

[Greg Weng [:snowmantw][: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.

Comment 18

[Joe Cheng [:jcheng] (please needinfo)]

Greg, it looks like you are going to work on this. assign to you, please reassign if you feel this is incorrect. thanks

Comment 19

[Greg Weng [:snowmantw][:gweng][:λ]]

Attachment: Hide the lockscreen before callscreen

I'm preparing to send the patch. Upload a video to show the solved case first:

Comment 20

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 21

[Greg Weng [:snowmantw][:gweng][:λ]]

Attachment: Patch

Because it's purely lockscreen modification so I set Tim as the reviewer.

Comment 22

[Greg Weng [:snowmantw][:gweng][:λ]]

Travis is green:

https://github.com/mozilla-b2g/gaia/pull/17230

Comment 23

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 24

[Greg Weng [:snowmantw][:gweng][:λ]]

As discussed, I'll closed this bug and open another bug for master, so that we can clear the blocker.

Comment 25

[Greg Weng [:snowmantw][:gweng][:λ]]

The bug for master: Bug 985862

Comment 26

[Tony Chung [:tchung]]

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.

Comment 27

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 28

[Tony Chung [: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!

Comment 29

[Greg Weng [:snowmantw][:gweng][:λ]]

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

[Tony Chung [:tchung]]

(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

[[:fabrice] Fabrice Desré]

If we have another bug to track the version on master, why not close this one?

Comment 32

[Keven Kuo [:kkuo]]

Ying, are you okay to uplift it? thanks!

--
Keven

Comment 33

[ying.xu]

I think this has been merged

https://github.com/mozilla-b2g/gaia/commit/712846a016f807de4a8e6823bbf468c3a220ac0a

Comment 34

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(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

[[:fabrice] Fabrice Desré]

Closing since we can track bug 985862

Comment 36

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

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