1479262 - Video fullscreen exit causing scroll position to change

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Michael Webb]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180728220145

Steps to reproduce:

I can reproduce by following these steps:

1. Open https://jsfiddle.net/webbm/p8ws3yc9/
2. Scroll to furthest down (2 of 2) video element.
3. Mark the number showing at the top of the screen (for ease of verification).
4. Open video element in fullscreen.
5. Exit fullscreen.
6. Mark the number showing at the top of the screen. This is less than before.

Note: First video element in the example page does NOT cause this behaviour.


Actual results:

Scroll position of body changed after exiting fullscreen.


Expected results:

Scroll position of body should not change after exiting fullscreen.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f1f82e673a3490bb572c3a1110eeded81badb9a9&tochange=c6dfe20cbb8acd87f7f5a27d14e22fbf8731aa78

Suspect; Bug 1201798


:xidorn,

Your bunch of patch seems to cause the problem, could you look into this?

Comment 2

[Xidorn Quan [:xidorn] UTC+11]

So this happens because the fullscreen element is close to the bottom of the page, and when the document becomes fullscreen, the scroll position is clamped to a smaller value.

This is similar to what happens with the following steps:
1. ensure the window is in normal state (not maximized)
2. scroll the page to the bottom and mark the number showing at the top
3. maximize the window
4. restore the window to normal state

You would also see the scroll position to be affected.

If we want to fix this, we probably need to record the scroll position of the document before entering fullscreen when the fullscreen element is not the root element, and restore it when exit.

It's interesting that, before bug 1201798, we also clamp the scroll position, but it somehow gets restored after exit. It's not clear to me how we managed to do that...

(Since this is about scroll position, I suppose it is more related to DOM than layout.)

Comment 3

[Alice0775 White]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> So this happens because the fullscreen element is close to the bottom of the
> page, and when the document becomes fullscreen, the scroll position is
> clamped to a smaller value.
> 
> This is similar to what happens with the following steps:
> 1. ensure the window is in normal state (not maximized)
> 2. scroll the page to the bottom and mark the number showing at the top
> 3. maximize the window
> 4. restore the window to normal state
> 
> You would also see the scroll position to be affected.
> 

The above steps is also reproduce before landing bug 1201798. so, this is different problem from this bug.

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

I didn't say they are the same issue. I just analogized that to show how it happens.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 63, but we could still take a patch in 65 and potentially, 64 beta.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.

Comment 7

[nivtwig]

In addition, the horizontal scroll position is not restored to the original horizontal position. The original report mentioned only the vertical scroll position.
Please raise priority of the bug and fix this ASAP, as it is very annoying in this common scenario:

1. Watching a video in a "small", not maximized window
2. Maximizing frequently and repeatedly the video to full-screen in order to seek back to another time of the video easily (since the time bar cannot be clicked easily in order to seek to the right time, in the small window), in case you missed hearing/watching the video for a small time. I cannot always use the back-arrow to seek back, since it conflicts with several sites, therefore I must use a mouse click to seek to the right time.
   Everytime you do this, you have to repeatedly adjust the vertical and horizontal position of the video in the non-maximized window.

Comment 8

[will]

Any updates on this? This behavior still occurs under firefox 124.0.1