Closed Bug 1314289 Opened 5 years ago Closed 5 years ago

typo in mozFullScreenElement does not trigger the Pointer Lock API on release channel

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set
normal

Tracking

(firefox49 verified, firefox50 verified, firefox51 fixed, firefox52 fixed)

VERIFIED FIXED
Tracking Status
firefox49 --- verified
firefox50 --- verified
firefox51 --- fixed
firefox52 --- fixed

People

(Reporter: asimonca, Assigned: karlcow)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [sitewait] [js])

[Note]:
-

[Affected versions]:
- all release channel builds since 47: Firefox 47.0 RC, Firefox 48.0.2 RC, Firefox 49.0.2 RC

[Affected platforms]:
- Windows 10 x64
- Ubuntu 16.04 x64
- Mac OS X 10.9.5

[Steps to reproduce]:
1. Download and open any Beta or Release build starting with 47.
2. Go to http://media.tojicode.com/q3bsp/
3. Click the "Fullscreen" button 

[Expected result]:
- Fullscreen mode is entered
- The pointer is locked 
- The fullscreen notification is displayed

[Actual result]:
- Fullscreen mode is entered
- The pointer is NOT locked (another click is required for Pointer Lock API to be triggered)

[Regression range]:
- https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6ea654cad929c9bedd8a4161a182b6189fbeae6a&tochange=15621f98b53b1994c7ae2e2703a6e50203c5304c

[Additional notes]:
- This issue only occurs on builds from the release channel.
- For Firefox 47.0 RC an additional pref is required to be set to true: webgl.force-enable
Flags: needinfo?(xidorn+moz)
I don't see how this can be a regression, actually.

This is an issue in the site that, it uses |mozFullscreenElement| when the unprefixed |fullscreenElement| is not available. However, the prefixed version of that is actually |mozFullScreenElement| ('Screen' vs. 'screen'), so the fullscreenchange handler always assumes it is not entering fullscreen, and consequently not request pointer lock.

The code in question is in game-shim.js:
> if(!("fullscreenElement" in document)) {
>     getter = (function() {
>         // These are the functions that match the spec, and should be preferred
>         if("webkitFullscreenElement" in document) {
>             return function() { return document.webkitFullscreenElement; };
>         }
>         if("mozFullscreenElement" in document) {
>             return function() { return document.mozFullscreenElement; };
>         }
>         return function() { return null; }; // not supported
>     })();

>     Object.defineProperty(document, "fullscreenElement", {
>         enumerable: true, configurable: false, writeable: false,
>         get: getter
>     });
> }

I tend to close this bug as INVALID.
Flags: needinfo?(xidorn+moz)
So is this a site-related issue that does not affect the functionality of the Pointer Lock API? 

Is there any way to change the behavior of the fullscreenchange handler so that this doesn't happen when a user ends up on a site experiencing the same issue?
Yes, it's a site issue.

The issue is that the site use a wrong name for checking whether it is in fullscreen. (mozFullscreenElement vs. mozFullScreenElement) It's a typo. How can we fix typo for every website?

One possible is that we add mozFullscreen* attributes in addition to our mozFullScreen*, but I'm not a fan of that. We should unprefix it soon, so I don't want to add another set of prefixed API.
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #3)
> Yes, it's a site issue.
> 

Sounds like "Tech:Evangelism" is a more appropriate component for this issue so that we could put this into webcompat team's radar and they might consider to reach out to the web authors (though this isn't a typical web compatibility issue).

> The issue is that the site use a wrong name for checking whether it is in
> fullscreen. (mozFullscreenElement vs. mozFullScreenElement) It's a typo. How
> can we fix typo for every website?
> 
> One possible is that we add mozFullscreen* attributes in addition to our
> mozFullScreen*, but I'm not a fan of that. We should unprefix it soon, so I
> don't want to add another set of prefixed API.
Component: DOM → Desktop
Product: Core → Tech Evangelism
This seems to be the site of https://plus.google.com/+BrandonJonesToji
who's an Engineer at Google.

He is on twitter and active
https://twitter.com/Tojiro/with_replies

Let's see. Contacted
http://twitter.com/MozWebCompat/status/794420085142102016
Assignee: nobody → kdubost
Summary: Fullscreen does not trigger the Pointer Lock API on release channel → typo in mozFullScreenElement does not trigger the Pointer Lock API on release channel
Whiteboard: [sitewait] [js]
Fixed the site. Thanks for the heads up!
Thanks Brandon!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
This is VERIFIED FIXED. Tested with Firefox Beta 50.0b11 on Windows 10 x64. Thanks Brandon and Mike!
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.