1396743 - Video is not resized accordingly when page zoom level is reset on new YouTube UI

Status: NEW

(Core :: Layout, defect, P3)

Description

[roxleitan]

Attachment: img.png

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170831165232

[Affected versions]:
Beta 56.0b8

[Affected platforms]:
Mac OS X 10.10, Mac OS X 10.12

[Steps to reproduce]:
1.Launch Firefox 56.0b8 with new profile
2.Set " layers.mlgpu.dev-enabled" and "layers.mlgpu.enabled" on True
3.Restart browser
4.Play a video on youtube.com (browser is set to normal size mode)
5.Zoom in (300%)
6.Enable browser Full-screen mode
7.Click to reset zoom to 100%

[Expected result]:
Zoom level should be reset and video should be resized accordingly

[Actual result]:
Zoom level is reset but video is not resized

[Note]:
The issue is reproducible also without step 2.
Not reproducible on latest Nightly 57.0a1.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Since we don't need the advanced layers preference set, do we know if this is a regression from 55?

Comment 2

[roxleitan]

Last good revision: 71ece2c1e68da6cf4949b57682c2700bab30edfb
First bad revision: 6ce22ac573a71d1386a1624371a95ce6dd896174
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=71ece2c1e68da6cf4949b57682c2700bab30edfb&tochange=6ce22ac573a71d1386a1624371a95ce6dd896174

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

But it's working in 57?  If so, can we do a reverse mozregression to get what fixed it?

Comment 4

[Cristina Badescu [:cbadescu], Experiments QA]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Version: 57.0a1; Build ID: 20170913100125

Hello,

I have tried to do a "--find-fix" regression using Mozregression tool, but it seems that the issue is also reproducible on latest Nightly (57.0a1) build, but only with the new YouTube UI. It doesn't matter if the prefs are set or not. However, this is not reproducible with the old YouTube UI. It seems that the issue is also reproducible on Windows.

I have tested this issue on latest Firefox release (55.0.3) and is not reproducible. Considering this I have used the Mozregression tool to see what caused this. Here are the results:
Last good revision: 93e4115d18670235f950ecaf9ce66559abb6024a
First bad revision: e573f37405ba017ab1e9aa6a2bb1cb31468c73a9
Pushlog: https://goo.gl/f7MPSe
Looks like the following bug has the changes which introduced the regression: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1236512

Edgar, can you please take a look at this issue?

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Moving to DOM based on comment 4.

Comment 6

[Samael Wang [:freesamael] (away for now)]

I found that although the reproducing rate is high on bad builds, it's not 100%, which indicates we could have a misleading result on bisect. Another interesting observation is that I have to logout youtube to reproduce it on nightly (could be a coincidence).

I tried another bisect, and repeat the test ~5 times if it firstly looks a good build. Eventually, it points me to this, which is also confusing...
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=39ba362aa75302c21d81519ae1793998db130b81&tochange=c467c6d0d17ea73b82e86ab1169925bfe03f9b2f

At least I'm able to reproduce the bug on a build ~2 months before bug 1236512 was landed, so it's unlikely a regression from bug 1236512. I'm still trying to find clues, but if anyone who's familiar with video elements can take a look it would probably be much more helpful.

Comment 7

[Samael Wang [:freesamael] (away for now)]

Attachment: video-element-size

Inspector shows the size of video-element was incorrect.

Comment 8

[Samael Wang [:freesamael] (away for now)]

Update the component to reflect my current finding and hopefully draw attentions from someone who's experienced with video element.

Comment 9

[Ray Lin[:ralin]]

Don't know why would be this case. But if this issue occurs on YouTube, I think it's unlikely a "Video/Audio Controls" problem as our built-in control is never loaded by default on YouTube.

Comment 10

[Samael Wang [:freesamael] (away for now)]

