Once we land bug 760102, we'll be able to go fullscreen in web apps, but pointer lock won't work because we won't be sending a "fullscreen-approved" observer service notification targeted at the document which entered fullscreen. We need to do something like sending that notification in the web app case after we've made it past all the sanity checks in requestFullscreen.

Pointer lock in terms of what platform? Desktop? FYI - For bugs in regards to things like "the web app runtime forgot X pref" - that usually belongs in firefox --> webapp runtime

Desktop. I don't think pointer lock makes much sense on other platforms. Pointerlock bugs and other code changes to content/ traditionally goes in this modules. Bugzilla doesn't really have a good way to have a bug span multiple components unfortunately. :\

(In reply to Chris Pearce (:cpearce) from comment #2) > Desktop. I don't think pointer lock makes much sense on other platforms. > > Pointerlock bugs and other code changes to content/ traditionally goes in > this modules. Right, I agree. > > Bugzilla doesn't really have a good way to have a bug span multiple > components unfortunately. :\ Okay. I'll add the whiteboard tag so I can at least keep track of it in triage.

Are there any prefs we turn in the runtime that may be causing this bug? Or is there more to this?

No. Pointerlock has a blanket approval on all platforms: http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#3542 I explained the problem in bug 760102 comment 34.

Probably not going to block on this for the 1st release of the web runtime, unless there is a strong evidence that top apps are affected. This sounds strongly desired though, given that apps on marketplace will include games that might use this API. Flagging for tracking.

I'm actually going to track this for release - pointer lock is a recent feature and we should really have this fixed by the time we release.

It isn't clear to me exactly what needs to be done here, but we can certainly land a patch that spans modules, even if its bug doesn't. Alternately, if the content/ and webapprt/ changes are best done by two different engineers, then we should file a separate bug in Firefox::Webapp Runtime to get the webapprt/ work done.

cc mbest for comment from a games perspective. My understanding is that the requirement for pointer lock is primarily for games, which is quite important. However, there is other outstanding work for HTML5 games that needs to be completed before we can see a game that requires pointer lock installed as an App. If my understanding is correct, this looks to be a P1 but will not block WebRT in Fx16.

It depends on the application the developers are making. Most games do not need PointerLock to function but many 3D games such as FPS will not be able to work around this limitation. There are not a lot of 3D shooters currently on the market so a 6 week delay is likely very low impact. Porter lock is also not needed for mobile. As long as we are not planning to ship BananaBread (http://www.syntensity.com/static/night10/) as a WebRT app, which we currently are not, I don't think this should block the release.

Porter Lock = PointerLock

Pointer lock now works for webapps in Desktop nightly builds; I tested with my test app at http://pearce.org.nz/fullscreen This would have been fixed by the fullscreen permissions/webapp work we've done for B2G; bug 777135, bug 684620, bug 760102 and friends.

Pointer lock works in current Nightly (FF18), Aurora (FF17) but still doesn't work in Beta (FF16). Martin previously said that a 6 week delay in pointer lock is ok, and it would be messy to pull in the B2G changes which fixed pointer lock in webapps, so I suggest we let the fix ride the trains to release on the FF17 train.

Jason, can you verify this is fixed in Firefox 17 and 18?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14) > Jason, can you verify this is fixed in Firefox 17 and 18? Desktop web apps aren't a priority anymore (to the point that our ADUs are incredibly low), so this isn't critical to verify.

Okay, thanks Jason. Flagging [qa-] to deprioritize.