1504865 - The page is visible behind fullscreen element after displayport expires

Status: REOPENED

(Core :: Panning and Zooming, defect, P3)

Description

[csheany]

User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0

Steps to reproduce:

1. Open YouTube
2. Request desktop site
3. Play a video
4. Enter fullscreen


Actual results:

With the video in portrait mode the page the appears underneath. Landscape doesn't seem to be affected.


Expected results:

The screen should remain as it was when fullscreen was first entered.

Comment 1

[csheany]

Attachment: Screenshot_20181105-170547.jpg

Comment 2

[csheany]

Tapping the screen briefly restores the intended state.

Comment 3

[Sorina Florean [:sflorean]]

Thanks for the report!
Tried to reproduce this issue following the steps from comment 0 with Sony Xperia Z2(Android 6.0.1) and Samsung Galaxy Tab S3(Android 8.0) and the video performed well in fullscreen, no visual issues was displayed. 
I did find the bug 1377873 while testing. 

Could you please make a video to see if there are some additionals steps? Is reproducible all the time? Thanks again!

Comment 4

[csheany]

Thank your for looking into it.

It seems to happen on a consistent basis.

Can you confirm that the desktop site was tested?

Did you have any issues with the controls?

Comment 5

[Stefan Deiac]

Hi csheany, I tried to reproduce your issue using your steps from comment 0 and I can confirm this issue on all branches: Nightly 65.0a1 (2018-11-25), Beta 64.0b12 and Release 63.0.2.
It seems to be reproducible on both phone/tablet.
After entering on the fullscreen, if I scroll the page, it seems to be scrollable.
Devices: Nexus 5 (Android 6.0.1), OnePlus 5T(Android 8.1.0), Sony Xperia Z5 (Android 7.0), Samsung Galaxy Note 9 (Android 8.1), Samsung Galaxy Tab S3 (Android 8.0), Sony Xperia Z2(Android 6.0.1) and Nexus 9 (Android 6.0.1).
Not reproducible on Google Pixel (Android 9).
Based on that, I'll make the issue as New.

Comment 6

[csheany]

Thank you for looking into it.

I believe the scrolling functionality is intended based on the hint in the controls.

This is referring to more of a flicker.

Comment 7

[csheany]

To reproduce without the scrolling element:

1. Open https://www.youtube.com/embed/09XmbByy6Sk
2. Request desktop site
3. Play the video
4. Enter fullscreen

Comment 8

[csheany]

The issue is that a backward L chunk is removed.

In the case above the "page" is a black background not to be confused with the standard placeholder above and below.

Comment 9

[csheany]

Attachment: Screenshot_20181128-125424.jpg

Comment 10

[csheany]

For a non YouTube example

https://introducinghtml5.com/examples/ch04/ch4-full-fallback.html

This uses the native controls.

Comment 11

[csheany]

Attachment: Screenshot_20181128-155417.jpg

Comment 12

[Stefan Deiac]

Hi, I can confirm the second scenario on both portrait/landscape mode using your links. The issue occurs only after few seconds after putting the video in fullscreen mode. Reproducible on all branches(Nightly, Beta, Release) with: OnePlus 5T (Android 8.1.0) and Nokia 6 (Android 7.1.1)
Note: Not reproducible on Chrome.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

Over to media for more triage.

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

I think Randall has additional context for this bug.

Comment 15

[Randall Barker [:rbarker]]

We see this same issue in Firefox Reality when requesting a desktop version of a site. I believe it may have something to do with the desktop viewport[1]. What seems to be happening is the element going fullscreen doesn't actually cover the entire screen and the page behind is visible. One possible cause is the screen size which is only reported at start up for android, but can actually change if the device is switched from portrait to landscape mode.

[1] https://searchfox.org/mozilla-central/source/mobile/android/chrome/geckoview/GeckoViewSettingsChild.js#72

Comment 16

[csheany]

In my experience it is covered initially and occurs after a few seconds.

I wonder if...

The video format itself could be a factor?

The metadata hasn't loaded?

Maybe it wants to switch to landscape when in portrait?

Comment 17

[Andreas Pehrson [:pehrsons]]

Chun-min, can you triage this?

Comment 18

[C.M.Chang[:chunmin] (PTO)]

If it's an media codec issue, it should be reproducible on the desktop. I couldn't reproduce it on the desktop, so I guess the problem might be in requestFullscreen API or on the front-end side.

Comment 19

[C.M.Chang[:chunmin] (PTO)]

Hi Imanol, is it possibly related to the change of bug 1498246 ?

Comment 20

[Imanol Fernandez]

Hi Chun, it shouldn't be related to bug 1498246. That API only listens to media events, but doesn't mutate anything, and is probably is disabled (we only use it in Firefox Reality AFAIK).

Comment 21

[csheany]

I also reproduce this on the test page from Bug 1500719.

https://bug1493976.bmoattachments.org/attachment.cgi?id=9018847

Xidorn, do you have any thoughts?

Comment 22

[csheany]

Attachment: Screenshot_20181230-193450.jpg

Comment 23

[Xidorn Quan [:xidorn] UTC+11]

I cannot reproduce it on my Android phone with Beta following steps in comment 0. Is this reproducible without any addons?

Looking at the screenshot, this may not be a GeckoView issue, but more likely a graphics issue or a layout issue. For people who can reproduce, it's worth using remote debugging tool to check the geometry of the video element to see what's happening on the page.

Comment 24

[Xidorn Quan [:xidorn] UTC+11]

If it's reliably reproducible with attachment 9018847 [details], it might be easiler to check this page, since it's much simpler than youtube.

Comment 25

[csheany]

What about with the example from Comment 10?

Comment 26

[Chris Peterson [:cpeterson]]

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #24)
> If it's reliably reproducible with attachment 9018847 [details], it might be
> easiler to check this page, since it's much simpler than youtube.

I can reproduce this bug on my Moto G5 Plus in Fennec, but not Focus + GeckoView 64. I'm using that simpler test case, so this is not a video problem. Due to the consistent timing and shape of the white portion of the page, this feels like a graphics invalidation problem.

In Fennec 65 Beta and 66 Nightly, the test enters full screen, all purple as expected. After about 10 seconds, the right and bottom halves of the page turn from purple to white. If I tap the page, the white portion turns purple again. After 10 more seconds, the white portion returns.

In Fennec 64, the test enters full screen, but the address bar is still visible. After about 10 seconds, the address bar disappears. After about 5 more seconds, the right and bottom halves of the page turn from purple to white (as in Fennec 65 Beta and 66 Nightly).

Did Fennec 65 change how the address bar works in full screen? It's interesting that the wait for the page to turn purple happens after the address bar disappears, not after the page first enters "full screen" (when the page is all purple but the address bar is still visible).

Comment 27

[Xidorn Quan [:xidorn] UTC+11]

Oh, I can reproduce what is described in comment 26 that after waiting for 10s large portion of the page becomes white.

This indeed feels like a graphics problem... so moving it there for now. I don't think in fullscreen related code should be changing anything after 10s.

On my device (Xperia XZ), the purple area shrinks to 397x705 (from 1080x1920), which is a ratio of ~2.7x. It doesn't seem to match any number really...

Comment 28

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

This seems to be related to the displayport expiry. (That's the 15-second delay before the issue occurs)

Comment 29

[csheany]

Botond, would you be able to patch this?

Comment 30

[Botond Ballo [:botond]]

It's something I can investigate, but my queue is full with other higher-priority tasks, so it will be a while before I get to this.

Comment 31

[csheany]

I think I tracked down the regression.

The last good build was Nightly 54.0a1 (2017-02-02)

The first bad build was Nightly 54.0a1 (2017-02-03)

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f985243bb630&tochange=2aede0a97bc6

Would you mind taking a quick look?

Comment 32

[Botond Ballo [:botond]]

Thanks for getting a regression window.

In that window, bug 1298218 jumps out as a potential regressing bug, as it is a significant change and has caused a number of other scrolling-related regressions over time. I'm tentatively marking this as blocking bug 1298218 and needinfoing Markus.

Comment 33

[csheany]

Matt or Timothy, would either of you mind taking a look?

Comment 34

[Matt Woodrow (:mattwoodrow)]

Botond, are you able to check if this is fixed by containerless scrolling for Android?

Comment 35

[Botond Ballo [:botond]]

Testing on https://bugzilla.mozilla.org/attachment.cgi?id=9018847, I can reproduce the issue in the latest nightly, and not with containerless scrolling, so yes, I would say this is potentially fixed by containerless scrolling.

Comment 36

[Matt Woodrow (:mattwoodrow)]

Great, let's wait for that to land then, rather than investing time into debugging code we're trying to get rid of.

Comment 38

[csheany]

Restoring the flag to get your thoughts.

Comment 39

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

No thoughts needed. This is waiting for containerless scrolling.

Comment 40

[csheany]

I understand the logic.

I was just thinking about the releases without it while it rides the trains.

Also, what is the purpose of displayport expiration?

Comment 41

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

(In reply to csheany from comment #40)

I was just thinking about the releases without it while it rides the trains.

We're not going to fix it in those releases. It's not a good use of time to try doing that, as we have a lot of other things that need fixing too.

Also, what is the purpose of displayport expiration?

To save memory when the user is not actively scrolling. Having a displayport on a scrollframe uses up a bunch of memory.

Comment 42

[csheany]

I guess a part of me wants to hear what he has to say.

Here's to Nightly 67.0a1 (2019-03-08) :)

Comment 43

[Markus Stange [:mstange]]

I agree with kats, containerless scrolling is the "right" way to fix this, and it's happening.

Comment 44

[csheany]

Thank you Markus :)

Comment 45

[Xidorn Quan [:xidorn] UTC+11]

As I mentioned in bug 1500719 comment 34, I tested layout.scroll.root-frame-containers (flip it back and forth in nightly) and it seems to me that containerless scrolling does fix this issue.

Comment 46

[Pascal Chevrel:pascalc]

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #45)

As I mentioned in bug 1500719 comment 34, I tested layout.scroll.root-frame-containers (flip it back and forth in nightly) and it seems to me that containerless scrolling does fix this issue.

Given that Containerless scrolling landed with 67, I am going to mark this bug as fixed.

Comment 47

[csheany]

I wish that were the case but unfortunately not yet.

Comment 48

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #35)

Testing on https://bugzilla.mozilla.org/attachment.cgi?id=9018847, I can reproduce the issue in the latest nightly, and not with containerless scrolling, so yes, I would say this is potentially fixed by containerless scrolling.

Re-testing on the same page, I can confirm that this still affects recent nightlies, even though we now have containerless scrolling.

It would be interesting to find out what regressed it with containerless scrolling enabled.

Comment 49

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Happy to take a patch for 70 but since this is triaged and set to P3 priority I'm setting it as fix-optional.
That will remove the bug from weekly regression triage.