1204069 - [Window Mgmt] The video in Youtube will be gray for a few seconds after exiting the fullscreen prompt

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect, P3)

Description

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

The video screen will be completely gray for a few seconds after tapping "cancel" on the "http://m.youtube.com is now fullscreen prompt."

Repro Steps:
1) Update a Aries to 20150911153729
2) Open the browser and go to m.youtube.com
3) Tap on a video to play it. 
4) Tap on the video to show the video controls and tap on the "Fullscreen" icon.
5) When prompted, tap the "Cancel" button and observe the video screen. 

Actual:
The video screen will be gray for a few seconds after exiting the "http://m.youtube.com is now fullscreen" prompt.

Expected:
The video resumes normal playback.

Environmental Variables:
Device: Aries 2.5
Build ID: 20150911153729
Gaia: 758c75ee087ea3722213ea2c185cca1d952c8a29
Gecko: 7b1cfb1606ec447506bf7373b645b7a09f3aa238
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Repro frequency: 5/5 100%
See attached: video, logcat

Comment 1

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

This issue also reproduces on the Flame 2.5 

This is actually worse since the whole screen and then the video screen goes gray after exiting the prompt. 

Environmental Variables:
Device: Flame 2.5 (Full Flash)(KK)(319mb)
Build ID: 20150911030227
Gaia: 6280500a6cb8d1b178cdd163450e36d22846fbed
Gecko: c0abc2a6e11f52761366e029eb1bae4c9864a8a3
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

---------------------------------------
This issues does not reproduce on the Flame 2.2

No gray video screen is observed after exiting the fullscreen prompt. 

Environmental Variables:
Device: Flame 2.2 (Full Flash)(KK)(319mb)
BuildID: 20150911032501
Gaia: 7a427e0f8aa6c185a9e22358006b97c19435ca4a
Gecko: 0d9c46d01861
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

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

Attachment: Youtubelog.txt

Comment 3

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

[Blocking Requested - why for this release]:
This is a regression of Youtube functionality.  Let's get a window on this issue.

Comment 4

[Michael Bryant (uber)]

Jayme, the initial regression window for this bug is the same as the regression window for Bug 1123209. As a result I would suggest it's likely that they both have the same root cause. The most easily noticeable difference between the two is that the first broken build has a different YouTube UI than the last working build.

Mozilla Central Regression log Inbound:

Last working build
Build ID               20150511010202
Gaia Revision          6089234ace8b294a8feef064387604bae16254e3
Gaia Date              2015-05-10 13:57:12
Gecko Revision         d8420a541d1c
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2


First broken build

Build ID               20150511122605
Gaia Revision          6089234ace8b294a8feef064387604bae16254e3
Gaia Date              2015-05-10 13:57:12
Gecko Revision         502e1a5e722f
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2

First broken gaia with last working gecko -> No reproduction

Gaia: 6089234ace8b294a8feef064387604bae16254e3
Gecko: d8420a541d1c

Last working gaia with first broken gecko -> Reproduces

Gaia: 6089234ace8b294a8feef064387604bae16254e3
Gecko: 502e1a5e722f

Gecko Push Log:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d8420a541d1c&tochange=502e1a5e722f

Comment 5

[Martin Shuman [:Marty]]

This issue may be caused by either:
Bug 1131756 - Debugger doesn't break in react hot reload demo
OR
Bug 1154606 - Should have a better error message when source map does not exist

Note: The window posted in Comment 4 is also the same window when youtube videos started auto-playing with advertisements, which may be related to this issue.

Comment 6

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

James your changes for bug 1131756 or bug 1154606 may have been the cause for this issue.  Can you please take a look at the pushlog in comment 4 and give your thoughts?

Comment 7

[James Long (:jlongster)]

Are the devtools open when this happens? The devtools aren't even loaded unless they are opened, and my changes should have absolutely no affect is the devtools aren't being used.

Comment 8

[Mahendra Potharaju [:mahe]]

Blocks 2.5 with P3. Papercut. But needs to be fixed

Comment 9

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

Not a Gaia issue according to regression range. Please re-triage.

Comment 10

[Ken Chang[:kenkai]]

Jerry, can you please check if this bug is related to gfx.

Comment 11

[James Long (:jlongster)]

I just noticed that the 2 commits from me also *only* add some l10n strings, so that can't be the issue.

