1440921 - v.youku.com: unable to enter fullscreen

Status: RESOLVED FIXED

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

Description

[Madper Xie]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180223100113

Steps to reproduce:

1. open http://v.youku.com/v_show/id_XMzQxODc3NjcyNA==.html?spm=a2hww.20027244.m_250473.5~5!2~5~5!2~5~5~A&f=51529458
2. The video will start automatically
3. Double click the video


Actual results:

After the double-click, the screen will be full size but then go back to smaller size...


Expected results:

It should keep the full size.

(In fact I tested google-chrome which works well.)
(Ps: I'm using 60.0a1 (2018-02-23) (64-bit))
(Pps: I'm using archlinux with 4.15 kernel.)

Comment 1

[Ralph Giles (:rillian)]

Thanks for the report!

I can reproduce, but note I had to disable my ad blocker to get past a cookie check before the video would play. Fullscreen works fine in Safari and Edge; in Firefox it expands to fullscreen, and then immediately shrinks back to the original layout, as described.

This isn't a playback problem, it's an issue with their dom events or element transitions. Passing to DOM for further diagnosis.

Comment 2

[Anne (:annevk)]

Mike, seen this before?

Comment 3

[Mike Taylor [:miketaylr]]

Interesting, this WFM in OSX/Nightly, but in Ubuntu/Nightly it does indeed reproduce.

In the console:

TypeError: window.event is undefined

And in http://g.alicdn.com/player/ykplayer/0.5.31/youku-player.min.js:

this._el.addEventListener('click', function() {
    t.isMenueShow ? t.hideMenu() : t._clickTimer.set(function() {
            t._video.ykplayer.switchPlayPause()
        }),
        window.event.returnValue = !1
}),

This might be one of the few Event.returnValue bugs we've gotten, I'll file an implementation bug for that.

(I get that same TypeError in Ubuntu... so possibly not the root cause?)

Comment 4

[Mike Taylor [:miketaylr]]

> (I get that same TypeError in Ubuntu... so possibly not the root cause?)

(s/Ubuntu/Mac/)

Here's the fullscreen/dblclick code:

this._el.addEventListener('dblclick', function () {
  t._clickTimer.clear(), 
  t._video.ykplayer.switchFullscreen()
}),

{
  key: 'switchFullscreen',
  value: function () {
    if (this.global.initConfig.disablefullScreen) return !1;
    this.global.playerState.fullscreen ? this.exitFullscreen()  : this.fullScreen()
  }
},

Hm, I see it hits the window.event.returnValue TypeError right before the dblclick handler is bound, but still not sure how this is is fine in OSX.

Comment 5

[Mike Taylor [:miketaylr]]

(also, it seems doubleclick is a red herring, clicking the fullscreen button in the player UI results in the same reported behavior)

Comment 6

[Mike Taylor [:miketaylr]]

So, I was wrong about there being a difference between Mac and Linux/Windows. I just happened to be testing different channels... that's the meaningful difference (doh!)

non-RELEASE_OR_BETA sets "full-screen-api.unprefix.enabled" to true (presuably so we can find these bugs):

https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.h#87-92

So, testing Mac on DevEdition, I get EXPECTED RESULTS. But Nightly on Windows/Linux, I get ACTUAL RESULTS. And if I flip the pref in DevEdition, the bug manifests as well.

The bug boils down to a module that sets up event listeners for this "half screen" button (which I think is just the "exit fullscreen" button, based on the icon itself):

I'm gonna omit some stuff so it's easier to digest:

First, it sets listeners for fullscreen change events:

document.addEventListener("webkitfullscreenchange", n, !1),
document.addEventListener("mozfullscreenchange", n, !1),
document.addEventListener("fullscreenchange", n, !1),
document.addEventListener("MSFullscreenChange", n, !1),

The n handler is defined as follows:

function n(evt) {
  var e = function() {
    r.hide(),
      r._args.onHalfFullscreen && "function" == typeof r._args.onHalfFullscreen
        ? t.onHalfFullscreen()
        : r._video.exitFullscreen();
  };
  !1 === document.webkitIsFullScreen
    ? e()
    : !1 === document.mozFullScreen
      ? e()
      : !1 === document.msFullscreenElement ? e() : document.fullscreen && e();
}


So n defines a function e, that checks to make sure the r._args.onHalfFullscreen property exists, and is a function (it is, I checked), then calls t.onHalfFullscreen.

That in turn calls e.exitFullscreen:

onHalfFullscreen: function() {
  e.exitFullscreen();
}

Which looks like:
{
  key: "exitFullscreen",
  value: function() {
    z.default.removeClass(this._playerfilm, "fullscreen"),
    this._fullScreenPlugin.exitFullscreen(),
    this._player.control.emit("fullscreen", !1);
  }
},

And this._fullScreenPlugin.exitFullscreen() looks like:

{
  key: "exitFullscreen",
  value: function() {
    if (
      ((this.isfullScreen = !1),
      this.container.removeAttribute("style"),
      (l.browser.isIE && l.browser.version < 10) || this.innerScreen)
    )
      return void this.exitFullscreenInPage();
    document.exitFullscreen
      ? document.exitFullscreen()
      : document.msExitFullscreen
        ? document.msExitFullscreen()
        : document.mozCancelFullScreen
          ? document.mozCancelFullScreen()
          : document.webkitExitFullscreen
            ? document.webkitExitFullscreen()
            : this.exitFullscreenInPage();
  }
};

So, it just calls regular DOM methods.

Back up to n, before e even gets called, it does some checks to see if it's currently in fullscreen already:

!1 === document.webkitIsFullScreen
    ? e()
    : !1 === document.mozFullScreen
      ? e()
      : !1 === document.msFullscreenElement ? e() : document.fullscreen && e();

So, for prefixed fullscreen browsers, if it's *not* fullscreen, exit fullscreen (wat). 

But in this case, it will be fullscreen, so it doesn't close it immediately.

And for unprefixed browsers, if it *is* fullscreen, also exit fullscreen (double wat). And this is the bug.

To fix it, or at least make it consistent you would want a similar !1 === document.fullscreen && e() check, I guess.

Xidorn, just to check, outreach to Youku seems like the right thing to do here, right?

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

Thanks for the analysis!

Given that code, I think the right thing is to outreach to Youku for this.

Comment 9

[Mike Taylor [:miketaylr]]

Oana, can you double check if this still repros? If so, we should needinfo? Adam, and see if he can help find someone in the China community for outreach.

Comment 10

[yxu]

(In reply to Mike Taylor [:miketaylr] from comment #9)
> Oana, can you double check if this still repros? If so, we should needinfo?
> Adam, and see if he can help find someone in the China community for
> outreach.

Hi Mike, I have tried to contact Youku for repairs, but as of now I haven’t received a reply yet. And I will continue to follow this up.

Comment 11

[Mike Taylor [:miketaylr]]

Thanks yxu!

Comment 12

[Oana Arbuzov [:oanaarbuzov]]

The issue is still reproducible.

[Tested with]
Browser / Version: Firefox Nightly 62.0a1 (2018-05-16)
Operating System: Linux Ubuntu 16.04

Comment 13

[Karl Dubost💡 :karlcow]

Duplicate of an existing issue on webcompat.

Comment 14

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Changing title as this impacts all platforms and want that to be clear as we're marking other bugs as dupes of this.

Comment 16

[Xidorn Quan [:xidorn] UTC+10]

This has been fixed by Youku, FWIW, on Sept last year.