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

Status: VERIFIED FIXED

(Web Compatibility :: Desktop, defect)

Description

[Alexandru Simonca [:asimonca], Release Desktop QA]

[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

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

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.

Comment 2

[Alexandru Simonca [:asimonca], Release Desktop QA]

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?

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

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.

Comment 4

[Hsin-Yi Tsai (away for a while) [:hsinyi]]

(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.

Comment 5

[Karl Dubost💡 :karlcow]

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

Comment 6

[Brandon Jones]

Fixed the site. Thanks for the heads up!

Comment 7

[Mike Taylor [:miketaylr]]

Thanks Brandon!

Comment 8

[Alexandru Simonca [:asimonca], Release Desktop QA]

This is VERIFIED FIXED. Tested with Firefox Beta 50.0b11 on Windows 10 x64. Thanks Brandon and Mike!