Cannot be fullscreen Gyao! high protection level(DRM) video on nightly build

NEW
Unassigned

Status

()

defect
P3
normal
2 years ago
2 months ago

People

(Reporter: alice0775, Unassigned)

Tracking

Trunk
x86_64
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
The problem is not reproduced on release and beta build.
And this seems in nightly build only problem.(I can reproduce the problem in nightly build at least since 2016-Jun-01.)


Reproducible : always

Steps To Reproduce:
1. Open a video (High protection level(DRM) video)
   test video: https://gyao.yahoo.co.jp/player/00590/v12121/v1000000000000000837/?auto=1&rep=2&ap_cnt=2&second=0
2. Click fullscreen icon in video controls

Actual Results:
Nothing happens

Expected Results:
Turn to Fullscreen
(Reporter)

Updated

2 years ago
Summary: Cannot be fullscreen Gyao! high protection level(DRM) video → Cannot be fullscreen Gyao! high protection level(DRM) video on nightly build
I can reproduce it via a VPN to Japan, the fullscreen is not available in Nightly but works well on Release.

It sounds like a regression.

Hi Ray,

Could you please take a look on this?

Or please help to dispatch this issue to the right person.

Thank you!
Flags: needinfo?(ralin)

Comment 2

2 years ago
(In reply to James Cheng[:JamesCheng] from comment #1)
> I can reproduce it via a VPN to Japan, the fullscreen is not available in
> Nightly but works well on Release.
> 
> It sounds like a regression.

Per Alice comment:
> The problem is not reproduced on release and beta build.
> And this seems in nightly build only problem.(I can reproduce the problem in
> nightly build at least since 2016-Jun-01.)
I would suspect this problem is more like caused by the variant of build flags in somewhere between nightly and others. In video controls, I cannot think of any could behave differently in only nightly build. 

I'm setting up VPN for JP region,  will look closer to the problem later.


Xidorn, do you know anything might stop nightly build from calling fullscreen API? Thanks
Flags: needinfo?(ralin) → needinfo?(xidorn+moz)

Comment 3

2 years ago
Entered the websites successfully, thanks for James's help. The website is using its own custom controls, so the problem should be related to client script.
The first thing I would suspect is the unprefixed Fullscreen API which is enabled in Nightly only at the moment. You can set "full-screen-api.unprefix.enabled" to false in Nightly and try again to confirm whether that is the reason.


Prefixed Fullscreen API has been used in wide for an extremely long time, and thus lots of different kinds of compat issues can happen when unprefixed Fullscreen API actually becomes available. We've tried shipping unprefixed Fullscreen API in the past, but eventually disabled it in release and beta (see blockers of bug 1269276).

It would be appreciated if someone can identify a simple pattern from the website for why the presence of unprefixed Fullscreen API would lead to the issue. With that, we can explore whether it is possible to workaround it somehow.
Flags: needinfo?(xidorn+moz)
Also it may be helpful to have a look at the console and see if there's any message displayed when you click the fullscreen button.
(Reporter)

Comment 6

2 years ago
(In reply to Xidorn Quan [:xidorn] UTC+10 (less responsive Nov 5 ~ Dec 16) from comment #4)
> The first thing I would suspect is the unprefixed Fullscreen API which is
> enabled in Nightly only at the moment. You can set
> "full-screen-api.unprefix.enabled" to false in Nightly and try again to
> confirm whether that is the reason.
> 
> 
> Prefixed Fullscreen API has been used in wide for an extremely long time,
> and thus lots of different kinds of compat issues can happen when unprefixed
> Fullscreen API actually becomes available. We've tried shipping unprefixed
> Fullscreen API in the past, but eventually disabled it in release and beta
> (see blockers of bug 1269276).
> 
> It would be appreciated if someone can identify a simple pattern from the
> website for why the presence of unprefixed Fullscreen API would lead to the
> issue. With that, we can explore whether it is possible to workaround it
> somehow.

indeed, it works as expected when turn full-screen-api.unprefix.enabled to false.
Component: Audio/Video → DOM
(Reporter)

Comment 7

2 years ago
(In reply to Xidorn Quan [:xidorn] UTC+10 (less responsive Nov 5 ~ Dec 16) from comment #5)
> Also it may be helpful to have a look at the console and see if there's any
> message displayed when you click the fullscreen button.


VIDEOJS: ERROR: 
InternalError
columnNumber: 1
fileName: "https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js"
lineNumber: 6
message: "too much recursion"
stack: "ua@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:6:1\nd@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:37:1495\ng/c.requestFullscreen@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:38:11378\nua@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:6:27847\nd@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:37:1495\ng/c.requestFullscreen@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:38:11378\nua@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:6:27847\nd@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:37:1495\ng/c.requestFullscreen@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:38:11378\nua@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js:6:27847\nd@https://players.brightcove.net/4235717419001/HJobu0ljb_default/index.min.js…"
__proto__: Object { stack: "", … }
index.min.js:2:5286
(Reporter)

Updated

2 years ago
Priority: -- → P3
ni? myself for investigation what's happening there.
Flags: needinfo?(xidorn+moz)
(For my own information, I see video.js is mentioned in the source code, and the error is infinite recursion, so it is likely related to bug 1268794. But that bug was only supposed to cause the black screen to be much longer, not intended to break the fullscreen feature itself. If it is proven that the design there can lead to breakage of fullscreen, we may need to reconsider the solution.)
Flags: needinfo?(xidorn+moz)
See Also: → 1268794
(Assignee)

Updated

2 months ago
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.