- From: <bugzilla@jessica.w3.org>
- Date: Fri, 19 Dec 2014 14:55:00 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27674
Bug ID: 27674
Summary: requestFullscreen should return a promise
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Fullscreen
Assignee: annevk@annevk.nl
Reporter: andyearnshaw@gmail.com
QA Contact: public-webapps-bugzilla@w3.org
CC: mike@w3.org, public-webapps@w3.org
I'd much prefer the Promise or callback-based workflow for handling full screen
rejections or approvals:
document.body.requestFullScreen()
.then(function () { /* ... */ })
.catch(function (e) { /* ... */ });
vs
var errHandler = function () {
document.removeElementListener('fullscreenerror', errHandler);
/* ... */
};
document.addEventListener('fullscreenerror', errHandler);
document.body.requestFullscreen();
Using promises or callbacks also means better encapsulation for libraries.
Imagine I'm using a video library such as jwPlayer means any fullscreenchange
or fullscreenerror handlers I've added will be triggered by that library's
request for full screen unless I use the "once" pattern as above. Generally,
those events will always be assigned at the same time as the request, so
returning a promise to be fulfilled or rejected just makes sense.
The fullscreenchange is still relevant, but it seems strange to me that the
fullscreenerror event even exists, because I can't think of a situation where
you'd want to catch *all* full screen rejections and not just one pertaining to
each request made.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 19 December 2014 14:55:03 UTC