Open Bug 1504865 Opened 2 years ago Updated 4 months ago
The page is visible behind fullscreen element after displayport expires
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.
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!
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?
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.
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.
For a non YouTube example https://introducinghtml5.com/examples/ch04/ch4-full-fallback.html This uses the native controls.
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.
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. 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.  https://searchfox.org/mozilla-central/source/mobile/android/chrome/geckoview/GeckoViewSettingsChild.js#72
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?
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
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
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).
2 years ago
Priority: -- → P3
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?
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.
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).
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
Flags: needinfo?(botond) → needinfo?(mstange)
2 years ago
Duplicate of this bug: 1384512
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
4 months ago
See Also: → 1664906
You need to log in before you can comment on or make changes to this bug.