1396732 - vimeo.com - Video is truncated in full-screen mode, when entered from "sticky" small player

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[roxleitan]

Attachment: video.png

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170904220027

[Affected versions]:
Nightly 57.0a1, Beta 56.0b8

[Affected platforms]:
Windows 10 x 64, Mac OS X 10.12

[Steps to reproduce]:
1.Launch Nightly 57.0a1 with a new profile
2.Go to https://vimeo.com/231359473
3.Scroll down
4.Click "Enter full screen" button on the video located at left top corner

[Expected result]:
Video should be opened in full-screen mode without issues

[Actual result]:
Video is truncated in full-screen mode

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Do we know if this is a regression from 55?

Comment 2

[roxleitan]

This is not a regression from 55.
good build: 2016-06-04 Firefox 49.0a1
bad build:  2016-07-01 Firefox 50.0a1

I will investigate regression range asap.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

ni? is for comment #2

Comment 4

[Cristina Badescu [:cbadescu], Experiments QA]

Hello,

I have tried to find the regression range using MozregRession tool. Here are the results:

Last good revision: d700dc054751333e0735f975fce3d3adf153c62a (2016-06-30)
First bad revision: fdcee57b4e4f66a82831ab01e61500da98a858e8 (2016-07-01)
Pushlog: https://goo.gl/GkA4jA
I couldn't go further because because these builds are too old and MozRegression cannot provide them.

Xindorn Quan, I've noticed you fixed related bugs concerning full screen issues. Can you please take a look at this issue to see if it's related to one of your issues?

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

I'm not sure exactly which change triggers this, but it seems to me that the reason is, there is a blocking element (the container of "Like" "Follow" "Share") which covers the majority of the video area.

The blocking element is removed on Chrome and early version of Firefox because the site uses the following code:
> var scroll_pos = window.scrollY || window.pageYOffset;
> var minibar_visible = scroll_pos >= this.scroll_limit;
> var should_update = minibar_visible !== is_mini;
> if (!should_update) {
>     return
> }
> _PlayerActions2.default.toggleMinibar(minibar_visible)
and window.scrollY becomes zero when entering fullscreen, so the minibar is removed.

In later version of Firefox, scrollY keeps being the old value, so the blocking element remains there.

I don't think there is any change in that range intends to change this behavior. It might be a side effect of some fullscreen-related changes. It is also not clear to me which behavior is better.

Comment 6

[Xidorn Quan [:xidorn] UTC+11]

OK, so the reason of scrollY change on Chrome and early version of Firefox is different.

Chrome always changes scrollY to zero whenever entering fullscreen, which is probably because they are still using the old position/z-index based implementation. I suspect they would change to match our behavior once they finish the top layer impl.

The reason of scrollY change in early version of Firefox is because they have the following CSS rule:
> :-moz-full-screen-ancestor>:not(:-moz-full-screen-ancestor):not(:-moz-full-screen) {
>  display:none!important
> }
which intends to hide everything outside fullscreen, and thus the page becomes not scrollable.

But :-moz-full-screen-ancestor is removed in bug 1199529 (in that regression range), and thus this no longer works.

I'm not sure whether we should bring back :-moz-full-screen-ancestor given that we no longer need to do bug 1195213. But this is not part of the Fullscreen API spec anyway.

This may be something Chrome would see eventually when they fully implement the new top layer based fullscreen, and unship :-webkit-full-screen-ancestor.

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

Filed https://github.com/whatwg/fullscreen/issues/103 for the spec discussion.

Comment 8

[Xidorn Quan [:xidorn] UTC+11]

I tend to say that this is a site issue, since I think our behavior is reasonable in general, and Chrome is also going to ship top layer and unship fullscreen ancestor pseudo-class.

Basically, relying on using :fullscreen-ancestor to remove everything outside fullscreen element so that scrollY can become zero to trigger hiding elements doesn't sound like a sensible approach.

Comment 10

[Mike Taylor [:miketaylr]]

Adam, can you get in touch with Vimeo on the ML about this please?

Comment 11

[Adam Stevenson [:adamopenweb]]

Reaching out on the Vimeo mailing list.

Comment 12

[Mike Taylor [:miketaylr]]

Oana, can you test if this still reproduces please?

Comment 13

[Oana Arbuzov [:oanaarbuzov]]

Tested the issue and I can't reproduce it. For me the video is displayed on the entire screen.

[Tested with:]
rowser / Version: Firefox Nightly 63.0a1 (2018-08-09)
Operating System: Windows 10 Pro

@Roxana can you still reproduce the issue?

Comment 14

[roxleitan]

Attachment: vimeo.png

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

Tested on Win 10 with the latest Nightly 63.0a1(20180812220618).

Comment 15

[laszlo.bialis]

Hi,

The issue reproduces on the latest Nightly 65.0a1 Build ID: 20181030224027, on all OS's (Win 10 x64, Win 8.1 x64, Win7 x32, Ubuntu 18.04 x64, macOS 10.13). 

After step 4. ("Enter full screen" button on the video located at left top corner) the image attached in Comment 14 is shown, but the sound keeps on playing.

On Chrome the issue is not reproducible.

Mike, Oana, shouldn't we reopen the issue based on comment 14 and the current findings?

Comment 16

[Mike Taylor [:miketaylr]]

Yes, I can reproduce now. Interesting.

Comment 17

[Oana Arbuzov [:oanaarbuzov]]

@laszlo.bialis, the issue reported by Roxana stated that the video was truncated (video.png), which no longer happens. 
Probably as a consequence of a fix, now the "Like/Follow/Share" overlay fully overlaps the video (vimeo.png).

Workaround: Clicking "Share" button the video is displayed.

[Tested with:]
Browser / Version: Firefox Nightly 65.0a1 (2018-11-01)
Operating System: Windows 10 Pro

Comment 18

[laszlo.bialis]

Indeed the video is not truncated anymore, however the "[Expected result]: Video should be opened in full-screen mode without issues" is not met at this point, as such reopening the issue seemed to be better than filing a new bug.

Comment 19

[Timea Cernea [:tbabos][inactive]]

Reproduced on latest Nightly 66.0a1 (2018-12-18) on Mac OS 10.14 with the actual result from Comment 17.

Comment 20

[Tim Spurway [:tspurway]]

:mtaylor should this be in a different component?

Comment 21

[Mike Taylor [:miketaylr]]

(In reply to Tim Spurway [:tspurway] from comment #20)
> :mtaylor should this be in a different component?

Probably not -- this is something Vimeo needs to fix.

Adam, can we re-ping Vimeo?

Comment 22

[Adam Stevenson [:adamopenweb]]

Reaching out to some folks at Vimeo. I also mentioned this issue recently on a call we had with them.

Comment 23

[Adam Stevenson [:adamopenweb]]

The issue has been logged with the right team at Vimeo.

Comment 24

[Neha Kochar [:neha]]

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Comment 25

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 26

[Marcela (Please NI request to Brindusa Tot)]

Reproducible in Windows10
Version 68.0a1
Build ID 20190513215004
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Comment 27

[Liviu Seplecan]

Reproducible in Windows 7
Version 69.0a1 from the 11th of June
Build ID 20190610214846
User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:69.0) Gecko/20100101 Firefox/69.0

Comment 29

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

Mike, do you want to take one more shot at asking Vimeo about this bug?
We're setting the flags to fix-optional across the board to let this bug fall out of weekly regression triage.

Comment 30

[Mike Taylor [:miketaylr]]

No problem, I just pinged the thread there.

Comment 31

[Mike Taylor [:miketaylr]]

To follow up: this is on a Vimeo engineer's TODO list. 👍

Comment 32

[Raul Bucata]

The issue is reproducible if the full-screen mode is enabled from the upper left side of the video top banner card:

https://prnt.sc/d5b-9AGV3wOQ
https://prnt.sc/_ayDC0LApLpH

Tested with:

Browser / Version: Firefox Nightly 100.0a1 (2022-03-31) (64-bit) / Chrome Version 100.0.4896.60 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Comment 33

[Barret Rennie [:barret] (they/them)]

:karlcow any updates on this from Web Compat?

Comment 34

[Karl Dubost💡 :karlcow]

Let's check on the vimeo mailing-list

My impression is the -webkit-full-screen-ancestor is not the full story.

On Safari the icons are set on the top right side and the blue icons fully disappear. So something is removed from the DOM. after calling toggleMinibar

                function a(e, t) {
                    if (Array.isArray(t)) {
                        var n = t[1];
                        t = t[0],
                        u(e, t, n),
                        e.removeChild(n)
                    }
                    e.removeChild(t)
                }

in safari we get:

<div class="vp-outro-wrapper hidden" hidden=""><div class="vp-outro" role="dialog"></div></div>

AND when in Safari I create a local override removing from the css the :-webkit-full-screen-ancestor rules, it still works in Safari.

Comment 35

[Karl Dubost💡 :karlcow]

I contacted them again.

Comment 36

[Dennis Schubert [:denschub]]

This is an important site and we don't really know what's going in. WebCompat Priority P1 for now, and a needinfo for Ksenia to see if she can figure out more!

Comment 37

[Ksenia Berezina [:ksenia]]

From what I can tell, what Xidorn describing in comment https://bugzilla.mozilla.org/show_bug.cgi?id=1396732#c6 is still happening. JS code has changed a bit, however logic remained the same. The element with class .outro is removed from the DOM based on this condition:
o !== i && b.a.toggleMinibar(o) in:

      {
        key: '_checkScroll',
        value: function () {
          var e = this.props,
          t = e.clip,
          n = e.content_block_status,
          r = e.copyright_status,
          i = e.is_mini;
          if ('fixed' !== window.getComputedStyle(document.body).position && !(n.is_blocked || r.is_blocked || t.is_unavailable)) {
            var o = (window.scrollY || window.pageYOffset) >= this.scroll_limit;
            o !== i && b.a.toggleMinibar(o)
          }
        }
      },

and :-webkit-full-screen-ancestor/:fullscreen-ancestor css is still present in css.

Comment 38

[Ksenia Berezina [:ksenia]]

Attachment: 1396732.html

I've attached a reduced test case. To reproduce, scroll down to the "fullscreen" button and click on it.

AND when in Safari I create a local override removing from the css the :-webkit-full-screen-ancestor rules, it still works in Safari.

Indeed in Safari, having :-webkit-full-screen-ancestor has no effect (windox.scrollY is always 0 regardless of this style rule presence).

So, to summarize the following values are in fullscreen:
Firefox: window.scrollY has old value, :fullscreen-ancestor has no effect
Chrome: window.scrollY has old value unless :-webkit-full-screen-ancestor rule is present
Safari: window.scrollY has 0 regardless of :-webkit-full-screen-ancestor rule

Comment 39

[Ksenia Berezina [:ksenia]]

I'll try to come up with a temporary intervention to alleviate the issue.

Comment 41

[Shlomo Morosow]

We've just released a fix for this at Vimeo.
Apologies for this taking so long and thanks for your help and analysis.
Cheers!

Comment 42

[Ksenia Berezina [:ksenia]]

Thank you Shlomo, appreciate it!