Open
Bug 1413157
Opened 7 years ago
Updated 2 years ago
Cannot be fullscreen Gyao! high protection level(DRM) video on nightly build
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
NEW
People
(Reporter: alice0775, Unassigned)
References
Details
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•7 years ago
|
Summary: Cannot be fullscreen Gyao! high protection level(DRM) video → Cannot be fullscreen Gyao! high protection level(DRM) video on nightly build
Comment 1•7 years ago
|
||
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•7 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•7 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.
Comment 4•7 years ago
|
||
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)
Comment 5•7 years ago
|
||
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•7 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•7 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•7 years ago
|
Blocks: 1269276
status-firefox58:
affected → ---
Updated•7 years ago
|
Priority: -- → P3
Comment 8•7 years ago
|
||
ni? myself for investigation what's happening there.
Flags: needinfo?(xidorn+moz)
Comment 9•7 years ago
|
||
(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.)
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•