[Tracking Requested - why for this release]:

+++ This bug was initially created as a clone of Bug #1559518 +++

Tested autoland
Build ID 20190619210854
Built from https://hg.mozilla.org/integration/autoland/rev/8d7491cb1c12fc69980a277e97d7c0f78582da18
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Bug 1559518 did partially fix the issue.
But I can still reproduce the issue if I keep moving mouse pointer on the screen.
The problem happens regardless with/without WebRender.

STR

1. Open any Video page (incl. standalone/local video)
   ( e.g https://base-n.de/webm/VP9%20Sample.html )
2. Zoom out 90%
3. Click on fullscreen icon at the end of video controls
4. While a screen is transferring, keep moving a mouse pointer on the screen.

Actual Results:
Bottom and right parts(incl. video controls) of video is truncated.

Regression window(Bottom and right parts is truncated):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a91efd693851d156f5680c88e6f91d12406ec3fe&tochange=94b369f38c536a4cc3b308311b1e88825e581ff5

Ryan Hunt,
Your patch seems to cause the regression. And Bug 1559518 did not fix the issue.
Can you please look into this?

The problem seems happen to any element.

I can confirm. Video viewport is truncated and we can see the webpage underneath. Fun fact I have seen exactly the same bug some time ago.

Zoom out is not necessary to reproduce the issue.

2. Zoom out 90%

STR

1. Reduce browser width and height
2. Open any Video page (incl. standalone/local video)
   ( e.g https://base-n.de/webm/VP9%20Sample.html )
3. Click on Goto Fullscreen button
4. While a screen is transferring, keep moving a mouse pointer on the screen.

STR

1. Reduce browser width and height
2. Open attachment 9072985 [details]
3. Click on fullscreen icon at the end of video controls

:rhunt, can you look into the bug?

Yup, looking into it. It's tricky to reproduce consistently.

(In reply to Ryan Hunt [:rhunt] from comment #6)

It's tricky to reproduce consistently.

Is it really?

1. Open anything in fullscreen mode. (can be https://interactive-examples.mdn.mozilla.net/pages/tabbed/video.html but anything works)
2. Hit ctrl+minus to reduce view scale.
3. FS content is truncated.

It is reproducible every time.

(In reply to Kacper Michajłow [:kasper93] from comment #7)

(In reply to Ryan Hunt [:rhunt] from comment #6)

It's tricky to reproduce consistently.

Is it really?

1. Open anything in fullscreen mode. (can be
   https://interactive-examples.mdn.mozilla.net/pages/tabbed/video.html but
   anything works)
2. Hit ctrl+minus to reduce view scale.
3. FS content is truncated.

It is reproducible every time.

I can't reproduce this using those steps. It may be platform related. I've only been able to test on Mac as that's all I brought with me to the Mozilla All Hands. I'll try to find another system to test on. Flipping webrender doesn't affect this.

BTW, I can also reproduce the issue with the both STR of comment#4 on Nightly69.0a1 Ubuntu18.04 (no HWA).

FWIW, comment 7 reproduces for me on macOS using Nightly.

In addition, when initially entering fullscreen without reducing the scale, I get content that is slightly truncated (leaving a white strip) at the bottom only, but not on the right-hand side.

(In reply to Ryan Hunt [:rhunt] from comment #9)

(In reply to Kacper Michajłow [:kasper93] from comment #7)

(In reply to Ryan Hunt [:rhunt] from comment #6)

It's tricky to reproduce consistently.

Is it really?

1. Open anything in fullscreen mode. (can be
   https://interactive-examples.mdn.mozilla.net/pages/tabbed/video.html but
   anything works)
2. Hit ctrl+minus to reduce view scale.
3. FS content is truncated.

It is reproducible every time.

I can't reproduce this using those steps. It may be platform related. I've only been able to test on Mac as that's all I brought with me to the Mozilla All Hands. I'll try to find another system to test on. Flipping webrender doesn't affect this.

I reproduce it and I'm also using Mac Os Mojave 10.14.5. See my previous attachment (using Firefox Nightly) and reducing to 90%

(In reply to Ryan Hunt [:rhunt] from comment #9)

(In reply to Kacper Michajłow [:kasper93] from comment #7)

(In reply to Ryan Hunt [:rhunt] from comment #6)

It's tricky to reproduce consistently.

Is it really?

1. Open anything in fullscreen mode. (can be
   https://interactive-examples.mdn.mozilla.net/pages/tabbed/video.html but
   anything works)
2. Hit ctrl+minus to reduce view scale.
3. FS content is truncated.

It is reproducible every time.

I can't reproduce this using those steps. It may be platform related. I've only been able to test on Mac as that's all I brought with me to the Mozilla All Hands. I'll try to find another system to test on. Flipping webrender doesn't affect this.

Ah, you are right. Actually the fix for bug 1559518 fixes my STR. I must have tested old nightly and didn't noticed that it does not include the fix. But still I see the flickers when I enter the FS It is hard to provide consistent STR, because rect is updated soon after entering FS.

That said I can reproduce the issue every time with @Alice0755's STR attachment 9072985 [details] What happens on my system is that the size of fullscreen content will be the same as the windowed viewport size. Actually zooming will fix that.

So basically we set wrong initial rect for fullscreen content.

:rhunt
maybe my descriptions for reproducing this bug will help, I'm on Windows 10 and I can reproduce it consistently on scale 100% on my 1440p monitor.
Using windowed mode and decreasing width or height works, too. (the difference between windowed and fullscreen needs to be large enough to be able to see the bug, I think)

sometimes it helps if you don't move the mouse at all when clicking the fullscreen button. (at least on a new profile, on my everyday profile it happens everytime even if I move the mouse)

The changes that caused this regression were originally targeted only for OOP-iframes. Theoretically they should work for normal OOP-browsers, but obviously there's something wrong here.

I won't have a lot of time to dig into the details this week, so I think it's best to effectively remove these changes from OOP-browsers. We can still keep the code affecting OOP-iframes, as they're not enabled by default.

I've written a patch to do this, but I've been having a hard time reproducing the regression on my computers.

Alice, could you try one of the attached builds and report if this patch actually fixes the issue for you?

• Treeherder [1]
• Windows x64 [2]
• OSX x64 [3]

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=08e166ae24d3741fa4906d5029d2a3524109250a
[2] https://queue.taskcluster.net/v1/task/Tcwh0Q0nSXuVlwm5dyO9LA/runs/0/artifacts/public/build/target.zip
[3] https://queue.taskcluster.net/v1/task/H2bNSGEVTfGO8ZCdOx2-3w/runs/0/artifacts/public/build/target.dmg

(In reply to Ryan Hunt [:rhunt] from comment #17)

[1]
https://treeherder.mozilla.org/#/
jobs?repo=try&revision=08e166ae24d3741fa4906d5029d2a3524109250a

Build id: 20190624171059
https://hg.mozilla.org/try/rev/08e166ae24d3741fa4906d5029d2a3524109250a
I tested on Windows10 and Ubuntu18.04. (I do not have Mac.)
The try builds(Windows 2012 x64 opt and Linux x64 opt) fixed the issue.

This was fixed by Bug 1554861

Hmm. It looks like I used the wrong bug number. The patch should have landed under this bug and not bug 1554861. Not sure what the best way to fix this is.

Hello!
Reproduced the issue using Firefox 69.0a1 (20190620220631) on Windows 10x64.
The issue is verified with Firefox 69.0b7 (20190722201635) on Windows 10x64, macOS 10.14 and Ubuntu 18.04, tried several times and no truncated video was presented.