Why is fullscreen API disabled by default?

[raj_bhaskar]

Brilliant, that does the job, thanks .

[Philip Chee]

Anyway, since I wanted to have some decent working full screen in SeaMonkey I wrote a small extension that does that:

True Full Screen in SeaMonkey

What it does is it enables full screen API first and then whenever the browser is switched to full screen it hides the top toolbars so that we get true full screen with no distractions. Additionally, it will pop out the toolbars when the mouse is moved to the top of the screen. And it works for me well on html5 video on youtube, vimeo and dailymotion and on a sample html slide show - with no nags, of course! . You can try it out in FB, theoretically it should work there, too.

Well:

This extension will be useful until SeaMonkey implements true full screen mode as a built-in feature.

Patches for true full screen mode welcome!

Phil

[Lemon Juice]

Patches for true full screen mode welcome!

Yeah, it would be best to patch SM so it has full screen natively - I've made this extension because I wanted to check if this would work at all and besides it was the quickest way for me. I've never submitted patches to bugzilla so I don't know how much work that would be and yet I would have to learn how to do it. Also, how would I test the patch? Could I simply make changes to omni.ja package and run it without compiling SM? What about other tests like automated tests?

I don't know if I can find enough time soon to dive into this so I admit it would be best if someone could take the code from my extension and move it to the SM code with appropriate modifications - but I suspect this may not happen, depending on various factors, so I might try it - but just not now.

Anyway, do we have an agreed way of how full screen is supposed to work in SM? A few months ago I tried to go through all the various bugs on full screen and they all seemed to run in circles without any definite conclusions. I'm for implementing full screen just like I did in my extension - simple without any unnecessary nags. If no one has any objections then at least we would know what direction to take and it would make it possible for us to do any progress. Or is the lack of any decisiveness so far due to the fact that no one has provided a patch yet? Meaning that the one who comes with a patch has the most to say in that matter unless contradicted with someone else's patch?

Also, I think the bug I submitted above about the full screen API defaults should also be addressed first because my implementation of full screen hinges on this setting (just like any other implementation would) and I don't really add anything new to the API. I haven't tested the API in SM in a technical way so I don't know all of its peculiarities, I've just been browsing with it enabled for several months and I haven't found any problems with it and in my experience it works fine as it is now and I see no reason for it to be off.

[Philip Chee]

I'll see if I can find the time to do this. The reason I asked is that some extension authors are rather touchy about other people appropriating their code even in cases where they used an open-source licence.

Phil

[Lemon Juice]

If you can find time to do this then it would be great. I think this should become part of SM anyway so I don't mind if you use my code or not as long as it works and if my code can speed things up then all the better. I've uploaded a new version which basically does some variable renaming, etc. to make the code more readable and obvious.

I suspect the code that sits in the fullscreen listener should go somewhere into the SM methods that toggle full screen on and off since a listener is probably not needed if it is to run as native code. The only difficulty I've come across is restoring sidebar's collapsed state after returning from full screen:

Code: Select all

SidebarSetState("collapsed")

simply doesn't want to work for me - it results in a collapsed state visually but is frozen -the grippy doesn't respond to mouse clicks and subsequent calls to SidebarGetState() return "hidden" instead of "collapsed". This must be some SM bug or weirdness, I've tried various workarounds including timeouts, using the same methods that are invoked from the UI for controlling the sidebar but nothing worked. That's why I've simply decided the sidebar gets completely hidden if it was collapsed to prevent any weird behaviour. Maybe this was problematic because run from an extension and would work as part of native code? You may look into this, maybe you know better these code peculiarities. However, this is actually trivia so you don't have to spend a lot of time trying to get this detail to work

[patrickjdempsey]

It sounds like what you want to do is to make the width of the sidebar box = 0 and allow the splitter to still function? I was under the impression that the proper behavior would be to store the sidebar state, toggle it to hidden, and then restore when fullscreen mode is backed out of.

Isn't all of that handled automatically if you use this function?

Code: Select all

function toggleAffectedChrome(aHide)
{
  // chrome to toggle includes:
  //   (*) menubar
  //   (*) navigation bar
  //   (*) personal toolbar
  //   (*) tab browser ``strip''
  //   (*) sidebar
  //   (*) statusbar
  //   (*) findbar

  if (!gChromeState)
    gChromeState = new Object;

  var statusbar = document.getElementById("status-bar");
  getNavToolbox().hidden = aHide; 
  var notificationBox = gBrowser.getNotificationBox();
  var findbar = document.getElementById("FindToolbar")

  // sidebar states map as follows:
  //   hidden    => hide/show nothing
  //   collapsed => hide/show only the splitter
  //   shown     => hide/show the splitter and the box
  if (aHide)
  {
    // going into print preview mode
    gChromeState.sidebar = SidebarGetState();
    SidebarSetState("hidden");

    // deal with tab browser
    gBrowser.mStrip.setAttribute("moz-collapsed", "true");

    // deal with the Status Bar
    gChromeState.statusbarWasHidden = statusbar.hidden;
    statusbar.hidden = true;

    // deal with the notification box
    gChromeState.notificationsWereHidden = notificationBox.notificationsHidden;
    notificationBox.notificationsHidden = true;

    if (findbar)
    {
      gChromeState.findbarWasHidden = findbar.hidden;
      findbar.close();
    }
    else
    {
      gChromeState.findbarWasHidden = true;
    }

    gChromeState.syncNotificationsOpen = false;
    var syncNotifications = document.getElementById("sync-notifications");
    if (syncNotifications)
    {
      gChromeState.syncNotificationsOpen = !syncNotifications.notificationsHidden;
      syncNotifications.notificationsHidden = true;
    }
  }
  else
  {
    // restoring normal mode (i.e., leaving print preview mode)
    SidebarSetState(gChromeState.sidebar);

    // restore tab browser
    gBrowser.mStrip.removeAttribute("moz-collapsed");

    // restore the Status Bar
    statusbar.hidden = gChromeState.statusbarWasHidden;

    // restore the notification box
    notificationBox.notificationsHidden = gChromeState.notificationsWereHidden;

    if (!gChromeState.findbarWasHidden)
      findbar.open();

    if (gChromeState.syncNotificationsOpen)
      document.getElementById("sync-notifications").notificationsHidden = false;
  }

  // if we are unhiding and sidebar used to be there rebuild it
  if (!aHide && gChromeState.sidebar == "visible")
    SidebarRebuild();
}

You can call it using the same style as Print Preview:

onEnter: toggleAffectedChrome(true);
onExit: toggleAffectedChrome(false);

Code: Select all

var PrintPreviewListener = {
  _printPreviewTab: null,
  _tabBeforePrintPreview: null,

  getPrintPreviewBrowser: function () {
    if (!this._printPreviewTab) {
      this._tabBeforePrintPreview = getBrowser().selectedTab;
      this._printPreviewTab = getBrowser().addTab("about:blank");
      getBrowser().selectedTab = this._printPreviewTab;
    }
    return getBrowser().getBrowserForTab(this._printPreviewTab);
  },
  getSourceBrowser: function () {
    return this._tabBeforePrintPreview ?
      getBrowser().getBrowserForTab(this._tabBeforePrintPreview) :
      getBrowser().selectedBrowser;
  },
  getNavToolbox: function () {
    return window.getNavToolbox();
  },
  onEnter: function () {
    gInPrintPreviewMode = true;
    toggleAffectedChrome(true);
  },
  onExit: function () {
    getBrowser().selectedTab = this._tabBeforePrintPreview;
    this._tabBeforePrintPreview = null;
    gInPrintPreviewMode = false;
    toggleAffectedChrome(false);
    getBrowser().removeTab(this._printPreviewTab, { disableUndo: true });
    this._printPreviewTab = null;
  }
};

[patrickjdempsey]

Or is that too aggressive? Maybe you could just duplicate the parts of toggleAffectedChrome you need?

[Lemon Juice]

It sounds like what you want to do is to make the width of the sidebar box = 0 and allow the splitter to still function? I was under the impression that the proper behavior would be to store the sidebar state, toggle it to hidden, and then restore when fullscreen mode is backed out of.

Theoretically, this seems to be the proper way and that's what SidebarSetState() method is for but restoring to the collapsed state is buggy.

Isn't all of that handled automatically if you use this function?

Code: Select all

function toggleAffectedChrome(aHide)
[...]

You can call it using the same style as Print Preview:

onEnter: toggleAffectedChrome(true);
onExit: toggleAffectedChrome(false);

Actually, what I am doing is very similar to what toggleAffectedChrome does - I save the sidebar state and then restore it with SidebarSetState so there's really no difference. Actually, the toggleAffectedChrome code is buggy in the same way - open the sidebar, collapse it by clicking on the splitter grippy, open print preview and exit print preview - the sidebar will look collapsed as before but it is not possible to open it or resize it using the splitter. This is the same problem as was happening in my case so it looks like a bug in SM.

What's more, I've found that SidebarSetState("visible") is also sometimes buggy - if I went to full screen, opened the sidebar and then closed it then when I returned from full screen SidebarSetState("visible") resulted in the same frozen-collapsed sidebar state. But here I was able to use SidebarShowHide() as a workaround.

So the collapsed sidebar state issue remains unsolved but I think it shouldn't block any implementations of true full screen because it's really a minor issue.

BTW, I've added some code to hide the find bar when going full screen and restoring it when exiting full screen. When the user manually opens and then hides the find bar in full screen then it is not restored (seems logical that in such a case the user wants the find bar to be closed for good). Version updated.

[patrickjdempsey]

In my dealings with sidebars in the past I've sometimes had to apply a minimum width to get them to work properly.

[Lemon Juice]

Well maybe you are right but a sidebar with a minimum width is no longer collapsed so applying it would defeat the purpose of restoring it to the collapsed state....

[Lemon Juice]

I thought it would also be good if the main menu showed when F10 or alt was pressed in full screen - version updated.