Closed Bug 127444 Opened 22 years ago Closed 14 years ago

Full screen mode on Linux hides titlebar

Categories

(SeaMonkey :: UI Design, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: bzbarsky, Assigned: jag+mozilla)

Details

(Keywords: privacy)

Full screen mode on linux hides the titlebar. This makes it impossible to move
the window.  If you happen to have a window in the upper right hand corner that
is kept "on top" by your windowmanager, that means that there is no way to exit
full screen mode (since it does not place mozilla "on top" and therefore all the
little buttons in the top right are inaccessible).
Keywords: privacy
What is full screen mode on Linux...
It was intended to be Windows-only for this release.  I haven't seen this yet,
but it sounds like it may be serious enough to disable the feature on Linux.
May I ask how i trigger fullscreen mode on Linux? I'd be interested in testing
it. I thought it was disabled on Linux, and the feature futured?

A simple solution would of course be the one requested over and over - a
"restore" item in page context menu while in fullscreen mode.
I should clarify.  This is fullscreen mode gotten by doing

window.fullScreen = true;

from a script.  One can do this by hand by typing

javascript:void(window.fullScreen = true)

in the url bar.  There is no UI on Linux that I can see for starting this full
screen mode if a user wants to, but web content can start full screen mode (bug
127405), which is what makes this a _real_ security risk.

That said, the current implementation on Linux is actually pretty good (I've
been playing with it) and I would be in favor of having it turned on but made
inaccessible to untrusted content.
This must be WM-dependent. On KDE 2.2 kwin, I can still see and reach
the WM decorated titlebar just fine and resize the window.
Yes, this _would_ be WM-dependant... different WMs do different things when
asked to resize a window to a particular size and when asked to put it in a
particular spot (some count title bar some do not).  Some also report the size
of the titlebar when asked and some do not.  I'm using AfterStep 1.8.0.
>'a _real_ security'

Could you define the type of real security risk here?
Sure.  The risk is that the offending page effectively turns off Mozilla's UI,
makes Mozilla take up the full screen, and makes Mozilla uncloseable....

There is also a bug that I can't find at the moment about resizeTo() having
similar effects that describes some other issues in detail.
QA Contact: sairuh → claudius
Isn't the whole point of "fullscreen mode" that the window decorations such as
title bars, menus, status bars, etc. are hidden? If you can see the titlebar, it
isn't fullscreen mode. It sounds like what the user wanted was to "maximize" his
window, not put the browser in "fullscreen mode". I'd call that user error, not
a bug.
Please read comment 4 again.  The _user_ did not put the browser in fullscreen
mode.  The user has no way to do that.  The _web_page_ put the browser full
screen mode.

If the full-screen mode were not accessible to untrusted content by default this
whole issue would be moot.
There was another bug about this...the answer I got was that this is very
WM-dependent and hard to fix. The best fix would still be to make sure all WM's
keep the titlebar on the screen. Some of them treat the (0,0) point of a window
to be the top left corner of the content area, *below* the titlebar, which is
what causes this particular problem.

However, if we can't fix that, I agree that we should disable this function from
content.
I think this is invalid by the new fullscreen mode. F11 will get you out, and
there are, or should be, seperate bugs if we're misbehaving with GNOME or KDE
panels.
> F11 will get you out

Only if that keybinding is not used by your windowmanager, which it often is.
this seems to be ok now.  full screen mode has its own (non-WM) buttons for
minimize, restore and close.
Please read comment 0, sentences 2 and 3 again.  On a typical AfterStep or
Windowmaker setup, not a single one of those three buttons is reachable.
ok well, setting window.fullScreen from Javascript is disabled in all.js
Right.  And it can't be reenabled till this bug is fixed.
>> ok well, setting window.fullScreen from Javascript is disabled in all.js
>
> Right.  And it can't be reenabled till this bug is fixed.

Whoa, hold it, are you actually planning on reenabling it at that point?
It would become discussable....  Whether it should be reenabled is a separate
issue.  In no case can it be reenabled while this bug exists, however.
the reason the titlebar goes away is that all OS chrome is explicitly clobbered.  
Some WM ignore that and display some of the chrome anyway.

If you want the titlebar to not get clobbered, there appear to be 2 options

1. the easy solution (change the behavior of "hidechrome"):
http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsWindow.cpp#4186
change "0" to "GDK_DECOR_TITLE" (and other relevant things for other toolkits)
I tested this out and it successfully restored the titlebar under blackbox.

2. the hard solution:
http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#1927
after hiding chrome, restore the titlebar.  this is "hard" because there doesn't
seem to be any way to alter the chrome of an existing window (except via
"hidechrome").
Once Full Screen is fully implemented on X11, shouldn't users be able to get out
of it using F11?
The F-keys are commonly reserved by the window manager for various window 
manager functionality.
Product: Core → Mozilla Application Suite
Assignee: hewitt → jag
QA Contact: claudius
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.