Comment 12

[Jerry Shih[:jerry] (UTC+8) (inactive)]

I'm trying to use layerscope tool[1] to check the gray screen.

[1]
https://wiki.mozilla.org/Platform/GFX/LayerScope

Comment 13

[Jerry Shih[:jerry] (UTC+8) (inactive)]

When we see the gray screen, I don't see the ImageLayer in layer tree. Investigating.

Comment 14

[Jerry Shih[:jerry] (UTC+8) (inactive)]

I'm not sure why that image layer is culled at [1] during exiting the full-screen prompt. That is at bug 1097464. Image decoder is still send the image, and the layer and the layerComposite status looks fine. Currently, I think the gray screen problem is due to the culling process. Investigating.

[1]
https://hg.mozilla.org/mozilla-central/annotate/d374d16cbb251c9dac5af69f8e186e821ce82fe2/gfx/layers/composite/ContainerLayerComposite.cpp#l366

Comment 15

[Jerry Shih[:jerry] (UTC+8) (inactive)]

The gray screen is due to setting empty visible region to imageLayer at [1]. The recent change of this function is bug 1097464. I will try to catch this new changes.

[1]
https://hg.mozilla.org/mozilla-central/annotate/e8c7dfe727cd970e2c3294934e2927b14143c205/layout/base/FrameLayerBuilder.cpp#l2445

Comment 16

[Mahendra Potharaju [:mahe]]

[Tracking Requested - why for this release]:

As this is a papercut, removing the 2.5 blocker flag and putting as part of backlog.

Comment 17

[Mahendra Potharaju [:mahe]]

This bug needs to be fixed and landed soon after branching. Not holding release for this bug

Comment 18

[Josh Cheng [:josh]]

Hi Cynthia,
Could you help to test using TV browser browsing desktop Youtube site and see whether the issue can be reproduced on TV Gaia?
Thanks

Comment 19

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Josh Cheng [:josh] from comment #18)
> Hi Cynthia,
> Could you help to test using TV browser browsing desktop Youtube site and
> see whether the issue can be reproduced on TV Gaia?
> Thanks

I didn't see this issue on TV browser while browsing desktop Youtube site. Cynthia can double check if my observation is valid or not.

Comment 20

[Cynthia Tang [:cynthiatang]]

Hi Josh and SC,
This issue cannot be reproduced on TV while browsing desktop Youtube site. Thank you.

======== Build Info =======
Build ID               20151108150206
Gaia Revision          23cab7ea0fcecab7689d340baf604e024e88f9a3
Gaia Date              2015-11-09 06:13:17
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e2a910c048dc82fc3be53475f18e7f81f03e377b
Gecko Version          45.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20151108.182159
Firmware Date          Sun Nov  8 18:22:17 EST 2015
Bootloader             HHZ12f

Comment 21

[Ethan Lin[:ethlin]]

I found that the gray layer is the statusOverlay in video control component. So I think we can change the display rule of the statusOverlay to fix it.

Comment 22

[Ethan Lin[:ethlin]]

Attachment: v1 - Change the rule of showing statusFader

The VideoControl will be recreated when the nsVideoFrame is moved. Then the VideoControl will try to show the statusFader again [1]. The original check will let the statusFader display if the readyState is not HAVE_ENOUGH_DATA, but it doesn't match the check in HTMLMediaElement[2]. So I use HAVE_FUTURE_DATA to check if statusFader should display in VidoeControl to solve this problem.

[1] https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/videocontrols.xml#633
[2] https://dxr.mozilla.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp?from=HTMLMediaElement.cpp#2301

Comment 23

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8687055 [details] [diff] [review]
v1 - Change the rule of showing statusFader

Review of attachment 8687055 [details] [diff] [review]:
-----------------------------------------------------------------

Jared reviews the videocontrols I believe.

Comment 24

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8687055 [details] [diff] [review]
v1 - Change the rule of showing statusFader

Review of attachment 8687055 [details] [diff] [review]:
-----------------------------------------------------------------

This change looks reasonable. Thanks for providing the link to HTMLMediaElement.cpp.

Comment 25

[Ethan Lin[:ethlin]]

Try server result:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=98e1777fc4ef

Comment 26

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/212ae3c64bd9

Comment 27

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/212ae3c64bd9