(In reply to Ray Lin[:ralin] from comment #9)
> Don't know why would be this case. But if this issue occurs on YouTube, I
> think it's unlikely a "Video/Audio Controls" problem as our built-in control
> is never loaded by default on YouTube.

Do you know what component <video> element belongs to? I'm quite unfamiliar with these stuff.

Comment 11

[Samael Wang [:freesamael] (away for now)]

Maybe just audio/video?

Comment 12

[Ray Lin[:ralin]]

Hey Alastor, do you have any clue whether media playback could cause this issue? Thanks.

Comment 13

[Alastor Wu [:alwu]]

It seems more like a layout issue. 
The size of decoded video frame is fixed and they would be sent to image bridge, then layout would decide the actual image size.

Comment 14

[Samael Wang [:freesamael] (away for now)]

(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #13)
> It seems more like a layout issue. 
> The size of decoded video frame is fixed and they would be sent to image
> bridge, then layout would decide the actual image size.

With this hint I tried to enable reflow logs:

enter nsVideoFrame::Reflow: availSize=22860,1073741823
exit nsVideoFrame::Reflow: size=22860,12900
enter nsVideoFrame::Reflow: availSize=22800,1073741823
exit nsVideoFrame::Reflow: size=22800,12840
enter nsVideoFrame::Reflow: availSize=76800,1073741823
exit nsVideoFrame::Reflow: size=76800,43200
enter nsVideoFrame::Reflow: availSize=51240,1073741823
exit nsVideoFrame::Reflow: size=51240,28800
enter nsVideoFrame::Reflow: availSize=38400,1073741823
exit nsVideoFrame::Reflow: size=38400,21600
enter nsVideoFrame::Reflow: availSize=51240,1073741823
exit nsVideoFrame::Reflow: size=51240,28800
enter nsVideoFrame::Reflow: availSize=38400,1073741823
exit nsVideoFrame::Reflow: size=38400,21600
enter nsVideoFrame::Reflow: availSize=25560,1073741823
exit nsVideoFrame::Reflow: size=25560,14400
enter nsVideoFrame::Reflow: availSize=76800,1073741823
exit nsVideoFrame::Reflow: size=25560,14400

What particularly interesting is that the video frame doesn't take all the available space on last reflow (presumably the problematic one).

Comment 15

[Gerry Chang [:gchang]]

Since it's not a common user behavior and we are about to build 56 RC, mark 56 as won't fix. Feel free to nominate again.

Comment 16

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I cannot reproduce this reliably. Here's the observation on inspector when I manage to reproduce.

When the zoom level is 100%, the <video class="video-stream html5-main-video"> has inline style "width: 640px; height: 360px". When the zoom level is 300%, the page will change the <video>'s inline style to "width: 426px; height: 240px;". 

After the zoom level is changed from 300% to 100% (step 7 in comment 0), the script failed to reset the <video>'s inline style from "width: 426px; height: 240px;" back to "width: 640px; height: 360px" (as the screenshot in comment 7), so the video looks smaller.

I think layout is correct here. The issue is why the inline style of the <video> failed to change back.

Comment 17

[Ray Lin[:ralin]]

(In reply to Ting-Yu Lin [:TYLin] (UTC+8) from comment #16)
> I cannot reproduce this reliably. Here's the observation on inspector when I
> manage to reproduce.
> 
> When the zoom level is 100%, the <video class="video-stream
> html5-main-video"> has inline style "width: 640px; height: 360px". When the
> zoom level is 300%, the page will change the <video>'s inline style to
> "width: 426px; height: 240px;". 
> 
> After the zoom level is changed from 300% to 100% (step 7 in comment 0), the
> script failed to reset the <video>'s inline style from "width: 426px;
> height: 240px;" back to "width: 640px; height: 360px" (as the screenshot in
> comment 7), so the video looks smaller.
> 
> I think layout is correct here. The issue is why the inline style of the
> <video> failed to change back.

The observation make sense to comment 14, as the video frame respects the inline style so doesn't take all the available room from the container.

Comment 18

[Ray Lin[:ralin]]

Hi Roxana, from comment 15 and considering that it seems only breaks 56, do you think it's fine to close this bug? Thanks.

Comment 19

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

FWIW, I can reproduce this intermittently on 57.0a1 (2017-09-17).

Comment 20

[Samael Wang [:freesamael] (away for now)]

Me too. I can reproduce it on today's mozilla-central (intermittently). I guess we don't want to close the bug just yet.

Comment 21

[Ray Lin[:ralin]]

Ah sorry, my fault didn't notice comment 4 but only see the [Note] section on comment 0 :P

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 57 since we're a few days away from release.

Comment 23

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals