Set full-screen-api.enabled to true by default

RESOLVED FIXED in seamonkey2.45

Status

defect
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: michal-ok, Assigned: michal-ok, NeedInfo)

Tracking

SeaMonkey 2.30 Branch
seamonkey2.45

SeaMonkey Tracking Flags

(seamonkey2.42 fixed, seamonkey2.43 fixed, seamonkey2.44 fixed, seamonkey2.46 fixed)

Details

Attachments

(1 attachment)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
Build ID: 20141013232806

Steps to reproduce:

After installing SeaMonkey or creating a new profile full-screen-api.enabled is false by default.


Actual results:

Full screen API is disabled, which causes usability problems on certain sites.


Expected results:

While the full screen features in SeaMonkey are not finished and there are other bugs regarding them, still the full screen API is already implemented and works in a fairly acceptable way. The drawback is that the location bar that is not hidden in full screen mode but still this is much better than having full screen API turned off completely.

When full screen API is off then there are problems with some sites:

- some sites enter full screen mode for slide shows and having slide shows in smaller browser windows is not really a good experience
- can't play html5 youtube videos in full screen (the full screen button is not available in the YT player)
- on vimeo.com when the flash plugin is disabled the videos are played using html5. However, when fullscreen api is off the user is greeted with a strange warning:

>What’s going on here?
>Some of your technology may be out of date, and this video may not play properly.
>Try Anyway

Example: http://vimeo.com/45917260 - and I am able to play the video with the worst possible quality in a dumbed-down featureless player.

As it currently stands, having the full screen API enabled offers a much better experience of almost full screen than having it disabled (which causes usability problems on certain sites).

full-screen-api.enabled should be set to true by default. I think it would also be best if people upgrading to a newer SM version got this setting enabled for them silently as a one-time occurrence because they might not even know that having this hidden pref disabled results in a suboptimal experience.
OS: Windows 7 → All
Hardware: x86 → All
Yeah, I've seen some sites where HTML5 fullscreen mode isn't triggered any more, leaving the page in an unrecoverable intermediate stage where the content (movie) fills part of the screen but essentially access to the controls is cut off at the bottom and you can't get back (don't recall the URL).

However, there is bug 784324 suggesting that just full-screen-api.enabled may not resolve it entirely, don't know what else would be considered "required" before enabling it by default.
(In reply to rsx11m from comment #1)
> Yeah, I've seen some sites where HTML5 fullscreen mode isn't triggered any
> more, leaving the page in an unrecoverable intermediate stage where the
> content (movie) fills part of the screen but essentially access to the
> controls is cut off at the bottom and you can't get back (don't recall the
> URL).

Do you mean that these problems happen when full-screen-api.enabled is set to true or false? Do you have any URLs where full-screen-api.enabled causes problems?

> However, there is bug 784324 suggesting that just full-screen-api.enabled
> may not resolve it entirely, don't know what else would be considered
> "required" before enabling it by default.

