1656223 - iview.abc.net.au videos zoomed after exiting fullscreen

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Cletus Van Damme]

Attachment: Windowed browser playing ABC iview video, before and after fullscreen.

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Visit ABC iview (iview.abc.net.au) and play any video, enter fullscreen mode via the arrows at the bottom right, exit fullscreen mode via the same arrows or by hitting escape key.

Actual results:

Video is heavily zoomed in, with only the top left visible in the browser window.

Expected results:

Video should have returned to original size.

Comment 1

[Cletus Van Damme]

Hopefully helpful further info:

Problem occurs after every fullscreen (i.e. is not intermittent).

Have so far only encountered the problem on ABC iview and not on other video sites (YouTube, Netflix, and various embedded players).

First experienced problem in Firefox 80.0b1 (64-bit). Reproduced in 81.0a1 (2020-07-29) (64-bit). Problem does NOT occur in 78.0.2 (64-bit) and 79.0 (64-bit) - both exhibit expected behaviour. All tested with fresh profiles, default settings, no add-ons.

Problem does NOT occur if I uncheck the "use hardware acceleration when available" setting.

GPU is a GeForce RTX 2060 Super. Installed drivers were several months old (445.87), so I installed the current version (451.67), but this had no impact on the issue.

OS is Windows 8.1 Pro 64-bit.

In an attempt to reproduce this issue on another system configuration, I installed Firefox 80.0b1 on a Windows 10 laptop with Intel HD Graphics, but the problem did not occur on that system.

Comment 2

[Virginia (please send need info request to Brindusa Tot)]

Hi Cletus,

Thanks for reporting this ticket.

I was able to confirm your troubleshooting on a Windows 10 Pro laptop, and I've updated the flags accordingly.

Page tested: https://iview.abc.net.au/show/abc-news-24/video/NS1413V001S00

Not reproducible on:
68.11.0esr (64-bit)
79.0 (64-bit)

Reproducible on:
80.0b4 (64-bit)
81.0a1 (2020-08-05) (64-bit)

I've added a product and component so the corresponding team can investigate this issue.

Regards,
Virginia

Comment 3

[Alastor Wu [:alwu]]

I can reproduce this issue on my Windows10 as well, but wasn't able to reproduce it on MacOS.

Comment 4

[Alice0775 White]

I can reproduce the issue on Nightly81.0a1 Windows10 with/without Webrender or Disabled HWA.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=81ed5bedd083dc295ce8622f171321959ca36bd0&tochange=6803dda74d3349a45d95bc9ce248b90bd9086488

Regressed by: Bug 1644271

Setting apz.mvm.force-enabled to true reproduces the issue on Firefox79.
And Setting apz.mvm.force-enabled to false fixes the issue on Firefox80.0b6.
However, Setting apz.mvm.force-enabled to false does not fix the issue on Nighty81.0a1.....
Setting both apz.mvm.force-enabled and apz.allow_zooming(default true by Bug 1620055) to false will fix the problem on Nighty81.0a1.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 6

[Jim Mathies [:jimm]]

site specific regression related to desktop zoom.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I've tried reproducing this on two different Windows machines (Lenovo arm64 laptop and dell desktop) and haven't been able to. On the desktop I do see after exiting fullscreen the video is momentarily at the fullscreened size but it quickly resizes back to what I would expect. Tried with and without WebRender.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jim Mathies [:jimm] from comment #6)

site specific regression related to desktop zoom.

While it was caused by patches required for desktop zoom, the bug appears to affect 80 as it's not conditional on desktop zoom being enabled. So flipping 80 to fix-optional.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Alice, if you have some time, can you please repro on a build from this try push with MOZ_LOG="apz.mobileviewport:5" in the environment? It should emit a bunch of logging to stderr. If it doesn't show up you may need to set MOZ_LOG_FILE="some_file" to have the output go to a set of files (one per process). Thanks!

Comment 10

[Alice0775 White]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #9)

Alice, if you have some time, can you please repro on a build from this try push with MOZ_LOG="apz.mobileviewport:5" in the environment? It should emit a bunch of logging to stderr. If it doesn't show up you may need to set MOZ_LOG_FILE="some_file" to have the output go to a set of files (one per process). Thanks!

