Open
Bug 1179457
Opened 10 years ago
Updated 3 years ago
Alias webkit Fullscreen related properties
Categories
(Core :: DOM: Core & HTML, defect, P5)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: miketaylr, Unassigned)
References
(Blocks 2 open bugs)
Details
We should alias the following webkit prefixed fullscreen API properties to their equivalents (either via CSS Unprefixing or otherwise) in Gecko.
We haven't unprefixed yet... so I suppose we just map to moz, or do it at the same time that we unprefix (743198). I don't have a grasp on the difference between prefixed WebKit and the standard right now.
onwebkitfullscreenchange
onwebkitfullscreenerror
webkitCancelFullScreen
webkitCurrentFullScreenElement
webkitDisplayingFullscreen
webkitEnterFullScreen
webkitExitFullScreen
webkitFullscreenElement
webkitFullscreenEnabled
webkitIsFullScreen
webkitRequestFullScreen
webkitSupportsFullscreen
Comment 1•10 years ago
|
||
Why the ?#@! have we still not unprefixed? What is this, 2003?
Comment 2•10 years ago
|
||
Content may check various prefix before using Fullscreen API, which can lead to unfortunate path if they check the webkit prefix first. It probably doesn't matter a lot though.
One thing I'm concerned is the events. Obviously we shouldn't dispatch both mozfullscreen{change,error} and webkitfullscreen{change,error} at the same time. We probably should add a flag to track which style of API was called, and only dispatch the corresponding event. We might eventually need to do so when we unprefix Fullscreen API anyway.
Blocks: 1121280
Comment 3•10 years ago
|
||
That is a great point. And super annoying, but perhaps not too bad. And if one starts to mix
use of moz/webkit/unprefixed use of API, that is not a case we explicitly need to support IMO.
Reporter | ||
Comment 4•10 years ago
|
||
Here's some data from Chrome's use counter to help us prioritize/decide what's worth implementing. The percentages will change over time (hopefully trending down), so it's just a snapshot:
onwebkitfullscreenchange
onwebkitfullscreenerror
No data
webkitFullscreenEnabled: 0.9455%
https://www.chromestatus.com/metrics/feature/timeline/popularity/322
webkitIsFullScreen: 0.3360%
https://www.chromestatus.com/metrics/feature/timeline/popularity/318
webkitFullscreenElement: 0.2933%
https://www.chromestatus.com/metrics/feature/timeline/popularity/323
webkitCancelFullScreen: 0.1116%
https://www.chromestatus.com/metrics/feature/timeline/popularity/321
webkitRequestFullScreen: 0.0649%
https://www.chromestatus.com/metrics/feature/timeline/popularity/176
webkitExitFullScreen: 0.0465%
https://www.chromestatus.com/metrics/feature/timeline/popularity/324
webkitCurrentFullScreenElement: 0.0400%
https://www.chromestatus.com/metrics/feature/timeline/popularity/320
~~~~ 0.03% Chromium threshold to be at risk for removal ~~~
webkitDisplayingFullscreen: 0.0086% (on <video>)
https://www.chromestatus.com/metrics/feature/timeline/popularity/167
webkitSupportsFullscreen: 0.0046% (on <video>)
https://www.chromestatus.com/metrics/feature/timeline/popularity/166
webkitEnterFullScreen: 0.0008% (on <video>)
https://www.chromestatus.com/metrics/feature/timeline/popularity/170
Comment 5•5 years ago
|
||
Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
Updated•3 years ago
|
![]() |
||
Comment 6•3 years ago
|
||
Also on the WebKit front
https://bugs.webkit.org/show_bug.cgi?id=229333
See Also: → https://bugs.webkit.org/show_bug.cgi?id=229333
You need to log in
before you can comment on or make changes to this bug.
Description
•