126685 - Mozilla should have a Full-screen mode (all platforms - Mac, Unix/Linux etc.)

Status: VERIFIED FIXED

(Core :: XUL, enhancement, P2)

Description

[Diego Biurrun]

Continuing from where bug 68136 left off...

Now that we have full screen mode on Windows, we need this for all platforms.

Comment 1

[Peter Trudelle]

->future

Comment 2

[Nick Pietraniec]

Should this bug be split into a separate bug for each platform?

Comment 3

[Ben Ross]

I think the low priority for this on all platforms is really quite bizarre. One
of the stated aims of full-screen mode was to allow 'web-kiosks', where the user
has no interaction with the outside world, and just, for example, browses a
shops personal website. *Surely* one of the most obvious directions that someone
setting one of these up is to go with Linux - if there isn't going to be any
user interaction, and all you ever have to set up is a browser, you'll go for
the free, reliable, stable, and relatively tamper-free option. Who wants to fork
out 100 quid / dollars for each web-kiosk?!?!?

Sorry, that doesn't help fix the bug, and I guess would be best expressed by a
vote, but I just want to point out that this really shouldn't be considered
principally a 'user' bug, and thus one solved 90% when 90% of the users (i.e.
Windows peeps) can do it - the market is *definitely* there for a Linux version.

Comment 4

[Robert Kaiser]

copying over two comments from bug 68136 which affect Linux, and belong here now:

------- Additional Comment #270 From Chris B. Sears 2002-01-31 21:37 -------

> c) Need ability to hide common desktop utils like gnome/kde taskbar, no
> estimate as again I have no knowledge in this area.

In KDE/Qt, QWidget::showFullScreen() and QWidget::showNormal()
are what you're looking for.  These got added in QT 2.1
and they are used in Konqueror in konq_mainwindow.cc

Chris

------- Additional Comment #271 From Chris B. Sears 2002-01-31 21:48 -------

BTW, QWidget::showFullScreen() and QWidget::showNormal()
work for Gnome as well, courtesy the ICCCM I believe.

Chris

Comment 5

[Diego Biurrun]

Nick, no let's try to keep this focussed for the moment.  Once we have one
implementation we can spin off the missing ones.

Nominating for Mozilla 1.1, we all want to have this in as soon as possible.

Comment 6

[Diego Biurrun]

mpt, why did you remove the dependency on bug 3341 (from bug 68136 also)?

Comment 7

[Nick Pietraniec]

This was why I was against filing a new bug for full screen other platforms... 
Please correct me if I'm wrong, but shouldn't most (if not) dependencies from
bug 68136 be migrated here now?  Mozilla is still a cross platform package.

mpt, if you're going to continue to remove this bug from blocking bug 3341,
please at least explain why you're doing this. 

Comment 8

[Christopher Whitt]

I don't speak for mpt, but it seems to me that full-screen mode is not necessary
for a kiosk mode, which is what bug 3341 is about.  Yes, some kiosk applications
might use full-screen, but they are independent.  

Actually, mpt has already explained (comment 43 in bug 3341 ) why full-screen
and kiosk mode are not dependent on each other.  I'll leave it others more
familiar than me to change the dependencies, but for myself, I don't know why
people feel so strongly that 3341 should depend on this on.

Comment 9

[Diego Biurrun]

It's true that you *can* set up a kiosk that does not run in fullscreen mode,
but the natural thing is to have it take up everything, am I wrong?  But let us
not bicker.  Just leave the dependency as a sign that the two bugs are related.

Comment 10

[Sören 'Chucker' Kuklau (gone)]

Why was the Summary changed? Does that mean BeOS, QNX, etc. will never have a
full screen mode?

Comment 11

[Diego Biurrun]

It's considered good form to explain a summary change.  Changing summary back,
as the previous comment explains there is no good reason to restrict fullscreen
modes to Windows, Linux and Mac.

Comment 12

[Robert Kaiser]

Re-adding Mac and Unix/Linux into current summary. It will be easier to find the
bug via the Bugzilla query page...

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

taking to implement for the Gtk Frontend

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

This turned out to be more difficult than I thought.

I'll try the more complex solution tomorrow, maybe I'll have a patch then.

Comment 15

[Jay Yan]

*** Bug 136522 has been marked as a duplicate of this bug. ***

Comment 16

[Julien Pierre]

Adding OS/2 to the platform list in the subject.

Comment 17

[Diego Biurrun]

Julien, OS/2 already has a fullscreen mode if bug 133881 is not lying...
Changing summary back to include only the platforms which do not have a 
fullscreen mode yet, sigh.

Comment 18

[Julien Pierre]

OK, never mind. I guess I didn't know about it.

Comment 19

[Chris Neale]

1.0rc2 on Linux can be coerced into having fullscreen mode (plays havoc in
Xinerama presently and toolbar (kicker in KDE 3) doesn't disappear)

I unzipped comm.jar and added the following from a windows copy to 

content/navigator/platformNavigationBindings.xul

+ <key id="key_fullScreen" keycode="VK_F11" command="View:FullScreen"/>
</keyset>

I suppose I could have deleted the hide menu item bit as well

The reason I did all this (aside from seeing if it would work) was to sort out
the buttons as displayed by Orbit 3, under fullscreen conditions, which I've
been resurrecting,

currently hosted at work : http://www.alfordot.com/e/p/cdn/orbit3/

wanted fullscreen under Linux, since I've been doing the chrome dev here

Comment 20

[R.K.Aa.]

*** Bug 146454 has been marked as a duplicate of this bug. ***

Comment 21

[Diego Biurrun]

Chris, this sounds very interesting, but I have not been able to make this work
with a current branch nightly.  Is this RC2 only?  Could you give a few detailed
steps to make this work?  Thanks.

Comment 22

[Chris Neale]

I neglected to mention rejarring comm.jar, I only tried on rc2
I've got another branch build compiling now, I might try it on that, although
rc3 is out !

The menu entry is in navigator.xul I think;

it appeared to me that buggy functionality is in place, but not visible as it
doesn't do various things as listed above; and as I reported, fullscreen goes to
2048, on Xinerama pairing

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

it's not in place because fullscreen should hide windows decorations, afaict,
which is pretty difficult on X11 - a new window needs to be created and the old
contents be transferred to it. my current impl. of that doesn't really work...
keypresses don't work in the new window

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

I'll use a different solution - do what galeon does, and simply move the title
bar outside the screen.

I'll ask them if I can use their code under MPL/GPL/LGPL, and attach a patch if
I may.

Comment 25

[André Dahlqvist]

Christian, if you use a window manager with virtual desktops does this technique
mean that mozilla will peak out on another desktop?

Comment 26

[Robert Kaiser]

IIRC, the way Christian wants to go is known to have problems with Xinerama and
is not "The Right Way (TM)" to do it.
But also Galeon chose that way because the solution which is believed to be "The
Right Way (TM)" is known to have problems with a certian number of window
managers...

Comment 27

[Nick Pietraniec]

Given the incredible amount of window managers available, isn't it inevitable
that there will be problems with a few?  Given the options, I don't think
implementing in this way would be a bad idea...  Unless there's a "right" way
that I don't know about.  If that's the case, maybe the fullscreen
implementation should be postponed.  I however, don't think it implementing it
in this way would be such a bad idea.

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

>IIRC, the way Christian wants to go is known to have problems with Xinerama and
>is not "The Right Way (TM)" to do it.

Galeon has special Code for Xinerama which I'll copy too.

"The Right Way (TM)" doesn't work with my window manager (sawfish, a very common
one) unless I do it by creating a new window w/o decorations, which is a)
difficult, b) I couldn't get it to run correctly c) requires additional 4 bytes
per window (ok, that's not much, but...)

>Christian, if you use a window manager with virtual desktops does this 
>technique mean that mozilla will peak out on another desktop?

No. I just tested that, and it doesn't.

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, current status: the three galeon developers who have worked on the
fullscreen code have agreed to triple-licensing.

I'll do some final tests of the code and then attach the patch here.

Comment 30

[Vadim Berezniker]

> No. I just tested that, and it doesn't.

Did you test on some other window managers?
I'm pretty sure that some window managers deal with virtual desktops differently.
Some restrain windows to the virtual desktop, but some(like E) allow you to have
a window extend to a different virtual desktop.

Comment 31

[Christian :Biesinger (don't email me, ping me on IRC)]

I tested with sawfish, which does allow a window to extend to more than one
virtual desktop.

I do not have another window manager that I can test with.

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch (GTK)

Comment 33

[Travis Crump]

I tried out the patch, and my window decorations never reappear after leaving
full screen mode.  Personally, I would be willing to call this a 'feature', and
it is infinitely preferable to the window decorations appearing when they
weren't there before I entered full screen mode(since I normally have window
decorations set to borderless for Mozilla[but I changed them to default to test
this cause I was curious about the other virtual desktop thing]), but...

I am using Enlightenment 0.16.5-6[Debian] and Gnome 1.4 and Enlightenment theme
'ShinyMetal'

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: new patch (GTK)

oops,looks like I didn't attach the latest version of the patch

Comment 35

[Nick Pietraniec]

Attachment: KDE screenshot w/new patch (GTK)

I just finished compiling the current CVS/w new patch.	I've attached a screen
shot of full screen in KDE.  (Sorry about size/quality)  The window decorations
are still there along w/the toolbar on the bottom.  I'll see if I can try it in
gnome too.

Comment 36

[Nick Pietraniec]

Attachment: Gnome screenshot w/new patch (GTK)

Here's the gnome shot...  The toolbar disappears, but the window decorations
are still there.  KDE, btw was 3.0.1, and gnome is 1.4 on Mandrake 8.2

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

toolbar at bottom: sorry, can't do anything about that.

decos still there: hmm. are you sure that you rebuilt the dom/ directory too?

Comment 38

[Nick Pietraniec]

I pulled CVS around 10:00 this morning, applied "new patch (GTK)" and waited
(4hours!) for it to build...  I don't think I missed anything, but I don't have
much experience building mozilla.

Comment 39

[Diego Biurrun]

I just pulled and built with your patch applied - works flawlessly (GNOME and
sawfish).  Thanks and congratulations!  Now let's get this baby reviewed and
checked in!

Comment 40

[Chris Neale]

which ./configure options are people using to build ?

does the Xinerama code make the fullscreened window stick to a single head ?

TIA

cdn

--

Orbit3 lives

Get Orbit3+1 and Orbit Retro from : http://themes.mozdev.org - mostly Stable

Comment 41

[Diego Biurrun]

This is my .mozconfig:

ac_add_options --enable-optimize="-O2 -march=k6 -mcpu=k6"
ac_add_options --enable-crypto
ac_add_options --enable-extensions
ac_add_options --with-extensions=default,irc
ac_add_options --disable-debug
ac_add_options --disable-dtd-debug
ac_add_options --disable-jsd
ac_add_options --disable-ldap
ac_add_options --disable-xprint
ac_add_options --disable-logging
ac_add_options --disable-mailnews
ac_add_options --disable-tests
ac_add_options --disable-accessibility
ac_add_options --disable-bidi
ac_add_options --disable-mathml
ac_add_options --disable-postscript

Comment 42

[Chris Neale]

I'm building with .mozconfig :

ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --without-system-nspr
ac_add_options --enable-crypto #comment to disable PSM/SSL support

ac_add_options --enable-svg

#

mk_add_options MOZ_INTERNAL_LIBART_LGPL=1
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1


on a 700MHz Celeron, and F11 under KDE/Linux still goes across both heads under
Xinerama, is this the correct behaviour ?

cdn

Comment 43

[timeless]

http://mozilla.org/xpapps/MachVPlan/Full_Screen_Mode.html
is the closest thing i found to a full screen mode specification, and it 
doesn't seem to talk about what to do for multiple monitors.

from the windows bugs, i think that end users expect apps to only full screen 
on a single window (not always primary), I haven't seen enough bugs from users 
about fullscreening a window that straddled screens (but afaik we can't full 
screen to aux monitors on windows yet so that makes sense).  My feeling is that 
for straddling windows, we should consider using one of the following points 
for deciding which screen to use: (top-left corner, center).  Before making a 
decission, I'd love to see the results of a usability study on the subject :-).

Trudelle: i guess you own the spec, can you clarify or indicate how 
[in]accurate my thoughts are?

For reference, (yes, the following links are to aid in answering full screen 
mode specification questions, please don't complain that they are about win32)

http://msdn.microsoft.com/library/en-us/cstask/html/csconwindowmanagement.asp 
is appears to be MSVC6's full screen mode spec (among other things)

http://msdn.microsoft.com/library/en-us/gdi/monitor_3lrn.asp appears to spec 
VGA mode full screen, which i think is what people think of when they full 
screen a command prompt, or a dos game, or a movie, and probably does *NOT* 
relate to GUI apps that enter full screen mode.

An amusing Mac reference for netscape netcaster:
http://www.netscape.com/eng/mozilla/4.0/relnotes/relnotesm.html
(multiple monitors aren't supported)

Note that this bug appears to be drifting heavily to the Gtk toolkit, do people 
want to file new bugs for Qt, MacOS, Photon and BeOS? -- I can also file a bug 
asking for spec clarification if necessary...

Comment 44

[Christian :Biesinger (don't email me, ping me on IRC)]

Chris, hm, that's not as intended. it should go only over the screen with
contains the largest part of the mozilla window. I'll look into that.

timeless, feel free to file bugs for the other toolkits (you missed xlib, btw)

Comment 45

[Christian :Biesinger (don't email me, ping me on IRC)]

so... does the patch hide window decorations on KDE for anyone? doesn't for me,
and I suppose this is because KDE doesn't allow doing it that way.

can we just ignore KDE please?

re xinerama, I'll look at that tomorrow. of course, testing will be difficult,
due to lack of a xinerama setup.

Comment 46

[Boris Zbarsky [:bzbarsky]]

This does not really satisfy the criteria for bug 123569:

1)  The patch does not work yet (comment 42)
2)  The patch is not "rotting"; I'm sure biesi can figure out how to get reviews.
    ;)

Comment 47

[Christian :Biesinger (don't email me, ping me on IRC)]

Ahh, just remembered; Chris, you don't compile with --enable-xinerama. In that
case, that behaviour is expected & there's nothing I can do about it, I think.

Comment 48

[Peter Trudelle]

Timeless, that's just a dev plan, not a real spec.  I agree with comment #44; it
is a full *screen* mode, not intended to use the entire desktop to display a
single window.

Comment 49

[Chris Neale]

Christian, added 

ac_add_options --enable-xinerama

to .mozconfig

incremental (make -f client.mk) builds crash,

will try make clean distclean && make -f client.mk on trunk and branch

I suppose --enable-xinerama should have been obvious

:¬)

cdn

Comment 50

[Chris Neale]

addendum, they crash when using either View > Fullscreen or F11

cdn

Comment 51

[Chris Neale]

trunk still crashes on View > Fullscreen and F11

as does branch for both methods

cdn

Comment 52

[Christian :Biesinger (don't email me, ping me on IRC)]

oh great... (btw, branch is irrelevant, the patch won't get there)

can you get a stacktrace?

Comment 53

[Chris Neale]

if I know how to; both seem to crash "cleanly"

cdn

Comment 54

[Christian :Biesinger (don't email me, ping me on IRC)]

if you have a debug build:
./mozilla -g
run
<wait until it comes up, cause crash>
bt

then you get a stacktrace

Comment 55

[Chris Neale]

building from this morning's 'make clean distclean && make -f client.mk'

make -f client.mk build with adjusted .mozconfig :

#ac_add_options --disable-tests
#ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --without-system-nspr
#ac_add_options --without-system-zlib
#ac_add_options --without-system-jpeg
#ac_add_options --without-system-png
#ac_add_options --without-system-mng
ac_add_options --enable-crypto #comment to disable PSM/SSL support

ac_add_options --enable-svg

#

ac_add_options --enable-xinerama

#

mk_add_options MOZ_INTERNAL_LIBART_LGPL=1
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1

#

cdn

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

that means a stack trace is probably useless...


can you try anyway?

Comment 57

[Chris Neale]

you mean the "clean" crash ?

>can you try anyway?

yes, it's building as I type

cdn

Comment 58

[Christian :Biesinger (don't email me, ping me on IRC)]

eh, do you have more than one crash?


oh, you didn't already have a build? In that case, it would have been better if
you had used --disable-optimize --enable-debug (takes 1.5 GB or so, though)...

Comment 59

[Chris Neale]

[same "crash" both branch and trunk]

anyway, I've Ctrl-C'ed the other build, it'll save it keeping me awake
[23:12 BST now]

I'll start it again --enable-debug and --disable-optimize tomorrow

cdn

Comment 60

[Aleksey Nogin]

The "cleanlinnes" on the crash is probably bug 148453

Comment 61

[Chris Neale]

Attachment: Startup debug data to stdout

pertinent(?) bit at end:

/opt/src/mozilla_trunk/mozilla/dist/bin/mozilla-bin: error while loading shared
libraries: /opt/src/mozilla_trunk/mozilla/dist/bin/components/libwidget_gtk.so:
undefined symbol: XineramaIsActive

crash from View > Fullscreen, haven't got it to restart to test F11 : )

cdn

Comment 62

[Chris Neale]

[ profile hiccup : ) ]

F11 does exactly the same

/opt/src/mozilla_trunk/mozilla/dist/bin/mozilla-bin: error while loading shared
libraries: /opt/src/mozilla_trunk/mozilla/dist/bin/components/libwidget_gtk.so:
undefined symbol: XineramaIsActive

HTH Christian

cdn

Comment 63

[Brian Ryner (not reading)]

Hm, so I didn't notice this bug when I filed and fixed bug 157371 (implement
nsIWidget::HideWindowChrome on gtk).  I'll have to say that this patch looks a
whole lot more complicated than the one I did in that bug, although I haven't
tested my patch on multi-head displays.

Comment 64

[Diego Biurrun]

Brian, I just pulled and built from CVS...  Your work does not really create a
true full screen mode, I still have window decorations with sawfish-gnome
1.0.1.20020116 on Debian Woody.  Seems to be a positioning problem, though, the
window is larger than the screen and if I move it a bit I can make it cover the
screen without the decorations being visible.

Biesi's patch did not have these problems.

Comment 65

[Brian Ryner (not reading)]

Did you test with my patch from bug 157371 manually applied, or with the current
trunk source as it is in CVS?  The first patch on that bug had some problems; I
tested the second patch with sawfish and it seems to work.

Comment 66

[Brian Ryner (not reading)]

Ok, I had the wrong answer to blizzard's question about whether we need to
support calling this on a non-toplevel widget.  We do.

Patch coming up to fix this problem and enable fullscreen mode.

Comment 67

[Brian Ryner (not reading)]

Attachment: Fix toplevel widget problem and enable fullscreen mode

Comment 68

[Diego Biurrun]

Applied your latest patch, rebuilt and all is well.  Window decorations are
hidden as they should be, we have a true full screen mode.  Please get this
reviewed and checked in as soon as possible.  Good work!

Comment 69

[Christopher Blizzard (:blizzard)]

Comment on attachment 91760 [details] [diff] [review]
Fix toplevel widget problem and enable fullscreen mode

r=blizzard

Comment 70

[Nick Pietraniec]

so, should I use both patches if I'm going to build/test again?

Comment 71

[Diego Biurrun]

No, apply bryner's patch to latest CVS.  That should be enough.

Comment 72

[Simon Fraser [no longer active]]

Comment on attachment 91760 [details] [diff] [review]
Fix toplevel widget problem and enable fullscreen mode

sr=sfraser

Comment 73

[Asa Dotzler [:asa]]

Comment on attachment 91760 [details] [diff] [review]
Fix toplevel widget problem and enable fullscreen mode

a=asa (on behalf of drivers) for checkin to 1.1

Comment 74

[Nick Pietraniec]

Attachment: snapshot w/ final patch

Snapshot w/ the last patch (kde).  Looks awesome...  Thanks guys.

Comment 75

[Nick Pietraniec]

I hope I'm not jumping the gun, but I filed bug #158226 about the kde toolbar
staying present in fullscreen mode.

Comment 76

[Chris Neale]

Moz window loses focus in KDE;

my build of moz trunk with patches for fullscreen on Linux
loses focus in KDE3.

i.e. pressing F11; causes Moz window to become fullscreen (bar kicker area),
except that KDE focus jumps to another maximised window

Comment 77

[Brian Ryner (not reading)]

Please file a separate bug on that.

Comment 78

[Chris Neale]

filed bug #158361 Toggling Fullscreen Mode in KDE3, Mozilla window loses focus

Comment 79

[Cedric De Wilde]

Attachment: Fullscreen under WindowMaker

Under WindowMaker, the clip isn't covered by the fullscreen mode. With galeon
1.2.5, it works perfectly. It's windowmaker 0.80.1 and xfree 4.2.0

Comment 80

[Darin Fisher]

under GNOME2, switching to full screen only works once.  the GNOME2 menu panel
at the top (default config + metacity) continues to consume part of the screen
on subsequent attempts to make moz go into full screen mode.

Comment 81

[Brian Ryner (not reading)]

I think setting the WM fullscreen hint will help these problems.  However, it
will require changing the fullscreen code in GlobalWindow, as I believe setting
this hint takes care of positioning and sizing the window, and restoring its
previous state when leaving fullscreen mode.

So, I would propose moving the fullscreen implementation down to the widget
level (i.e. nsIWidget::MakeWindowFullScreen(PRBool aFullScreen)), and moving the
existing positioning and sizing code into the win32 implementation of that
method.  I think we should leave HideWindowChrome as it is, as it may have uses
other than fullscreen mode.

Comment 82

[Christian :Biesinger (don't email me, ping me on IRC)]

since bryner fixed the part that I tried to fix, assigning this bug to him.
Thanks for your work - my first attempt was similar to yours, though I didn't do
the Xsync which made my attempt not work on my sawfish WM - this is why I tried
the galeon code.

Comment 83

[jjkarppi]

Cedric: You probably mean the dock, not clip. Anyway, right-click on it and
deselect "Keep on top". After that full-screen mode works perfectly under Window
Maker. (Except that the minimise button doesn't seem to do anything...) 

Comment 84

[Cedric De Wilde]

Yes you're right, it's the dock sorry. 

But it's not normal, the dock should be covered by the fs mode. It's not  really
easy to select and deselect the option "keep on top" at each mode change. In
galeon, it work well, it's why i've made a comment

Comment 85

[Havoc Pennington]

The correct approach to this bug is a) use the FULLSCREEN hint and
b) ignore any bugs about stacking or positioning with respect to docks, panels,
etc. because they are all window manager bugs.

I would drop fullscreen mode out of the UI when the WM doesn't support the
fullscreen hint, because any way you implement it will be buggy and broken.

Comment 86

[Brian Ryner (not reading)]

I like hp's suggestion, but it will require a rework of how fullscreen works on
Unix, since it looks like the fullscreen hint automatically takes care of
maximizing the window and removing chrome.  So, I'd suggest we move the
implementation of fullscreen from nsXULElement down into the widget code so that
this can work differently on Windows and Linux.

Comment 87

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 167666 has been marked as a duplicate of this bug. ***

Comment 88

[Christopher Aillon (sabbatical, not receiving bugmail)]

Nominating attachment 91760 [details] [diff] [review] for the 1.0 branch on behalf of [e-mail]
(Bamm Gabriana). See bug 167666 for the full text of Bamm's request.

Comment 89

[Diego Biurrun]

Hmm, I'm tempted to resolve this one as FIXED since we now have fullscreen mode
on Unix.  What about the Mac?  Does it work on OS X?  I suppose so.  I
personally don't care much about Mac OS, so I guess a new bug should be opened
for this.

Comment 90

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #89 From Diego Biurrun 2002-11-06 04:33

> Hmm, I'm tempted to resolve this one as FIXED since we now have fullscreen mode
> on Unix.

What about Photon, etc.?

> What about the Mac?  Does it work on OS X?

I don't think so.

> I suppose so.

What makes you think so?

> I personally don't care much about Mac OS, so I guess a new bug should be
> opened for this.

Why, the summary clearly mentions "Mac".

Comment 91

[Gerry Singh]

The ONLY reason I voted for this particular bug is because I am 
interested in having this feature work on Mac OS X  which is, by the way, a 
version of UNIX. 

They have fullscreen mode working in Opera for OS X (albeit, not that 
great).  Mozilla for OS X and other versions of UNIX have been waiting all 
these months for this feature too.

Comment 92

[Andrew Serff]

I aggree with Gerry.  I voted for this bug because it didn't and still doesn't
work on OS X.  So I don't think this bug is fixed yet.  I didn't know opera did
it...I'll have to check that out.

Comment 93

[Nick Pietraniec]

I don't understand why the fullscreen bugs keep morphing from general bugs 
to "we fixed it on platform x, let's close this bug and file another!"

If a separate bug is going to be filed for each platform, (as they probably 
should be) let's do it now instead of everyone getting miffed (again) and 
having to move their votes (again).  

Comment 94

[Diego Biurrun]

*** Bug 183988 has been marked as a duplicate of this bug. ***

Comment 95

[Matthias Versen [:Matti]]

*** Bug 213307 has been marked as a duplicate of this bug. ***

Comment 96

[Jan Varga [:janv]]

I use BeginFullScreen to hide the system menubar and dock on Mac OS X (I don't
create a new native window). Does anybody know a way to hide the titlebar and
window border (on existing window)?
Thanks

Comment 97

[Markus Stange [:mstange]]

Now fixed on Mac, too. (bug 370857, bug 505699)

Comment 98

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified with Minefield builds on each platform like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090908 Minefield/3.7a1pre ID:20090908030622

Comment 99

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Now everything looks fine on 1.9.2 too with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre ID:20090922041132