Closed Bug 1504865 Opened 6 years ago Closed 3 years ago

The page is visible behind fullscreen element after displayport expires

Categories

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

65 Branch
ARM
Android
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
geckoview64 --- wontfix
geckoview65 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix

People

(Reporter: csheany, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [geckoview:p2])

Attachments

(4 files)

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.
Attached image Screenshot_20181105-170547.jpg —
Tapping the screen briefly restores the intended state.
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!
Flags: needinfo?(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?
Flags: needinfo?(csheany)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → ARM
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.
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
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.
Attached image Screenshot_20181128-125424.jpg —
For a non YouTube example https://introducinghtml5.com/examples/ch04/ch4-full-fallback.html This uses the native controls.
Attached image Screenshot_20181128-155417.jpg —
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.
Over to media for more triage.
Component: GeckoView → Audio/Video: Playback
Product: Firefox for Android → Core
Version: Firefox 65 → 65 Branch
I think Randall has additional context for this bug.
Flags: needinfo?(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
Flags: needinfo?(rbarker)
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?
Chun-min, can you triage this?
Flags: needinfo?(cchang)
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.
Component: Audio/Video: Playback → Audio/Video
Flags: needinfo?(cchang)
Product: Core → Firefox for Android
Version: 65 Branch → Firefox 65
Hi Imanol, is it possibly related to the change of bug 1498246 ?
Component: Audio/Video → GeckoView
Flags: needinfo?(imanol)
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).
Flags: needinfo?(imanol)
Product: Firefox for Android → GeckoView
Version: Firefox 65 → 65 Branch
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?
Flags: needinfo?(xidorn+moz)
Attached image Screenshot_20181230-193450.jpg —
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.
Flags: needinfo?(xidorn+moz)
Product: GeckoView → Core
If it's reliably reproducible with attachment 9018847 [details], it might be easiler to check this page, since it's much simpler than youtube.
What about with the example from Comment 10?
(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).
Summary: The page is visible behind fullscreen video → The page is visible behind fullscreen element
Whiteboard: [geckoview:p2]
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...
Component: General → Graphics
This seems to be related to the displayport expiry. (That's the 15-second delay before the issue occurs)
Component: Graphics → Panning and Zooming
Summary: The page is visible behind fullscreen element → The page is visible behind fullscreen element after displayport expires

Botond, would you be able to patch this?

Flags: needinfo?(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.

Flags: needinfo?(botond)

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?

Flags: needinfo?(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.

Blocks: 1298218
Flags: needinfo?(botond) → needinfo?(mstange)

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

Flags: needinfo?(tnikkel)
Flags: needinfo?(matt.woodrow)

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

Flags: needinfo?(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.

Flags: needinfo?(botond)
Depends on: 1158392

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

Flags: needinfo?(matt.woodrow)
Flags: needinfo?(tnikkel)
Flags: needinfo?(mstange)

Restoring the flag to get your thoughts.

Flags: needinfo?(mstange)

No thoughts needed. This is waiting for containerless scrolling.

Flags: needinfo?(mstange)

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?

(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.

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

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

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

Thank you Markus :)

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.

(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.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

I wish that were the case but unfortunately not yet.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

(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.

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.

See Also: → 1607096

Is anyone still experiencing this issue?

I tried the test page from comment 21, as well as those in the two duplicate bugs (bug 1384512 and bug 1560818), in recent Fenix and GeckoView Example, and could not reproduce them. (I also tried using mozregression to see what fixed it, but it looks like builds only go back one year, and GVE from one year ago does not exhibit the bug either.)

It doesn't seem that I can reproduce this issue now either.

maybe this got fixed when releasing Fenix (no Bugfix commit, just different code)

Let's close this. If anyone can still reproduce it in a recent Fenix version, please chime in and we can reopen.

Status: REOPENED → RESOLVED
Closed: 6 years ago3 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: