Enable fullscreen API

[Happy-Ferret]

Is there a way to enable the fullscreen API for the qbrt shell? i e a user loads Youtube into a qbrt shell, accesses a video, clicks the "fullscreen" button and receives a fullscreen representation of the video?

I remember back in the Xulrunner days you had to set a preference (in prefs.js) for that. However, that no longer seems to work. Or perhaps I'm just not remembering the correct preference (I tried setting full-screen-api.enabled to true and full-screen-api.approval-required to false).

Setting window.fullScreen to true from a chrome privileged scope isn't always an option, so enabling the requestFullscreen API would be highly appreciated.

[mykmelez]

I searchfoxed for full-screen-api and found these preferences. So I set full-screen-api.enabled to true in defaults/preferences/prefs.js:

diff --git a/defaults/preferences/prefs.js b/defaults/preferences/prefs.js
index fecdbf7..bdf8009 100644
--- a/defaults/preferences/prefs.js
+++ b/defaults/preferences/prefs.js
@@ -24,8 +24,10 @@ pref('dom.mozBrowserFramesEnabled', true);
 pref('javascript.options.showInConsole', true);

 // Ideally, this would disable telemetry, but it doesn't actually work
 // (at least it doesn't disable code that spews errors into the console),
 // so we also override the @mozilla.org/base/telemetry-startup;1 XPCOM contract
 // with a custom component DisabledTelemetryStartup that ignores
 // the app-startup and profile-after-change messages.
 pref('toolkit.telemetry.enabled', false);
+
+pref("full-screen-api.enabled", true);

And then I invoked npm start run https://youtube.com, after which pressing the fullscreen button for a video caused the video to take over the screen. So it looks like setting that one preference is sufficient.

Of course, there should be an easier way to set that preference than editing the qbrt default preferences file. That's #73!

[Happy-Ferret]

Thanks.

Strangely, updates to the prefs.js profile file aren't properly propagated in my build. Even deleting the profile folder inside the user directory didn't fix this. Some weird monkey business, albeit one I'm quite certain I can figure out.

Anyhow. I then explicitly set full-screen-api.enabled to true from within the shell's main.js and can confirm that this does indeed work.

[mykmelez]

qbrt copies its application files (including prefs.js) into the Firefox installation dir after it installs Firefox into the dist/ dir. If you make changes to qbrt's app files, you need to node ./bin/install-xulapp.js afterward to get qbrt to re-copy those files. (Warning: that script is internal and unstable, so it's likely to change.)

[Happy-Ferret]

Ah. Ok. Didn't know that. I assumed it was using its own set of prefs stored inside the user directory, like XULRunner applications of yonder.

In any case, I added something to your other ticket. Unless you want a very specific implementation, this should be a "low hanging fruit".

[Happy-Ferret]

Did something change about the way Gecko handles full-screen requests, lately? I can no longer seem to get the above example to work, even though the prefs are set and applied correctly.

EDIT: Hm. It still works for websites, just not local applications. Might be one of the drawbacks you had previously mentioned in #73.

Although I'm fairly certain it had worked with a local application, previously.

[mykmelez]

Hmm, it still works for me with a local application and a recent version of Firefox. I added pref("full-screen-api.enabled", true); to the defaults/preferences/prefs.js file, ensured the file got copied into the right part of the dist/ directory via node ./bin/install-xulapp.js, and then added document.documentElement.requestFullscreen(); to examples/hello-world-html/app.js. Running that app then caused it to enter fullscreen mode.

[Happy-Ferret]

Yep.

Just tried that. I can confirm that actually works. It seems the issue comes down to an implementation detail of my app (which uses mozbrowser for its views).

Well. No biggies. I'll fix that eventually.

Right now I'd just like to get down and dirty with some qbrt internals. Adding require() to my internal fork yesterday afternoon stoked a fire in me. :cat: :dog: