WindowMaker by default maps F11 to "Open Window list menu" Making it diffcult to un-full-screen Mozilla. You might consider; A> tell people to disable that feature in WindowMaker in the release notes. (If you want me to write howto, I can, just ask.) B> make a alternate maping available. (Ctrl shift F11) ? C> make it a customizable option.

My understanding is that some keyboards (international?) don't have function keys at all, and mac users are also strongly opposed to programs usurping F-keys. How does one get into fullscreen mode initially? F11 doesn't seem to do anything here (gnome/sawfish), FWIW.

for [cross-]reference, bug for implemented fullscreen mode is 68136.

Is the floating toolbar included in the tab cycle?

F11 in Moz when using Gnome 1.4 and sawfish 0.38 works fine.

Why don't you change F11 into F12? After all, MultiZilla users are already used to this function key, so why not?

f11 was picked to match ie-win's key. picking f-12 would just annoy everyone. => not going to be done.

"picking f-12 would just annoy everyone." everyone? You better read the download numbers first, before adding a very silly comment!

window makers binds are easily remapable. window maker has a relatively small user base. no other window managers map f11 by default that I'm aware of. parity with w32 IE in w32 moz is very nice. parity with w32 moz in linux moz is very nice. there is a menu entry to enter, and a button to leave, making the f11 binding being inaccessible a nonfatal issue. Suggest WONTFIX. I remember quite a few other applications that use F11, which caused me to remap window managers keybinds when I used it long, long ago.

jmd, bad suggestion: Relatively few users use Linux compared to Windows and Mac, why not completely cut the Linux builds too? Then we don't have to worry about who maps what on Linux. No, the real solution to this bug is bug 115183 -- apparently as bz noted, Classic Theme has a button to exit out of full screen mode. Modern doesn't. Put a button on Modern and problem solved.

Should this bug be duped to bug 115183, or left open to discuss a possible relnote if 115183 isn't fixed by next milestone? To all those making suggestions as to changing keybindings, etc. note that it's not a really good idea - some users will have it mapped by their WM no matter what you choose. (Personally, I'm glad my WM maps it -- it prevents me from accidentally entering full screen). And one more note: this bug is in Documentation. If we're looking for a solution to the problem, this bug should be in a different product/component. 115183 is already there.

When in fullscreen mode while still having a small menubar, why not add a small new button to the right of the bar (like the close tab 'X') to exit the fullscreen mode. This is intuitive for those who do not remember the keyboard shortcut, while it allows to escape the fullscreen mode, even when F11 is already mapped. Also, I do not know whether its a bug or not, but try this: 1. enable fullscreen mode 2. exit mozilla 3. restart mozilla (should be in normal mode) 4. open a new tab with ctrl-t Is it desired that the new tab is in fullscreen mode again?

Full-screen mode has been removed from Mozilla and will not be present in the next milestone (it's already gone in the nightlies). This bug should be closed as wontfix/invalid.

Linux has no full-screen mode -> wontfix

Linux has had fullscreen. I've used it once or twice. It worked, once, too. Just because it doesn't work now doesn't mean it'll never work. If there is a bug somewhere where someone with authority said fullscreen will be taken out of linux builds, then reference that bug here. And for what it's worth, recent CVS still has a View->Full Screen menu option in linux. I imagine current reality trumps a year-old comment (chances are, the decision was changed or someone fixed a bug that prevented it from working).

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

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