The try-build cannot play the video in comment 2 due to an error. (Maybe the same reason as bug 1658490.)

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Hm, I was seeing that problem on the regular aarch64 windows build, and I think it's because those builds don't have the EME stuff for decoding video content. The Be aarch64 build worked on my Lenovo laptop as it includes the EME stuff. I don't know what the equivalent is for the x64 build but I've triggered some more jobs on that try push and will try those builds to see if one of them has EME built in.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Hm, none of those builds worked either.

In that case, can you just try with a regular nightly build? Same steps as in comment 9 - there might still be some clues as to what's going wrong in the logs that are already in the code. Thanks!

Comment 13

[Alice0775 White]

Attachment: log.zip of Nightly81.0a1(20200813092915) Windows10

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #12)

Hm, none of those builds worked either.

In that case, can you just try with a regular nightly build? Same steps as in comment 9 - there might still be some clues as to what's going wrong in the logs that are already in the code. Thanks!

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Thanks! It seems like the visual viewport size isn't getting updated after exiting fullscreen, although I'm not sure why (or even if that's the root of the problem here, but it's plausible). I'll try to figure out a way to get more logging into a build you can use so I can narrow this down.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Ah, I can reproduce it now. The initial window size (before going into fullscreen) has to be rather large for this to reproduce. My window was pretty small and apparently that behaves differently during reflow.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

After exiting fullscreen, the first reflow (which goes through SimpleResizeReflow and marks children dirty) happens before the content viewer size is updated. So when that reflow happens, and the MVM is asked to update its display size here, the display size doesn't actually get updated. Eventually the content viewer size is updated, and the subsequent reflow causes the MVM to update its display size to the new value. However, that reflow bounces out of this condition and so never does a reflow on the root scrollframe. Therefore nothing ends up triggering the MVM to update its visual viewport size.

One possible solution here is to ensure the content viewer size is updated before that first reflow, but that seems like a possibly risky change. A more tightly scoped change would be to ensure we refresh the visual viewport size after doing a reflow where we know the MVM's display size changed. This visual viewport size update will be redundant in the cases where the root scrollframe was reflowed, but if it wasn't, it will act as a failsafe to ensure the visual viewport size is correct.

Comment 17

[Kartikaya Gupta (email:[e-mail])]

A more tightly scoped change would be to ensure we refresh the visual viewport size after doing a reflow where we know the MVM's display size changed.

Tried this, and it didn't fix the bug. Possibly because the resize event is fired before this reflow. Emilio thinks the content viewer size should be updated before that first reflow so I'll look into that approach.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Following emilio's suggestion I made PrepareForFullscreenChange set the size on the contentviewer instead of the viewmanager, so that the updated size is available for the first reflow. That fixed the problem for me.

Try push to verify tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=935959699c19c004ad92fd6080fd30fd455a3c04

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1656223 - When exiting fullscreen, ensure the content viewer size is updated before first reflow. r?emilio

Instead of getting/setting the size on the view manager on a fullscreen
change, this updates the code to get/set the size on the content viewer, which
internally sets the size on the view manager. Doing this ensures that the
content viewer size is updated prior to the reflow, which is required for
the MobileViewportManager to update its internal notions of size and to update
the visual viewport properly.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0b3e25d09ce8
When exiting fullscreen, ensure the content viewer size is updated before first reflow. r=emilio

Comment 21

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/0b3e25d09ce8

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Going to mark this as wontfix for 80 since the patch does carry some risk and seems to only manifest in rare conditions.

Alice, can you please verify the nightly builds with the patch fixes the problem for you?

Comment 23

[Alice0775 White]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #22)

Going to mark this as wontfix for 80 since the patch does carry some risk and seems to only manifest in rare conditions.

Alice, can you please verify the nightly builds with the patch fixes the problem for you?

I can reproduce the issue on Nightly81.a1(20200815211739) Windows10.
And I verified fix and no longer reproduced the issue on Nightly81.a1(20200816214203) Windows10.

Comment 24

[Cletus Van Damme]

I also can no longer reproduce it with 81.0a1 20200816214203. Thank you for your work on this issue.

Comment 25

[Kartikaya Gupta (email:[e-mail])]

Great, thanks!