I think full-screen-api.enabled does not need to solve all problems entirely to be turned on by default - even if it solves part of the problems it is worth turning it on. Are there any sites where full-screen-api.enabled causes any problems as compared to when it is turned off? The links in that bug appear to be dead.
(In reply to lemon_juice from comment #2)
> (In reply to rsx11m from comment #1)
> Do you mean that these problems happen when full-screen-api.enabled is set to
> true or false? Do you have any URLs where full-screen-api.enabled causes problems?

As far as I recall I didn't change that pref, i.e., full-screen-api.enabled;false.
Unfortunately, as said, I don't have a URL for this specific instance.
If you say that full-screen-api.enabled was false then this wouldn't matter much in this case.

The question is does full-screen-api.enabled set to on cause any problems or breakages? If we don't have any cases like that then is there any reason why it can't be set to on by default? I provided some examples of where setting it to on solves problems and helps (and I could find more of them). I've never come across a site where it would cause any issues.
The SeaMonkey file that holds most of our defaults is browser-prefs.js
http://mxr.mozilla.org/comm-central/source/suite/browser/browser-prefs.js.
The prefs to be added are probably these:
http://mxr.mozilla.org/comm-central/source/mozilla/browser/app/profile/firefox.js?rev=3335d6e68892&mark=1608-1614#1608
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Preferences
From what I can see full-screen-api.approval-required has no effect in SeaMonkey so perhaps it doesn't need to be set at all. It might not have been ported from Firefox yet (which can actually be a good thing because we don't have those nag screens asking whether we want to go full screen - some people find them irritating).
With SM 2.35 coming soon I think it becomes important to finally enable full-screen-api.enabled by default because youtube uses HTML5 player since 2.35 by default and user experience is pretty bad with full-screen-api.enabled set to off - no full screen and no full screen button on the html5 player. When the pref is on the working full screen button will appear (full screen will still have the narrow tool bar at the top but it's still better than nothing).

I propose a patch for file http://mxr.mozilla.org/comm-central/source/suite/browser/browser-prefs.js - I hope I found the correct file for SM prefs!
Attachment #8627035 - Flags: review?
Works fine with FF 43.0a1 (2015-08-15), so indeed SM problem.

We have a proposed fix, so we should get this into 2.37
I am a SeaMonkey user.  Suddenly, I couldn't open Youtube videos in fullscreen.  I'm a long time SM user (since freakin Mozaic) and haven't made any recent changes,SM is current. I do had scriptblocker and adblocker, so I expected it was one of them.  NOPE!  without my involvement, the full-screen-api.enabled was set to false.  Luckily I found the info regarding this for FF (of course, not much out there for SM). This was not a fresh install, I had not changed any settings or made any changes to SM or Flash.   I did uninstall flash as a test, along with the script and ad blockers before I found this (happy to do so anyway).  I am wondering if SM just made the jump to use HTML5 instead of Flash without my knowledge, and thus subject to this "default" bug.
(In reply to Technosaur from comment #9)
> I am wondering if SM
> just made the jump to use HTML5 instead of Flash without my knowledge, and
> thus subject to this "default" bug.
More or less yes (Google made SM jump to html5). See this post for more explanation and workarounds: http://forums.mozillazine.org/viewtopic.php?p=14318267#p14318267
Assignee: nobody → michal-ok
Status: NEW → ASSIGNED
Comment on attachment 8627035 [details] [diff] [review]
pref full-screen-api.enabled true by default

I think we should enable it, the full-screen API works fine by my experience, and I don't mind the navigation bar remaining visible (thus not a "true" fullscreen). The lack of the "Do you allow ... to go full-screen?" prompt I'd consider a plus, given that Firefox presents it after the fact anyway. ;-)
Attachment #8627035 - Flags: review?(iann_bugzilla)
Attachment #8627035 - Flags: review?
Attachment #8627035 - Flags: feedback+
Comment on attachment 8627035 [details] [diff] [review]
pref full-screen-api.enabled true by default

Do we need to expose this preference? If so can a bug be spun off for that?
r=me for this patch though
Flags: needinfo?(rsx11m.pub)
Flags: needinfo?(RainerBielefeldNG)
Attachment #8627035 - Flags: review?(iann_bugzilla) → review+
I don't see any use case for explicitly disabling the full-screen API, unless it's possible for a website to abuse it and just force full screen to the user (then there is always ESC to cancel, but repeating that process over and over again may be a major annoyance).
Flags: needinfo?(rsx11m.pub)
We would also need some UI such as Firefox Bug 470628 (Provide a Full Screen button)
https://hg.mozilla.org/mozilla-central/rev/87390d4620e2

Can someone file a "Full Screen button" bug for SeaMonkey and set a dependency on this bug (or even re-purpose this bug)
Keywords: checkin-needed
http://hg.mozilla.org/comm-central/rev/3a61e85a78fe
FIXED unless you want this on aurora/beta/release
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.45
Comment on attachment 8627035 [details] [diff] [review]
pref full-screen-api.enabled true by default

This is a trivial change and only enabling an API which has been slightly incomplete but stable for quite a while. Thus, should be safe to enable on branches as well (including 2.42.x).
Attachment #8627035 - Flags: approval-comm-release?
Attachment #8627035 - Flags: approval-comm-beta?
Attachment #8627035 - Flags: approval-comm-aurora?
Comment on attachment 8627035 [details] [diff] [review]
pref full-screen-api.enabled true by default

a=me for all release branches.
Attachment #8627035 - Flags: approval-comm-release?
Attachment #8627035 - Flags: approval-comm-release+
Attachment #8627035 - Flags: approval-comm-beta?
Attachment #8627035 - Flags: approval-comm-beta+
Attachment #8627035 - Flags: approval-comm-aurora?
Attachment #8627035 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.