1081565 - [Dialer][Browser] When user receieves a call while watching a video through browser, the top portion of the resulting screen will be blank

Status: VERIFIED WORKSFORME

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Rachel Pribble [:rpribble]]

Attachment: Screenshot.png

Description:
If the user watches a video in fullscreen through the browser app, receives a call during the video, then ignores the call, the top two thirds of the resulting screen will be white and blank. The call screen appears properly, but the user will be taken back to the homescreen instead of the video. The video url will still be seen at the top of the screen, and the user is able to interact with the homescreen behind the white overlap. Restarting is required to resolve the issue.
   
Repro Steps:
1) Update a Flame device to BuildID: 20140925000204
2) Enter browser
3) Play a Youtube video and enable fullscreen viewing
4) Receive a call from another device
5) Ignore the call
6) Observe the resulting screen
  
Actual: 
When user receieves a call while watching a video through browser, the top portion of the resulting screen will be blank.

Expected: 
No blank screen is encountered.
  
Environmental Variables:
Device: Flame 2.1 KK (319 MB)
BuildID: 20140925000204 (full flash)
Gaia: 8061ab487d42cbc49b329fd68b9ca90e0fe477e6
Gecko: e970bc96f8b5
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 5/5
See attached: Screenshot, Logcat

*Note: Created as a clone of bug 1073176.

Comment 1

[Rachel Pribble [:rpribble]]

Attachment: Logcat.txt

This issue does not occur on the v2.1.

Environmental Variables:
Device: Flame 2.2 Master KK (319 MB)
BuildID: 20141011040204 (full flash)
Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322
Gecko: 3f6a51950eb5
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

No blank screen is encountered.

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

Comment 1 was a mistake. The issue does not happen on the Flame 2.2.

Nominating this 2.1? This was rewritten because the patch did not resolve this issue bug 1073176.

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

[Blocking Requested - why for this release]:

Comment 4

[Tony Chung [:tchung]]

Alive, was bug 1073176 not properly fixed and uplifted for 2.1?

Comment 5

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

(In reply to Tony Chung [:tchung] from comment #4)
> Alive, was bug 1073176 not properly fixed and uplifted for 2.1?

I tested the v2.1 and confirmed the bug 1073176 is fixed,
however, the bug was talking about "before ignore/recieve the call" and this bug is talking about "ignoring the call".

QAWanted, what I am seeing is different from the bug summary.
* Make a call from another device
* Ignore the call

The browser turns into all white after ignoring the call, and we cannot go home by press home button.

Comment 6

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

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #5)
> (In reply to Tony Chung [:tchung] from comment #4)
> > Alive, was bug 1073176 not properly fixed and uplifted for 2.1?
> 
> I tested the v2.1 and confirmed the bug 1073176 is fixed,
> however, the bug was talking about "before ignore/recieve the call" and this
> bug is talking about "ignoring the call".
> 
> QAWanted, what I am seeing is different from the bug summary.
> * Make a call from another device
> * Ignore the call
> 
> The browser turns into all white after ignoring the call, and we cannot go
> home by press home button.

Also I observed that the vibration never stops after ignoring the call.
Etienne had you ever seen this?

InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable dialer_agent.js:210

STR:
0. Flash v2.1
1. Open browser app(search app) on homescreen
2. Type youtube and choose google.
3. Navigate to youtube.com
4. Choose an video to play.
5. Make call from another device
6. Wait for ~7 secs and then press reject the call.

The youtube website is still there but all white and the phone keeps vibrating.

Comment 7

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

Sam/Aus, I found something bad in taskManager :(
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/task_manager.js#L580

When attention window opens, we should not call exitToApp if we are never shown.
exitToApp will try to open the homescreen without closing the current displayed app :/

I am not sure why this does not happen on master though.

Comment 8

[Etienne Segonzac (:etienne)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> Also I observed that the vibration never stops after ignoring the call.
> Etienne had you ever seen this?

bug 1077331 :)

Comment 9

[Sam Foster [:sfoster] (he/him)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> Sam/Aus, I found something bad in taskManager :(
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/task_manager.
> js#L580
> 
> When attention window opens, we should not call exitToApp if we are never
> shown.
> exitToApp will try to open the homescreen without closing the current
> displayed app :/
> 
> I am not sure why this does not happen on master though.

In master we call an _unregisterShowingEvents method when we hide that removes the event listeners for attentionopened etc. We used to have a similar list of listeners we added and removed when showing (unregisterShowingEvents was just a refactor) but it seems that got removed at some point. I'll do a 2.1 patch. 

This may also fix bug 1081528.

Comment 10

[Sam Foster [:sfoster] (he/him)]

> In master we call an _unregisterShowingEvents method when we hide that
> removes the event listeners for attentionopened etc. We used to have a
> similar list of listeners we added and removed when showing
> (unregisterShowingEvents was just a refactor) but it seems that got removed
> at some point. I'll do a 2.1 patch. 

Hmm, no I just missed it, _unregisterShowingEvents is there in 2.1. I'll look deeper.

Comment 11

[Rachel Pribble [:rpribble]]

The original issue as stated in the description is no longer occurring on today's Flame v2.1 (b2g-34). 
Removing qawanted tag, leaving not yet closing as worksforme since multiple issues are being discussed here.

Environmental Variables:
Device:	Flame 2.1 KK (319 MB)
Build ID: 20141013001201 (full flash)
Gecko: 610ee0e6a776
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Version: 34.0a2 (2.1)
Base Image: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

User is taken back to the video browser page after declining or ignoring a call.

Comment 12

[Sam Foster [:sfoster] (he/him)]

Ok I have a fix for the attentionopened event handler issue (the add/removeEventListener was inside _registerEvents instead of _registerShowingEvents). It appears to fix bug 1081528. But I'm not able to reproduce the issue here, so I'm not sure if its related or not. Maybe we can re-test once that fix is landed?

Comment 13

[Candice Serran (:cserran)]

May be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1081528. When this lands, will verify if this fixes it.

Comment 14

[Sam Foster [:sfoster] (he/him)]

Curiously, I have not been able to reproduce this, but the steps and symptoms do make sense. I've landed bug 1081528 on 2.1, can we re-test once that patch makes it into the build? It fixes the issue Alive spotted in Comment #7. We may also find other dupes involving attention (high-priority) windows.

Comment 15

[KTucker [:KTucker][Inactive 3/4/2016]]

Adding qawanted to see if this issue has been resolved as a result of the patch that landed in bug 1081528

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to KTucker [:KTucker] from comment #15)
> Adding qawanted to see if this issue has been resolved as a result of the
> patch that landed in bug 1081528

I can confirm that this issue has been fixed on latest 2.1. However I can't say for sure that this was fixed by the patch in bug 1081528 because I had worked with Rachel on comment 11 and we both couldn't reproduce the bug since 10/13.

Observed behavior: Device goes back to Browser continuing the youtube video without issue after ignoring an incoming call. Bug repro rate: 0/5.

Device: Flame 2.1 (shallow flash, 319MB mem)
BuildID: 20141014133133
Gaia: a93410a4ef8ff11ff042e2ccbb26001eddd03285
Gecko: cb72824df1d0
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 17

[Joshua Mitchell (Inactive)]

End result is this bug no longer repro's - let's call it fixed

Comment 18

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.1.
When user receieve a call while watching a video through browser, no blank screen is encountered.

See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.1 version:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0