This is split off from bug 3341. Mozilla should have a Full-screen mode, accessible from the `View' menu. In such a mode, by default the only chrome would be: * the menu bar at the top of the screen * the status bar at the bottom of the screen * Back, Forward, Stop, and Update buttons at the left end of the status bar. In full-screen mode, toolbars could be turned on and off just as in normal mode; their state in full-screen mode should be remembered separately from their state in normal mode.

I'm not convinced that the status bar should be on by default (sure it's useful, but is it essential?). However I do think the location bar is needed (otherwise the user could only follow links). Surely, the Back, Forward, Reload and Stop buttons would have to be smaller to fit on the left-hand side of the status bar. I think that by default just the navigation bar (with location bar) should be displayed by default, possibly with smaller buttons. A 'Full-screen Options' submenu could be added to the right-click menu allowing users to choose which toolbars they want to have on screen. It would also be nice if an auto-hide feature (similar to IE) could be implemented, so the toolbars only appear when the user moves their mouse to the top or bottom of the screen. Finally, a Windows only point: would the taskbar be flicked into auto-hide mode while Mozilla is in full-screen mode (like IE). I suppose this could also apply to the Mac OS X dock (but I'm not certain exactly how the dock operates).

If the status bar should be around for the progress meter, then I suggest putting the progress meter where IE puts it, near the throbber.

We need to be able to get rid of _everything_, potentially auto-hiding it like IE for Windows does (hit F11, right click on the bar at the top, and chose auto-hide.) I know Ben has a thing for smoothly scrolling toolbars...

The currect patch for 3341 should be a start for hiding everything.

What should happen if I ctrl-click a link while in full-screen mode, or click a mailto: link?

Is this bug depending on that we should be able to patch userChrome.css?

This looks to be quite easy in fact, i may take this and do it tonight. I'm assuming fullscreen for navigator only... I would put a menuitem in View, and a menuitem on the context menu for this, as well as make a keybinding for quick access. More info tonight...

> What should happen if I ctrl-click a link while in full-screen mode, or click a > mailto: link? The same as usual -- but new windows wouldn't be maximized (they shouldn't be, in any case). Kerz: This probably isn't as easy as it looks -- you'll need help from XP Toolkit people to draw full-screen windows without title bars or other chrome, and the mechanism for doing that will be different on each platform. You could do the intra-window stuff, though ... But keep your sticky fingers out of the context menu! Full-screen mode won't be switched *nearly* often enough to deserve a context menu item -- or a keyboard shortcut, for that matter. Having a keyboard shortcut would be an especially bad idea, since when users hit it by mistake they will have no clue what they just did, or how to get out of it. (I know this from personal experience -- I'm the one who has to go and help all the customers who overshoot the Backspace key, hit F11 by mistake, and then complain that `all my buttons disappeared!'.) And Alt,V,F is easy enough to type that a keyboard shortcut wouldn't provide much advantage anyway.

Perhaps this is a different bug, reading the summary seems to indicate that. I am working on a fullscreen mode that hides all xul chrome, in other words, only the title bar shows. Context menu works fine in this. My plan was to add a menuitem to the context menu only while in fullscreen mode, to take you back out. Anyways, i am blocked because i cannot use element.style.display = "none" as it has not been implemented for xul. I don't want to muck with hidden attributes on xul, because that would mean i'd have to somehow remember the state they were in prior to going into full screen. Maybe i'll open a new bug, or just make this an installable addon, if i can ever get it to work how i want it to...

Well, one of the advantages of using full-screen mode on Windows would be that you *wouldn't* have a title bar, so the menu bar would be touching the very top of the screen ... so Windows users in full-screen mode could use their menu bar just as quickly as Mac users can use theirs all the time. :-)

In my design there is NO menu bar. None. This is the same as 4.x's fullscreen. Meaning, all I am doing is getting rid of the chrome in the window. I'm not touching any native window bits. That would be 4.x's canvas mode, and would require a much greater, and much deeper, amount of work.

I believe what people are really looking for is something like IE's fullscreen mode where all OS chrome (including the taskbar, etc) are hidden. Hotspot regions at the edges of the screen would allow chrome to be displayed on demand (minimal toolbar, sidebar, OS taskbar).

But what Kerz is talking about is a start. Maybe it would satisfy some people for now?

As an add-on package, sure.

Added self to cc.

4.x had a similar kiosk mode...4xp

arg. which bug is tracking the xptoolkit stuff? i think 3341 is kiosk/full screen.

Bug 3341 started out as a feature request for a full-screen mode but evolved into a kiosk mode enhancement. This bug was split off from bug 3341 to cover just the full-screen feature (and not the kiosk mode). Therefore, 4xp shouldn't be a keyword.

you missed my point. 4x did have the toolkit for this, so it is 4xp but this bug probably belongs to toolkit. reassign

->future

Here's my quick-hack I'm using for "fullscreen": expand window out of screen, hide all irrelevant XUL stuff (everything except box with browser). I touched 3 files: "platformNavigationBindings.xul" - add support for F11 "navigator.js" - function to call after F11 (also some init and object to store original position - Fullscreen object, BrowserFullScreenModeInit(), BrowserFullScreenMode(); hmm, I should rename it :) "navigator.css" - class for fullscreen (not very smart - works for one skin only) O.K. - it's not real fulscreen, at least I don't know how to get rid of Windows-main-panel (or how is it called; I think it's not possible from JavaScript, right?). But it's easy and very handy sometimes.

Argh, sorry for spam - those files are for build 2001041620. For another one just extract appropriate parts.

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

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

->danm/patch

How about an Opera-style full screen? No window frame, no toolbars, no title, no statusbar, no addressbar. Just the current page, stretched to the size of the screen and on top of every other window. Very usefull, IMHO.

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

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

Unduping my bug and marking dependant. It's requesting that the menubar simply be manually disableable, which is probably a step on the road to fullscreen, but quite a differant option. As I said there, Mozilla would have a manually reachable fullscreen on UNIX except for the menubar (Manual meaning the user needs to configure their window manager to unborder and maximize the Mozilla window, which I happen to have bound to Meta-X).

This is a popular request and although I'd never use this myself (I rarely maximise never mind full screen), I'd say this is something that definitely should be added, I can see the main use is for people who want to do presentations using HTML, CSS and anything else that mozilla will support in the future.

Kerz, have you been able to improve on your patch at all? Would be wonderful if we could shoot as a 1.1 feature. --Jedbro

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

Added myself to Cc.

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

Would like to comment that K-meleon a Gecko based browser has a Full-screen functionality working in latest version. Perhaps something should be looked into there.

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

Since the feature bug I opened for my own use to track Netscape's work on this issue has been closed as a dup, I guess I have to take over this bug for use in planning and tracking the work. Adding pertinent comments from my bug below. Please continue any discussion of this feature in the appropriate newsgroup, not in this bug report. Comments on the plan itself (such as Mike Lee's below) are most welcome here. Proposed requirements: * First step may be a single click menu item in View called Full Screen that deselects Personal toolbar, Status bar, Menu bar, and My Sidebar, leaving only the Main Toolbar. * Text only option for toolbars Current engineering plan for this work is at http://mozilla.org/xpapps/MachVPlan/Full_Screen_Mode.html Netscape cannot afford the 'complete' implementation, so unless we get some volunteers, we'll be implementing the 'slimline' option. Assigned to Ben for planning/design, currently estimated at 5 days to imlement. ------- Additional Comments From R.K.Aa 2001-09-30 21:28 ------- related: bug 68136 ------- Additional Comments From Mike Lee 2001-10-04 19:34 ------- Can I ask why "c) Discover a mechanism for creating a window that floats over the taskbar,but shifts behind it in z-index when the mouse hovers over the edge of the screen that the taskbar is attached to (hard) - swag: 7 days for me." is a requirement? Internet explorer certainly don't do that, and I seriously doubt anyone is going to use it, the point of having fullscreen is so we don't see the taskbar. Its probabily best if the minimal UI is created. That we we 'kind of' have a fullscreen mode, and see if someone come around to make removing titlebar during runtime scriptable.

From the plan, under Linux: > c) Need ability to hide common desktop utils like gnome/kde taskbar, no > estimate as again I have no knowledge in this area. Look at something like the 'gqview' graphics program. It's a nice lightweight image program, similar to the old versions of acdsee for windows. It includes a fullscreen mode (right click in the main pane). Doesn't seem to use the DGA extention, but works nicely, whatever it's doing. I guess you can't look at the gqview code though, since it'd be only GPL licensed. It's method should work for all UNIXes, not just Linux, or just GNOME, or just KDE.

I think that to implement full screen mode on Linux we only have to take a look at the code of Mozilla PopUp menus and PullDown menus. These widgets are drawn on top any other window or gnome/kde taskbar.

As I put forward in bug bug 104136, I think it would be a neat feature to have the equivalent to fullscreen mode, but without maximisation... Because it would be nice to just hide all the chrome fr a short time while reading a website... that's my thoughts anyway...

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

r=law for Ben's engineering plan and the 4-5 day estimate; I only looked at strategy 1).

i prefer the secound plan, because the first is not a real fullscreen mode. it's more like a 'maximum panel feature'. ok, it's a nice feature too, for people how didn't want to hide all other windows only for browser and maximize the viewpanel. i think it isn't good to implement a half solution. i prefer to add both options. we could save time to move the platform dependend parts in different bugs - the guru's there should implement this.

Yeah, I completely agree. We should go with strategy 2. Include from the first strategy, however, this: > Could require special smaller icons for skin - UE/Skins requirement. The current icons, even if they didn't have text labels attached, would still be too big, IMHO.

Reassigning

alecf, ben please review.

Question about fullscreen, will you be able to script to apply fullscreen? Like IE:s window.open("","","fullscreen=1"); ?

That would be horrible to do, especially since it opens Mozilla up to the full screen spam some pr0n sites have. Other than for those types of ads, what good is scripting fullscreen?

Comment on attachment 54601 [details] [diff] [review] patch to implement full-screen mode Yikes. let's use JS hashtables instead of magic indexes... also, I'm concerned that we're storing too much state in the "elemList" array (which is a arbitrarily generic name) i.e. instead of accessing array[i], array[i+1] etc.. let's access array[i].id, array[i].attribute, array[i].newvalue, etc As far as storing state, why do we need this concept of "cycling"? Why can't we encode the specific modes into the array: (I might not have the exact syntax right, you'll have to look this up online) var fullScreenElementChanges = [ { id: "main-menubar", attribute: "hidden", fullScreenValue: "true", normalValue: null }, { id: etc....

> As far as storing state, why do we need this concept of "cycling"? Why can't > we encode the specific modes into the array: Why should we? It just adds an unnecessary field to the array and unnecessary complexity to the routine that processes the array. Originally I had two routines, one for entering fullscreen mode and one for leaving it. But then I looked at the routines and realized that there was no need to have two separate ones. Indeed, by being table driven, all I needed was the one toggle routine with no need for the routine to even know which state it was in.

How does this handle additional toolbars, like the Links Toolbar?

It handles the links toolbar very well. See the following entry in the fullScreenElementChanges table in the patch: { id: "linktoolbar", attribute: "hidden", value: "true"}, If other toolbars are added in the future, similar lines for them would have to be added to the table.

my concern with the toggling is that things might get out of sync if the code changes in the future, for example if some initialization gets called twice, or someone invents a UI which allows you to toggle some arbitrary prefs. for example: + + if (pref.GetBoolPref("browser.fullScreen")) { + BrowserFullScreenToggle(); + } What if we're already in full screen when this code is called, just by some wierd case? We could solve this by EXPLICITLY saying that we want to go into full screen mode: BrowserFullScreenSetMode(pref.GetBoolPref("browser.fullScreen")); where BrowserFullScreenSetMode() is some function that explicitly sets the browser into full screen or back to normal, based on some boolean expression. I'll even play devil's advocate with myself: but the code as it is written garantees that the "toggled" state is never reversed! Why should I try to handle that case? The answer is that many people maintain this code and do not necessarily know the implications of tweaking or moving every line of code. Your code sould be robust and explicitly request a particular state, instead of relying on a preexisting state. Also, you seem to be using the pref as a way to store state, but are not reacting to someone else changing that state. The rule is that if you're going to set state based on a preference, you have to set up a pref observer which reacts to that pref changing. There are any one of a number of ways that a pref value can change, not the least of which is someone adding a pref UI.

Dean, I didn't realize the full implications of your comment. You were really asking about chrome elements that were in overlays and how would they get added to the table. I don't have an answer for that yet.

Alec, you raised some good points about the possibility of getting out of synch. So I'm attaching a revised patch to protect against that. Basically I added a separate FullScreenEnter method which calls the toggle routine only if we are not already in full screen. (There already existed a FullScreenExit method in my patch.) We still want the toggle routine as well because (1) it makes the entering and exiting more unified and (2) toggle will be called directly when the F11 key is pressed -- in that case we don't care which state we are in but we do want to get to the other one.

Alecf, Regarding the pref, it is only used so that I can restore the same state at browser startup that it had the last time the browser was exited. It's not intended as a means to allow some other module to effect an entry into fullscreen just by modifying the pref, nor for a pref UI to be added. If having a pref requires all this other baggage, then suppose I don't use a pref. Is there some other means of maintaining this persistence that I should use instead?

I'm still concerned about the fact that we have 3 states which must be kept in sync: 1) the actual full-screen state (which could potentially vary from window to window) 2) the "fullScreen" global variable (which is only "global" per window) 3) the "browser.fullScreen" preference (which is actually global) This actually makes me realize that we could easily, even with this code, get into a wierd state. For example: - Open 2 windows - In one window, hit F11. That window will go into full screen mode, and set the the browser.fullScreen pref and the window-global fullScreen variable to "true" - Alt-Tab to the other window. Now hit F11 again. Now the pref, which was already "true" will get set to "true" again, the fullScreen variable for this window will be set to "true" as well. - Now hit F11 again. Now the 2nd window's fullScreen variable, plus the global browser.fullScreen pref are set to "false" but the first window's global variable is set to "true" - now the way this code is layed out right NOW this out-of-sync state is alright, but what if some new code decides to look at the pref instead of the global variable? If I'm a new engineer, how do I know which one to look at? can we unify at least the global variable and the pref? Here is my suggestion: - when the key presses, toggle the preference - that way you are toggling the global state of the pref, and not depending on the actual state of a local, per-window pref. - use a pref observer to observe full-screen state. Each window will have one of these observers - when the pref observer fires, look at the new pref value, and explicitly change your state to match the pref. This is all assuming that full-screen mode is something that's a full across-the-product mode. if it's a per-window state, then we shouldn't be using preferences at all. It seems like this feature hasn't been fully thought out, frankly...

Just saw your comments - it sounds like dumping the use of prefs would be the ideal situation. One non-pref way of maintaining state is by using XUL persistence via localstore.dat. It basically allows you to retain the value of DOM attributes across sessions. look for some examples of dom attributes with the "persists" attribute

I'll take a look at this tomorrow afternoon after my S&C Final.

One question: Has anyone working on this seen what MultiZilla's "fullscreen" mode does & maybe try to improve upon it, rather than reinvent the fullscreen? It seems to work rather smoothly and the only thing keeping it from a true fullscreen is the titlebar that remains. *shrug*

Dean, I now have an answer for how to handle chrome items coming from overlays such as the linkbar. Rather than having the list of chrome elements (toolbars, buttons, etc) in a javascript table, put it in a xul structure. That way, the overlay can access the xul structure and add the name of its toolbar into the list. This is exactly the way it added the toolbar into the chrome, so now it uses the same mechanism to add the name of its toolbar into the list. Attaching a patch that incorporates this xul-based change table.

A quick comment and a couple of questions to satisfy my curiosity... + <box id="fullScreenElementChanges"> You could probably make this "<data ..>" rather than <box>, so that by default it doesn't have any presentation. + <key keycode="VK_ESCAPE" oncommand="BrowserFullScreenExit();"/> Why Escape? Would this interfere with the fact that Escape is also bound to "Stop"? + <data idx="back-button" attribute="class" value=""/> What's the visual impact of setting class to ""? I have a vague idea of what it might do in Classic but not in Modern...

if ben is ok with the general approach, then I am...however now that I'm looking at the individual entries, I'm wondering why we can't just use the "hidden" attribute for everything?

Ben: Making the enclosing entity be <data> instead of <box> is a good idea. I wasn't sure of the exact semantics of <data> (it's not even mentioned in the xul reference guide) so I arbitrarily picked <box>. I'll change that to <data> Reason for escape was to give the user some way to break out of fullscreen mode when he got into it by accident. I figured F11 wouldn't be at all obvious to him (it will also get him out) and that in frustration he might try hitting escape. Will this interfere with STOP and, if so, how can we fix that? The visual impact of setting class to "" in classic mode is to no longer allocate space at the bottom of the image for the label. If I didn't do that, then the toolbar had the same height that it had in normal-screen mode, but with this change I was able to get the toolbar to be skinnier. In modern this had no effect. ----------- Alec: Hidden is used for those xul objects that need to be hidden. For example, the status bar. I don't want to hide the "back" button but instead want to remove the text from it. That is why is need to change its value attribute. And I want the image for the "back" button to be smaller which is why I had to change its class attribute.

"Will this interfere with STOP and, if so, how can we fix that?" Use a different key. Having Esc do two things will be very confusing. What happens when I press Esc while in full-screen mode and loading a page? Does the load stop and the window restore?

We already are using a different key, namely F11. However the discoverability of that will be impossible, especially since we don't have the menu when in fullscreen mode. But you are absolutely correct -- I broke the ability to use escape to stop page loading, both in fullscreen mode or in normal mode. That's certainly unacceptable. Suppose I fix things up so that at least escape works correctly in normal mode (stops page loading) but in fullscreen mode it does a switch to normal screen? While in fullscreen mode, the user can still stop a page load by pressing the stop button (that button is still visible). It's probably more important to give the user a discoverable way to exit full-screen mode when he got into it by accident than to give the user a shortcut for aborting page loading when in fullscreen mode.

How about putting something like "Exit Fullscreen Mode" into the right click context menu?

> Suppose I fix things up so that at least escape works correctly in normal mode > (stops page loading) but in fullscreen mode it does a switch to normal screen? > While in fullscreen mode, the user can still stop a page load by pressing the > stop button (that button is still visible). How about making it a pref? The default should be Esc = Exit Fullsreen Mode so people who go fullscreen by accident can get out of it, and people who know and use the fullscreen mode can still choose to press Esc to stop loading a page.

I really think that Esc should always do the same thing. What about a button on the toolbar, visible only when in fullscreen mode?

95% of users will try Esc first anyway. Maybe a pop-up modal window asking Do you want to: [o] Stop the page loading [o] Exit the full screen mode The downside is that we are supposed not to like modal windows.

i prefer to add a warning message on entering fullscreen mode +---------------------------+ | press F11 to escape | | fullsceen mode | | | | O never show this message | | [ OK ] | +---------------------------+ everyone should notice them on accident. a popup entry is also very usefull

How about we copy PC Anywheres setup? PC Anywhere has a fullscreen mode with a non-obvious exit. When you enter it, though, it displays a dialog explaining briefly what is happening and how you get out. (Incidently, it's Alt+Enter for PCA). +----------------------------------------------------+ | You are now entering full-screen browsing mode. To | | return to normal mode, press the F11 key | | | | [ ] Don't show me this again | | | | [ OK ] [ Cancel ] | +----------------------------------------------------+ Text might need some work, but I think this is alot better then messing with the meaning of ESC. mpt, this acceptable use for a dialog? Any better ideas here?

No warning dialog, no way, no how. Can we please get out of this 'Are you sure?' mentality? Users are not idiots making endless mistakes we need to protect them from. If they say go to full screen mode, then by Gum, we damn well better get them there PDQ. BTW, I agree with Jacek that 95% of users will try esc and expect it to work. Is there really a problem with overloading it in this instance? Couldn't it still be used as stop, and where there is nothing to stop, it could exit the mode?

> Couldn't it still be used as stop, and where there is nothing to stop, > it could exit the mode? I think a bunch of people hit ESC multiple times, since in NS4, well, it took four or five times for animations and loading to actually stop. I think a one time dialog for an advanced feature like fullscreen is acceptable, and I'm normally opposed to such dialogs. Fuck, we're still poping up a warning every time a user submits a FORM until they check the box (which my parents still can't figure out). Why not pop up a dialog when Mozilla starts saying the Internet is a big scary place and there's someone somewhere watching everything you do. > If they say go to full screen mode, then by Gum ...they better know how to get out? I think the problem we're trying to address here is when they DIDN'T say they wanted full screen mode... they clicked a button that looked odd... and now they're stuck. Having the UI be "well...er...they'll probably guess to press ESC eventually" with no way for them to actually KNOW how to return is certainly no better then a small dialog. Dialogs that are short enough tend to get read. And I know PLENTY of users that would be calling me, or pressing ctrl-alt-del and killing Mozilla before they try ESC.

Latest patch changes <box> to <data> per Ben's suggestion. It also fixes the behavior of escape so that it works properly in non fullscreen mode. The behavior of escape in fullscreen mode is that it exits the mode. I am investigating how I can detect that some activity (e.g., page loading) is currently going on and should get the escape instead. If I can figure out how to do that, then I'll make that change. If anybody knows how I can do that, please speak up.

Jeremy: I know a lot of people bright enough to try Esc but not F11. I would still suggest usinfg Esc for leaving the fullscreen mode *at least* after the page is fully loaded (when there is no other reason to use Esc. And I still believe that +---------------------------+ | Do you want to: | | | | O stop the page loading | | O exit fullpage mode | | | | [ Cancel ] | +---------------------------+ is the best solution *before* the page is fully loades. After that Esc should simply exit the fullscreen mode.

> when there is no other reason to use Esc ESC is also supposed to stop animated images (currently broken) and javascript (not implemented yet). At least provide a hidden pref to disable this ESC leaves fullscreen nonsense for users who want to use it for the other stuff and nothing else. And preferably the final fix is get a toolbar with a mode switch button during fullscreen, like IE, and then remove this ESC entirely.

the question is will 91% hit escape twice when they want to leave. If the answer is yes, then i think it's fine to do this. Specific behavior: escape-escape (limitted time window): quit fullscreen escape: w/ no stop response available: quit fullscreen escape: w/ some stop response available: some stop event This way if i need to stop page load and then stop javascript i'll have to <esc> {pause} <esc> [assuming we ever support that]. time window should take into account OS key repeat timeout value. So if keyrepeat timeout is X we should wait at least 1.5*X before deciding not to quit fullscreen. For for accessibility we should not pick a timeout Y less than X -- I can imagine that a user needs and uses a very long key repeat, in which case if they trigger <esc><esc> over their long time X it should still quit fullscreen. Whereas we might have arbitrarily picked a timeout Y less than X which would frustrate such users.

I can see myself using fullscreen mode a lot, and I think I'd find having [esc] take me *out* of fullscreen mode very frustrating, given that there'll also be a perfectly good function key available to do the same thing. It should 'stop loading', and that's *all* it should do... Since we're already putting up "warning dialogs" that can be (semi-)permanently turned off for many other things, the idea put forward by poelzi and Jeremy Dolan seems the most sensible thing to do here, to me. By contrast, overloading [esc] seems like a *more* modal solution, in a sense - escape becomes context aware, and starts to do different (and surprising!) things depending on where you are at the time... :-(

'Seeing yourself' use the app is pure subjective speculation, very unreliable, and worthless compared to watching target users (NOT us) trying to use the feature, which is what we should do to settle this. The fact that we are putting up these dialogs all over the place is not an argument for putting up more; they are almost always a bad idea, and we usually should not compromise the UI in this manner.

I haven't read the other comments in this bug, and haven't tried the patch, but here's a suggestion (sorry if this is way wrong): how about avoiding overriding the already-used Esc key, and put some closebox kind of button in the top right corner when we're in fullscreen mode?

With latest patch, escape is now working as follows: in normal mode: stops any activity in progress in full-screen mode: if any activity is in progres stop the activity else exit fullscreen mode Ben and Alec, Patch is now ready for reviews. Thanks.

Oh good, now I have to remember what Esc does depending on whether I've already pressed it or whether the throbber's spinning? Overloading the key is a bad idea... 1. Enter full screen 2. Click a link 3. Change my mind 4. Start reaching for the Esc key 5. Page finishes loading without me noticing, since I'm looking at my keyboard to find the Esc key 6. Press Esc 7. Look in bewilderment as Moz is no longer in full-screen mode 8. Curse everyone in this bug that recommended that Esc have more than one function. This patch isn't ready for reviews. It seems to me that there's about a 50/50 split right now as to whether overloading the Esc key is the right approach. If you want to get full-screen mode in, the patch should not contain Esc. Get the core functionality in, and we can hammer out this detail properly in another bug.

You've got a good point in your scenario, and you may be correct that that is worse than having no way to exit the mode. However, our opinions don't count for anything to the users of this mode, and IMO deciding on what UI to try is not the purview of the code reviewers either, or shouldn't be; this is an issue for UI designers and usability testing. Overloading esc is cheap to try, the worst case scenario (exiting fullscreen unintentionally) is not at all harmful, and esc is cheap to fix if it *proves* to be a bad idea; but I think it would be a worse idea not to try using the key that most people will likely hit first.

Sure, it's not the duty of the reviewers to make these UI decisions. But if someone's trying to put this in there, then there needs to be a call on whether or not it really belongs. We could very well be jumping to conclusions on whether or not this will even be an issue. I still say we put it out without the overloaded Esc key and wait to see if we actually get any negative feedback on it. We may be surprised at the lack of noise!

give up on this modal dialog junk... we can't please all the people all the time, let's just pick some subset of "all users" .. my vote is for the people who will hit "escape" automatically. The problem _I_ see is that there are two major subsets of users here: Ones who just want the browser full screen temporarily, and those who want to run in some kind of "kiosk" mode. I would say we have some global state which says whether or not we're in kiosk mode... but until we implement some "kiosk mode" feature (that's a whole other bug) we just go with "esc"

I do not buy the "overloaded Esc" argument". You may as well say that Enter is overloaded as it is used everywhere in th UI. Enter is used always for confirming the recent/planned change. Fine. But the same is true about Ecs. It is meant to be used to ESCAPE a recently introduced change restoring the situation to the original one. The vast majority of users who will try this key first is right. It is using the correct key for the the thing it was created for.

We also need a hotkey to initiate full screen. Whatever hotkey that is, can just be a toggle. It turns full screen off as well. We don't have to make accel+letter hotkeys left, however. We may need to use a function key. If you have a key in mind make sure it conforms to: http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html Also please check if it's available by consulting http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html

Aaron, F11 is that hotkey.

Added another patch that uses text instead of images for the back/forward/reload/stop button when in fullscreen mode. That has the advantage of having a skinnier toolbar and therefore more fullscreen. It has a second advantage in that now I could add a return-to-normal-mode button on that toolbar. I couldn't do it before because I didn't want to create an image for it in every skin. Now with this added button, it could be argued that the escape key method of returning is redundant. However I am leaving it in for now -- we can always remove it later if testing indicates that it is getting in the way.

Interestingly, according to http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html, F11 is completely free, but F7 is assigned to "full-screen mode" in Browser Content! Relevant?

IE uses F11, and since NS4 didn't have full screen we have to match, mine as well match IE, so users don't have two differant keys to think about. Also helps them leave fullscreen if they got in accidently, if they know how to in IE. > It has a second advantage in that now I could add a return-to-normal-mode > button on that toolbar. I think a toolbar button, ESC, and F11 is definatly a bit much. IE gets by with F11 and a button. If we can get the button in, that'll be plenty.

Yeah, I think we were concerned that some Macs only go up to F8. That's probably why we had F7 there. Function keys aren't the best for Macs in general, they're supposed to be reserved for the user to assign things to them. If there's also a button to click on with a mouse, I suggest we go with F11 as a toggle, since people will know that.

nc4 did have a full screen mode. that you couldn't get to it from a keyboard shortcut might be different. The arguement wrt Enter is relatively vacuous. Here's the only example i can think of where Enter is similar to the confusion escape can cause: you are on a form page which triggers a download and redirects to another form page. your browser is set to automatically close download windows when done. you trigger the first form and get the download dialog. you sit and ignore all progress indicators and randomly decide when to hit enter. If you hit enter before the download dialog goes away then you've cancelled the download (or something, i can't remember what). if you hit enter after the dialog goes away, you've submitted another form. The big difference here is that in order for enter to be ambiguous, you have to intetionally ignore a progress indicator which is giving you a clear indication of when the world will change. w/ javascripts and page loads you have no such indication. Scripts can terminate whenver they like or never. And we currently have no good way to estimate and indicate to a user when the page will stop loading elements/doing reflows. That aside, if we have a stop button, then we should have room for a restore from full screen button. IE does this [*sometimes]. If we're going to use Text Only buttons then it'd be simple to have a depressed [Full Screen] button, which restored the previous state when clicked. *sometimes. IE has configurable toolbars, and i don't remember the default. if you have the fullscreen button on the toolbar it indeed behaves as described above... Of course, IE also has View>Full Screen F11. Which makes it pretty clear how to enable or disable this mode. Plus, if you right click the toolbar, in addition to autohide, you can enable the menubar (we can't easily do this yet, see some other bug) .. which would let you see F11. IE also paints minimize, restore and close buttons (which look like normal ones except for their coloring) some users understand what restore looks like and what it means (tooltip provided). Maybe many don't. These features have been around since ie4 which is say ~5years [and 3 versions: 4,5,6]. Sorry for a detailed description of a competing product about which we care not one iota.

The big difference here is that while many users do not use keyboard shortcuts *at all*, getting stuck in fullscreen mode will make them use one. In these people having the same key both ways for fullscreen switching will be no help as they didn't enter the mode using a key. Yet even they know what is the use of the Esc key (everybody uses Enter, and almost everybody Esc and Backspace).

You guys make a lot of good points, thank you! IE's fullscreen mode worksforme. I doubt many IE users are reduced to hitting the esc key in vain (as they are in many other apps with more extreme versions of this mode). I don't see why we couldn't mimic the minimize/restore/close icons too, and the right-click to get a menubar would be a plus.

I don't see how we can do that -- since we're doing 'slim' full mode, the titlebar remains, and I think it would be a little confusing for the user to have two sets of window control buttons. What we could possibly do is catch the restore event and use that as an indicator to exit full screen mode (after all, what else do we plan to do if the user is in 'full screen' mode and they click restore? we have to bring the chrome back).

Sometimes the obvious hurts. That makes complete sense to me. Can we catch that event, though?

Catching the restore event would be a windows-only solution and not cross platform.

Nevertheless, I think it's something we need to consider...it would be odd behavior to allow the user to restore the window and still have all the chrome hidden, and still have View > Full Screen checked...

> I don't see why we couldn't mimic the minimize/restore/close icons too Windows only. You could do a Mac one too, but then your screwed for UNIX. No standard button layout. Someone suggested using an 'X' though, which would be fine. Already using that for tabed browsing. Since this isn't even real full screen, the others are unnecessary anyway. > What we could possibly do is catch the restore event and use that as an > indicator to exit full screen mode That's awful. Not only is it windows only, it goes completly against what that button is supposed to do. It doesn't send signals to applications, it's a window manager function.

nope. hyatt killed the [x] from tabbed browsing. there's currently a bug to give an [x] to sidebar, but i'm not 100% certain it'll survive. As for unix, we should be able to recognize size events. So if we ever shrink or grow we can try to figure out if we're full screen. and as for the restore button, i forgot that this bug isn't about borderless. otoh i've been using ratpoison on freebsd and there i have no decorations .. although i can still force mozilla's size to shrink (through a halving process). for now, i see no reason not to respond sanely to the restore event and let platforms try to implement it as best as they can. The restore event is *not* windows only. it also exists on mac, and probably most non X11 ports. [I'd expect it's available in Photon and BeOS among the ports i follow, perhaps even Qt Embedded ..)

Jeremy, it's not awful, it's exactly what IE does, and we're going to have to do it anyways. As I said, you cannot let the user restore an app that's supposedly in 'full screen' mode.

There's a bit of a confusion here over the use of the restore button and the restore event. I thinks it's because we are calling this feature "full screen" whereas we really mean "minimum chrome". Unlike IE's feature, we are not toggling between a reduced window and a true full-screen window. Rather we are removing the chrome from the window but retaining the overall size of the window. So pressing on the restore button will toggle between a true full-screen window and a reduced-size window. It will not change the chrome. Pressing F11 (or escape, or the new exit button that I just added) will change the chrome but will not change the overall size of the window.

In that case, Esc should definitely be out. If we were in kiosk mode (I know, bug 3341) then we could at least discuss it. But if the window can be restored and still not have any visible chrome, Esc won't be obvious at all. I like either a) handling the restore event, although that may be better-suited for bug 3341; or b) having a button on the toolbar to restore the chrome. It sounds like we already have b), but admittedly I haven't looked at the latest patch. If that solution didn't offer Esc, I'd be in full support of it.

* Sorry, slightly offtopic * timelesss: What kind of fullscreen mode did nc4 have and how can you trigger it?

Netcaster, and on irc i guessed ctrl-8. according to a few web sites, i'm right.

Sorry, I came late to the conversation. Someone mentioned waaaay back that the Mozilla browser should not have the option to "OpenNewWindowInFullscreen()" And while I agree that porn pop-ups are totally lame, stuff like this -> http://www.microbians.com/ is really neat in IE. So... the open in fullscreen thing does have a use, even if it is a HUGE hack. This might be a feature request/new bug report, but I thought I'd toss it out there to see how the developers would comment ;)

I think Mozilla is good for configurability to suite a wide variety of users. We can now toggle pop-up windows though a pref setting - why couldn't we do the same with OpenNewWindowInFullscreen()? The user should be able to choose what they want.

I think that fullscreen=1 should be supported. Some of you dont agree because of the porn sites?? Then dont visit those sites.. If people still think fullscreen is annoying they should be able to turn that off in the preferences.

i prefer to options with o allow to open windows in fullscreen o allow signed scripts to open fullscreen windows secound should be checked by default, first NOT :) ps: peter, user make mistakes over and over and over. they should be warned about everything, so it is not our mistake if they can't escape the fullscreen mode, we shown them how. we are not possible to image us, wich a "normal" user browse - we can use bugzilla ;)

+ <box id="fullScreenElementChanges"> + <data idx="linktoolbar" attribute="hidden" value="true"/> + </box> Don't forget <data> instead of <box> here too... + <key id="fullScreenEscape"/> I don't think overloading escape is necessary now you have the toolbar button. Let's just stick with F11 like IE. + <hbox id="fullscreen-nav-bar-buttons" hidden="true"> (etc) Given that you're sticking with the approach of listing items to hide in the data list, it'd be unfortunate to duplicate all these buttons. What we really want is a variation of what I think you had in an earlier version of this patch, setting an attribute on the items listed that triggers a style rule that makes the items smaller.

> Don't forget <data> instead of <box> [in linkToolbarOverlay] Done. That was an oversight. > I don't think overloading escape is necessary now you have the toolbar > button. Let's just stick with F11 like IE. What's wrong with having two ways to do it? Escape is still the first thing I would think of trying when I enter a mode I didn't want to be in. The name on the toolbar button might not be obvious to me. > Given that you're sticking with the approach of listing items to hide in the > data list, it'd be unfortunate to duplicate all these buttons. What we really > want is a variation of what I think you had in an earlier version of this > patch, setting an attribute on the items listed that triggers a style rule > that makes the items smaller. AFAIK, there is no style rule that turns off the image and leaves only the text. According to Hewitt, that would have to be done at the skin level. By duplicating the four buttons, I have a skin-independent solution. I do agree with you that I liked my earlier patches better in which I didn't have to duplicate the buttons, but that was before I went to the text only mode. Why did I go to a text-only mode? Two reasons. First, the text is skinnier than even the smallest images. Second, I would have to create a new gif file for the exit-mode button, and there would be a different such gif file for each skin.

>> I don't think overloading escape is necessary now you have the toolbar >> button. Let's just stick with F11 like IE. >What's wrong with having two ways to do it? Escape is still the first thing I >would think of trying when I enter a mode I didn't want to be in. The name on >the toolbar button might not be obvious to me. Argh, not this again. We do have two ways to do it, the button and F11. As I said before, we're trying too much to predict how often users are going to accidentally stumble across this feature. Please don't overload Esc on the initial implementation. If it does prove to be a problem, we can re-visit the issue later.

I agree with Dean -- I recommend we don't overload Escape at this time, simply because keyboard users use Escape to stop loading and/or stop animations (when that's fixed). If you're hoping/assuming people will stay in full-screen mode for any amount of time, they're bound to hit Escape thinking it will stop page load/animation, only to leave your mode. Questions: - Will ALT+ menu accelerators still work, such as Alt+V for the view menu? - Will other global accelerators work such as Accel+Shift+L to open a web location?

I may be missing something obvious but I keep seeing references to a toolbar button being used to exit full-screen mode. If you're in full screen mode, there should be no toolbars, menus, buttons, etc visible (if there are, then you are by definition not running in full-screen mode).

I'll agree... If someone is using fullscreen and often uses the escape button to stop loading, the two are bound to confilct and cause problems with people popping out of fullscreen mode when they don't want to. If they got into fullscreen mode via F11, I'm sure no one will get "stuck" in fullscreen... It would be logical for them to try F11 even if they tried escape first. I think that binding excape to exit may make sense at first, but I think that for knowledgeable users, it will cause problems.

I am a heavy keyboard user. Moz has all kinds of problems navigating the UI via the keyboard. Making ESC do two different things here would be another keyboard problem - and a bad one at that. I would spend a lot of time in fullscreen (I do when I use IE). And I use ESC _all the time_ to stop loading pages (in Moz and IE). Making ESC do both things would have only one effect: I would be popping out of fullscreen every couple of minutes. I would not be able to use the fullscreen mode at all. my 2 [ non programmer - just an tester / end-user / UI critic ]

Steve, "What's wrong with having two ways to do it? Escape is still the first thing I would think of trying when I enter a mode I didn't want to be in. The name on the toolbar button might not be obvious to me." --- Well it should be. I would submit that if a user does not understand "Exit full screen mode" (which your patch specifies), then he or she will not understand "ESC" "Since this isn't a real full screen mode (that is, the whole screen isn't devoted to content and there are other visible ways to exit the mode, like the button), there's no real need to provide a panic-out. AFAIK, there is no style rule that turns off the image and leaves only the text. According to Hewitt, that would have to be done at the skin level. By duplicating the four buttons, I have a skin-independent solution." --- We're going to need a skin-dependent solution for this anyway, as the text/images toolbar mode requires an attribute set that results in style rules being applied that cause different parts of the anonymous content to be hidden. I talked to Joe about this and he said that tbstyle="images|text|both" has been suggested. With that reigime, you'd set tbstyle="text" on the core navigation buttons, and hide all the others. The style rule might look something like this: toolbarbutton[tbstyle="text"] > .someAnonymousContent { display: none; } (varies slightly between classic and modern skins). Joe and I have no problem with this being a skin-related solution, sometimes a skin solution is the cleanest solution to a problem.

oops, that should have read Since ... and "AFAIK, ...

Comment on attachment 55916 [details] [diff] [review] changing <box> to <data> in linkToolbarOverlay marking 'needs-work' per comments.

Attaching patch to address reviewers comments: 1. Escape key is no longer used 2. Buttons are no longer duplicated

I'm just looking at another bug right now, I'll get to this later tonight.

Hmmm, this all looks and feels rather dirty. It would be so much nicer if one could just tell the button or toolbar, by setting some attribute, whether to display the text, the image, or both. I thought the XUL 1.0 spec mentioned a feature similar to this, and I suspect that there's a bug somewhere on implementing it. Once that's implemented, you could then leverage that and make this code a lot cleaner. As it stands, I'd rather not see this code go in.

bug 22056 - Show toolbars as text/icons/both

I agree with jag in preferring the solution outlined in my 10-31 17:22 comment... using a mechanism such as that you'd a) save a bunch of code and b) make the mechanism cleaner and easier to understand.

Could someone on Windows with this patch add three toolbars to their taskbar (i.e. right click on the taskbar and choose Toolbars|New a few times, dragging them on several sides of their screen), and then put Mozilla in "full screen" mode and get a screen shot?

OK, the infrastructure currently does not support specifying an attribute to indicate if a button should be text-only/image-only/text+image. The patch presented here gave a clean method of accomplishing this within the current infrastructure. The alternative is not to change the nav buttons at this time but readdress that issue when the infrastructure matures. Therefore attaching another patch that leaves the nav buttons unchanged at this time.

another option is to push for "the infrastructure" (a la fixing bug 86455) to mature. don't you and hewitt have the same manager? Work the system! :)

Steve, looking good. You could probably just cut the commented out sections as they serve no purpose when Joe implements tbstyle (shouldn't take him more than a day). Also, it looks like you're no longer using the 'fsid' attribute. With the commented sections yanked & fsid attr removed, r=ben@netscape.com In answer to Alec's pondering, I believe Steve's patch can be altered additively rather than fundamentally when Joe lands tbstyle support. Joe, I'm not sure how you're planning to support tbstyle - were you planning on implementing it as an attribute on individual buttons or on the toolbar itself? If the former, Steve's patch can add additional data elements for each button that is to be shown as text only, e.g.: <data idx="back-button" attribute="tbstyle" value="text"/> or if it's the latter a single item for the navigation toolbar: <data id="nav-bar" attribute="tbstyle" value="text"/>

Comment on attachment 57023 [details] [diff] [review] Remove commented-out code per reviewers request ok, my final request is that "fullScreen" be called "gFullScreen" - it really looks like a local variable, especially within the context of some of the larger functions. with that, sr=alecf (no additional patch necessary) adding r= for ben

I just thought of a VERY cool way of solving this - I hope its actually possible, and I'm curious what you guys think: for each element that is affected by the full-screen mode, you set it up as an observer (using observes="main-window"?) so that when you set the fullscreen="true" attribute on the main window, it gets reflected into any subsequent observers. Then, you just use CSS to style those observed elements, like .status-bar[fullscreen="true"] { display: hidden; } and so forth.

Netscape 4.x has a kiosk mode. The meaning of kiosk mode should be that you would like to run a browser based application for a kiosk terminal, which is exactly the position I'm in. My client wants to deploy an application throughout their facilities on kiosks and doesn't want to know that it is running in a browser, or for the users to be able to muck with anything but the web page contents. (i.e. not titlebar, or anything else) For this purpose, the ability to change the preferences through the UI is unimportant. I hope this gets resolved soon, otherwise we'll have to go to Internet Explorer, and I really don't want that.

Kenneth: You're looking for bug 3341 (found easily by either reading through this bug or searching for "kiosk")

Why was this patch checked in with the addition of a toolbar button without an image that only appears in Classic with the top-aligned text "Normal Screen"? In other words, an obvious UI flaw that would never be found in any other professional product.

Now that I see this in action, I don't quite understand it. I would expect activating this mode to maximize my browser window, which it doesn't. I also think that we need the Location field in there otherwise, as Alex said back on 02-08, users can only follow links.

Blake: This behavior is temporary. All the buttons will be text-only when bug 86455 is fixed. Dean: Location field = ctrl-shift-L. Lack of location field is same behavior as in IE.

Patch was checked in last night. Forgot to mark this as fixed. Doing so now.

I tested this with a Linux debug build pulled from CVS after the patch was checked in, and a Windows nightly build (ID 2001111008), and could not achieve full screen mode in either. STEPS TO REPRODUCE 1. Start Mozilla. 2. Hit F11. EXPECTED RESULTS Web browser should be full screen. ACTUAL RESULTS Some toolbars, the menu bar, and the status bar disappeared. The caption remained. The window did not take the full screen. Even maximising the window did not make it take the full screen. There were other problems, for example (unlike IE) there was no way to enable the menu bar, the location bar, or any of the toolbars while in "full screen" mode. Opening the sidebar (by hitting F9) caused weird behaviour including crashes and missing content. There was no feedback when loading pages (no throbber and no progress meter, IE has both of these). One toolbar remained (with only 4 buttons, and no location bar, making it hard to seriously use this mode to browse the web). The tabs remained, and there was no way to autohide either the tabs nor the navigation bar, so even with the window maximised and the window border chrome removed by the window manager, and all but one tab closed, there was no way to show a web page without Mozilla chrome present. REOPENING.

I think this whole feature should just be backed out until we architect a real full-screen mode that isn't just some hack to hide chrome elements. As is, this isn't compelling in any way to the end user. A real full-screen mode on win32 would hide the window borders and title bar and consume the task bar. IMO this is one of those features that, if we don't do it right, just shouldn't be done at all.

> The caption remained. That is correct. It was not designed to do otherwise. > The window did not take the full screen. Correct again. Again by design. > Even maximising the window did not make it take the full screen. If by that you mean that it still had a caption on top, again this was by design. > (unlike IE) there was no way to enable the menu bar, the location bar, > or any of the toolbars while in "full screen" mode. Because that was not part of our design. If you want that, open an RFE in a separate bug report. > Opening the sidebar (by hitting F9) caused weird behaviour including > crashes and missing content. Now that's serious. I'm unable to reproduce any weird behavior or crash. If you can reproduce that, open a separate bug report, give exact steps to reproduce, include a description of what you mean by "weird behavior", and give the stack dump if there is a crash.

>> The caption remained. > That is correct. It was not designed to do otherwise. Then the design is flawed. >> The window did not take the full screen. > Correct again. Again by design. Again the design is flawed. >> Even maximising the window did not make it take the full screen. > If by that you mean that it still had a caption on top, again this was by > design. No, I meant that the window did not overlap the taskbars and other Explorer chrome, like the IE full screen mode does. >> (unlike IE) there was no way to enable the menu bar, the location bar, >> or any of the toolbars while in "full screen" mode. > > Because that was not part of our design. If you want that, open an RFE in a > separate bug report. To quote from comment #4 on this bug: "We need to be able to get rid of _everything_, potentially auto-hiding it like IE for Windows does." This bug currently is not fixed. There is no code in Mozilla that gives it "a Full-screen mode" like the bug summary requests. Just because some code was checked in using "full screen" as the checkin comment does not mean this bug is fixed. The design does something else -- "quickly turn off some of the toolbars" mode, if you like. It does not do "full screen" mode. REOPENING again. Please do not mark this bug as FIXED until the bug is actually fixed. If you have no intention of fixing it then reassign it to someone else, e.g. nobody@mozilla.org.

The spec for fullscreen mode is available at http://www.mozilla.org/xpapps/MachVPlan/Full_Screen_Mode.html Two alternatives were presented, namely (1) instant hide of UI and (2) complete full-screen mode. It was decided to implement (1). That is what was done and checked in. That is why the bug report is closed. PLEASE DO NOT KEEP REOPENING THIS REPORT!!!! If you have specific problems with the way it was implemented, or would like to see more implemented, then file bug reports or requests for enhancements. Already several such reports were filed on the implementation, namely bug 109586 -- request for throbber/progress-meter in full-screen mode (request for enhancement), and bug 109585 -- exit fullscreen button does not appear in modern skin (bug).

My last comments stand. This bug is not fixed from a QA point of view. Please do not mark this bug as FIXED until the bug is actually fixed. If you have no intention of fixing it then reassign it to someone else, e.g. nobody@mozilla.org. The spec does not fulfill the requests of this bug and is therefore not at all relevant as far as resolving this bug is concerned. (From a UI perspective I believe that the spec you mention has serious issues, for instance it is unclear why a user would ever want to use it. However that is not relevant here either.)

http://bugzilla.mozilla.org/show_bug.cgi?id=68136 bug summary: Mozilla should have a Full-screen mode hixie: "The window did not take the full screen." morse: "Correct again. Again by design." Am I missing something here? Morse, to claim, as you do by closing this bug, that Mozilla now has a full screen mode, is not just unconvincing, it's patently false. To summarise the page that you named as the definitive "spec" (so called): " Full Screen Mode Two different strategies: 1) Instant hide of UI & presentation of slimline UI <snip> 2) Complete Full Screen mode <snip> This is the better looking approach, but as described it's hard " While the slimline UI works reasonably well, it isn't related to the bug summary in any way. Not only is this feature is extremely important it has 51 votes (and 46 CCs). All of these votes are clearly for a true full screen mode, not a "slimline UI". If you were to file a separate bug called "implement a slimline UI", make it a blocker for this bug, and close it, that would be reasonable. But there is no way that one hundred interested parties will buy the line that "Mozilla has a full screen mode". It doesn't.

People, let us be civil and stop flaming morse, please. I completely agree that a true full screen mode (like IE, kmeleon, galeon) would be something cool to have, however it is far too late to start complaining now. If you had read through the bug, had a look at the spec or tried out the patches before you should have noticed what was going on. In order to reach some sort of compromise I have opened bug 109603 ([RFE] implement a true full screeen mode) and updated the summary in this bug to better reflect what was going on: Mozilla should have a Full-screen mode ---> implement a Full-screen mode (hide toolbars only) To avoid getting the same type of negative feedback from endusers we should maybe rename the view menu entry from "Full Screen" to "Full Window", since the current implementation is not what people have come to expect from the term full screen. I can come up with a patch for that. What was implemented is a necessary prerequisite for a more complete full screen mode and not useless at all. By setting the window maximised and removing window decoration I can achieve full screen mode on Linux now. So move over your votes and comments to bug 109603 and let this bug rest in peace. Thanks.

> People, let us be civil and stop flaming morse, please. Nobody is "flaming" morse -- I can't speak for luke, but personally I'm just doing my job as QA: Trying to verify this bug, and failing. > I completely agree that a true full screen mode (like IE, kmeleon, > galeon) would be something cool to have, however it is far too late to > start complaining now. If you had read through the bug, had a look at > the spec or tried out the patches before you should have noticed what > was going on. I read. I commented. My comments were ignored. See: http://bugzilla.mozilla.org/show_bug.cgi?id=68136#c3 http://bugzilla.mozilla.org/show_bug.cgi?id=68136#c140 > In order to reach some sort of compromise I have opened bug 109603 > ([RFE] implement a true full screeen mode) That bug is a duplicate of this one. > ... and updated the summary in this bug to better reflect what was > going on: Retroactively changing bug summaries is a dangerous practice. Morphing bugs is considered bad practice because it makes searching for bugs harder, breaks links to bugs, changes the meaning of votes, ccs, and comments, causes valid bugs to be lost in the muddle, and skews statistics for bug reporters, confirmers, fixers, and bug verifiers. (These statistics have an indirect impact on contributors' bugzilla and CVS privilieges as well as, in some cases, their pay.) > What was implemented is a necessary prerequisite for a more complete > full screen mode and not useless at all. In that case this bug should not have been closed, as luke pointed out. > So move over your votes and comments to bug 109603 and let this bug > rest in peace. Thanks. Many of the votees on this bug will not be reading bugmail, assuming (and rightly so) that their vote will not get cancelled in this way. REOPENING. I am marking bug 109693 as a duplicate of this bug. Please do not knowingly file duplicates in this way. Thanks.

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

I have to agree with Ian. The reason I voted for this bug was because I believed (naively, perhaps) that Mozilla would gain a _real_ full-screen mode upon the resolution of this bug. Lighter chrome != Full-screen. In some cases, having the slimline option is useful, but it will never be as useful as a real full-screen mode. Why bother going halfway and stopping? As Hyatt said, "IMO this is one of those features that, if we don't do it right, just shouldn't be done at all." Unfortunately, I must agree with that, too.

I'm sorry, but I have to agree with hyatt. I understand that morse put a lot of work into this, but it's just not useful in any way. I cannot see the current implementation making the browsing experience any better or easier. I can, however, see it making the experience more difficult and frustrating. We should back this out and take a fresh approach to it.

I just downloaded the nightly as well, and although I think it's a great start, I don't see how this feature (as it stands) would be useful. If you go to fullscreen mode, you lose the location field and the throbber... So if you want to browse the web, you've got to hit F11 again to enter a location. I'm also looking back to the first comment >> Mozilla should have a Full-screen mode, accessible from the `View' menu. In such a mode, by default the only chrome would be: * the menu bar at the top of the screen * the status bar at the bottom of the screen * Back, Forward, Stop, and Update buttons at the left end of the status bar. In full-screen mode, toolbars could be turned on and off just as in normal mode; their state in full-screen mode should be remembered separately from their state in normal mode. << And wondering if what was proposed has been implemented. I think the ability to do a "full window" is neat (providing I can have my location bar back) but it looks like a "full-screen" option has not yet been implemented.

This needs a UI spec before any other work is done on it.

Matching summary to UI spec, which is FIXED. Problems or enhancements to the current spec should be seperate bugs. The current patch is useful and gives UNIX a fullscreen mode (set up a keybind in your window manager to maximize the window and remove boarders). To repeat AGAIN for Nick, no, you don't have to exit the mode for location bar, use ctrl-shift-L. A full-screen mode like IE's isn't going to make 1.0 unless it's given special priority, which it shouldn't get. There's alot more important work to be done. Implementing an IE-like fullscreen mode on Mac9, Mac10, Windows, and UNIX would take enormous ammounts of time. If you don't like the current implementation, don't use it. But please quit whining. If we really believe it isn't better then nothing for most users, add a hidden pref and have it off by default. As I said though, it's useful in UNIX... F11 then Meta+X gives me a true (well, pretty much) full screen browser TODAY. Ian: patches accepted to do all the stuff you want.

If you change the summary of this bug again, your bugzilla permissions will be turned off. This bug is for Full Screen Mode. It has not been fixed properly, if at all. The patch as it exists today has nothing to do with fullscreen mode, and only changes the toolbar configuration. Please don't morph this bug into something it's not.

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

> Retroactively changing bug summaries is a dangerous practice. Morphing > bugs is considered bad practice because it makes searching for bugs > harder, breaks links to bugs, changes the meaning of votes, ccs, and > comments, causes valid bugs to be lost in the muddle, and skews > statistics for bug reporters, confirmers, fixers, and bug verifiers. > (These statistics have an indirect impact on contributors' bugzilla and > CVS privilieges as well as, in some cases, their pay.) Point taken. I was not aware of this. My apologies. > REOPENING. I am marking bug 109693 as a duplicate of this bug. Please do > not knowingly file duplicates in this way. Thanks. I just VERIFIED that bug into nonexistence. I was just trying to make all interested parties happy. As I should have known, such an undertaking is bound to fail. BTW, Ian has filed bug 109593 (Back out "full screen" mode) in order to get rid of this feature. I do not agree, but either way you might be interested in having a look at it.

I've filed and marked fixed bug 109665, which is about implementing option one of the spec as provided by trudelle and implemented by morse. Go comment in there about the appropriateness of the spec, the implementation and the patch having been checked in. Leave this bug for comments about implementing the real full-screen mode. Resetting milestone and owner for re-evaluation.

Well, after some discussion on IRC, I've changed my stance on this. I think that we should back at least part of this out for two reasons: 1) my proposed solution to the chrome-hiding issue should be hashed out more 2) the Full Screen menu item is decieving.. we should not check in the menu item until we have more of this feature landed, at least as minimal as maximizing the window. That said, I don't think lack of toolkit support should prevent the some amount of chrome-hiding code from landing, because 1) the chrome-hiding has to land sometime 2) I think that a hidden-chrome, maximized-window state is at least useful to people looking to go into a maximum-viewable-area mode. So my proprosed solutions: (take your pick, I support them all) 1) back this whole thing out 2) check in a thing that maximizes the window when going into fullscreen mode and in either case, we hash out the CSS solution that I proposed.

patch to widget/ to support hiding of window chrome (windows only)

patch to content/ to support the 'hidechrome' attribute which hides window chrome when set.

new service which provides a means for showing/hiding OS chrome items.

build stuff for component in part 3

turn on full screen in the browser & convert button hiding code to css rather than js

The attached patches (1,2,3,4,5) implement full chrome hiding (including taskbar, etc) for Windows only. The interface for OS chrome hiding included can be implemented on other platforms however and is non-platform specific. Platforms must also implement HideWindowChrome(PRBool aShouldHide) on their respective |nsWindow|s.

Comment on attachment 57713 [details] [diff] [review] full screen patch part 1 >+ while (parentWnd) { >+ hwnd = parentWnd; >+ parentWnd = ::GetParent(parentWnd); >+ if (!parentWnd) break; This break is unnecessary. >+ if (aShouldHide) { >+ DWORD tempStyle = ::GetWindowLong(hwnd, GWL_STYLE); >+ DWORD tempExStyle = ::GetWindowLong(hwnd, GWL_EXSTYLE); >+ } >+ else { >+ if (!mOldStyle || !mOldExStyle) { >+ DWORD tempStyle = ::GetWindowLong(hwnd, GWL_STYLE); >+ DWORD tempExStyle = ::GetWindowLong(hwnd, GWL_EXSTYLE); >+ } This will cause a warning, won't it? Move the tempStyle and tempExStyle decl. out?

Comment on attachment 57715 [details] [diff] [review] full screen patch part 3 >+ <content persist="width height screenX screenY fullScreen"/> Don't forget to remove fullScreen persistence.

ooh, nice catch. the latter case should be mOldStyle and mOldExStyle not tempStyle and tempExStyle.

all of blake's comments have been addressed, this segment updated with: if (!mOldStyle || !mOldExStyle) { mOldStyle = ::GetWindowLong(hwnd, GWL_STYLE); mOldExStyle = ::GetWindowLong(hwnd, GWL_EXSTYLE); }

Comment on attachment 57717 [details] [diff] [review] full screen patch part 5 >+fullscreen { >+ -moz-binding: url("chrome://communicator/content/fullScreenBindings.xml#fullscreen"); >+ visibility: collapse; >+} The binding hookup should be in xul.css, and just add fullscreen to the list of display:none element there. Too bad this can't just be hooked up to window... >+ <fullscreen id="navigatorFullScreen"/> Is this id needed?

right, that should be mOldStyle / mOldExStyle. I even have that in my version. reassigning to ben.

blake: can't be display: none or else the binding won't be usable ;) Yes, the id is required as navigator's BrowserFullScreenToggle function gets this element and toggles the isInFullScreenMode property. I agree in principle that the css hookup should be moved out of navigator, but am not sure that xul.css is the best place for this. Is this an element we want to add to XUL itself, or is this just in our application domain (hence requiring a new content stylesheet, communicator.css)

The document referred to as a spec, http://www.mozilla.org/xpapps/MachVPlan/Full_Screen_Mode.html, is not a spec, merely a very rough engineering plan. This feature needs an approved UI Specification before any further time is wasted on it. cc marlon for UE input.

This bug has a spec. I quote from the bug description: Mozilla should have a Full-screen mode, accessible from the `View' menu. In such a mode, by default the only chrome would be: * the menu bar at the top of the screen * the status bar at the bottom of the screen * Back, Forward, Stop, and Update buttons at the left end of the status bar. In full-screen mode, toolbars could be turned on and off just as in normal mode; their state in full-screen mode should be remembered separately from their state in normal mode. We should add escape to leave full-screen as per the discussion in this bug. If you disagree with this spec, now would be a good time to explain as such.

I think Peter means an agreed upon document, preferably residing with other specs on mozilla.org I'm not trying to solve everyone's full screen problems with my patches, merely demonstrate how one could hide window chrome on windows. When a final UI spec is developed, I'm confident someone could use the code I've presented to implement such a specificiation.

Yes. It need not be anything formal, just sufficient to show what the feature should look like, what it will do (and not do), how the user interacts with it, etc. Ideally, nothing would be left to chance. Settling all of this after checkin, via endless bug reports, is quite tedious and wastes development effort. Much better to specify the results up-front, get agreement, and then only write the code once.

I just built Ben's implementation and I think it's an excellent starting point. Besides the minor bugs and lack of auto-hiding toolbars, it brings us very close to what IE has. Under Windows, at least.

Glad to hear it. Perhaps someone can take the next step by posting screenshots, translating to Mac/Linux, and describing the interaction on each platform? We'll need that to be able to test it properly as well.

Shouldn't the next step be doing something the current "full screen" mode?

Some things to consider, when producing a spec: - what happens when the window deactivates? (user clicks in another window on a multimonitor system, alt-tabs or hits something like the windows key) most likely answer: show the OS chrome (this is what IE does) The nsIOSChromeItem interface provides means for locating and measuring pieces of OS chrome, such as the windows taskbar, which should make it possible for a hot zone to be set up along the screen axis nearest the region defined by those coordinates, and code set up to show the chrome when the mouse enters that region. Problems with current patch - Maximize window, hit F11 to enter full screen mode. Hit F11 again to exit full screen mode. Note that the window does not return to its maximized state. This is waiting for Fabian's fix to enable .maximize() calls on DOM windows. When that is supported, the exit-fullscreen code can check to see if the <window>'s sizemode attribute is set to 'maximized', and if so, call |maximize| to maximize the window again. - Enter full screen, open a new window (Ctrl+N). Note the new window is not of the coordinates of the original window that went full screen. This is because resizeTo/moveTo appear to update the width/height/screenX/screenY attributes. A solution would be to use the real copies of these attributes stored on the full screen element in the new browser window creation routine. - OS Chrome does not return when the window is deactivated (see above)

bbaetz points out bug 110120, which cites F11 key clashes with WindowMaker, a relatively common window manager on Linux. This presents the another issue for the UI spec - which key binding is used to toggle this mode on various platforms. On Windows, F11 is the obvious choice. On Mac and Linux, not so obvious. Mac users I've spoken to usually loathe us using F-keys for application functionality, so I'd guess F11 isn't the best choice there either.

Konqueror uses Ctrl+Shift+F I like F11 myself, and it's nice to be consistent. The ability to do custom key bindings would be neat for conflicts like this... But I suppose that's not within the scope of this bug. :)

640x480 screenshot of patches 1-5

Nick: we can do custom key bindings, see http://www.mozilla.org/unix/customizing.html. But it has to be registered as a command accessible from XBL; I don't know whether this functionality is or not. If it is a command, that would be a workaround for the folks hitting bug 110120. Maybe someone familiar with the implementation can comment there.

spoke to kerz on this, i think what ben has on hand can work for the mean time. We need to consider the issues with Modern, but for the interim the use of dialog buttons and a regular textfield on a flat toolbar could work. The user scenarios and requirements will also have to be considered more thoroughly. be sure to include the throbber (16px version if necessary) for feedback.

"We need to consider the issues with Modern" The issues that Ben mentioned with the taskbar not re-appearing, etc., or other issues? "but for the interim the use of dialog buttons and a regular textfield on a flat toolbar could work" Huh? Dialog buttons? What's wrong with keeping the toolbar for the selected theme?

I'm also confused by the comment - maybe I'm misunderstanding - but I also don't understand why we wouldn't just make use of the existing toolbar. I agree screen real estate is an issue, but... - Autohiding would help that. (Should that be a separate bug?) - What about bug 86455 (small toolbar icons). Could we make use of whatever comes out of that? i.e. When in full screen mode, switch to small icons (or at least remember their size separately in full screen). - ditto for bug 22056 (text/icons/both option)

Screen real estate is *the* issue here, this feature exists only to make maximal use of it.

re: problems with the Windows taskbar not showing up again, we could always do what IE does. IE doesn't hide the taskbar. If the taskbar is not set to auto-hide, IE switches it to auto-hide when going into full-screen and then back to always-shown when returning out.

Comment #109 Can we catch [the restore] event? um, it doesn't look like we can yet, it was discussed ages ago, if i can't find a bug for it, i'll file one. Comment #110 Catching the restore event would be a windows-only solution and not cross platform. no, it would apply to most platforms [Comment #113] Comment #111 it would be odd behavior to allow the user to restore the window and still have all the chrome hidden, and still have View > Full Screen checked... It would be wrong. if you fullscreen ie on windows and then right click on its window in the taskbar and select restore, it leaves fullscreen mode in addition to the normal restore behavior. Comment #112 That's awful. Not only is it windows only, it goes completly against what that button is supposed to do. It doesn't send signals to applications, it's a window manager function. Restore is something that window managers should send to applications, even if they just tell them their size changed. If you stretch my window w/o telling me not to paint somewhere and expect me to do the right thing, you're broken. Comment #113 hyatt killed the [x] from tabbed browsing. time marches on, it appears the [x] got reincarnated.

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

Potentially helpful Mac-specific comment from bug 111214: The best results would entail using an API like Draw Sprocket or CGDirectDisplay which would not only remove the menu bar and Dock, but would also speed things up by removing the double buffer. (anarkhos@mac.com)

Hmmm, thinking about Ben's implementation a little more, I'm not sure this is exactly the right way to go about things on Windows. If we hide the taskbar we run into two problems. First, if (heaven forbid!) Moz crashes, the Taskbar will be hidden and the user left hanging. Secondly, I think the taskbar should display no matter what if the user presses the Windows key, and I'm not sure if that will happen if What about just making the window a top-most window? From talking to people, this works well. The other thing you have to do is intercept WM_MINMAXINFO because apparently Windows doesn't let you make a window taller than about 20 less than the screen height. This seems safer to me than hiding the taskbar.

here's a rough sketch for the FS feature, comments, additions are welcome: INTRODUCTION There are 3 distinct uses for Fullscreen mode. 1) for offering a way to create a terminal "dedicated" to a particular site, i.e. kiosk mode. - advanced user/sys admin 2) to allow everyday users to make the most use of screen real estate when browsing. - advanced users/intermediate users with occasional needs. 3) to facilitate slide shows on projectors or demos on laptops. - advanced/intermediate/novice General concerns: - the feature is potentially very dangerous because it takes users out of their element, and often times have to stumble to get back. - The Mozilla FS window should follow behavior of an ordinary window in many respects, or like a window that is "super maximized". Exception: FS spawn should not cross components. for example, you should never spawn a FS mail application window by default from a FS browser window (for example pressing ctrl+m, or ctrl+2) ACCESSING FULLSCREEN MODE The behavior for Fullscreen mode can resemble that found in current MSWindows2K/XP/IE scenarios with a few exceptions: 1. Entering FS Window mode. MSWindows: assume only advanced users will see its use. - F11 to toggle - View Menu item Comment: This is very advanced-user oriented, and neglects the feature for category 2 and 3 users. Mozilla: We shall assume users want the flexibility to enter and exit FS mode on a regular basis, so the controls for entering and exiting should be visible: - a menu item under "View" called "Full Screen / Window Mode" - a shortcut "F11" for all platforms - an additional exit shortcut [ESC] for all platforms. - context menu item (when clicking on the window titlebar) - Kiosk mode should be entered through a distinct pref labelled as such, and not associated with Fullscreen mode. - [FUTURE] a toolbar widget to cycle through toolbar sizes (part of customization spec). - [FUTURE] a customizable toolbar button for placement on either the main or custom toolbar (part of customization spec) However we shall assume that Kiosk mode should not be as accessible, and only be initiated by full intention of the sys admin. - a preference Panel - complex key command 2. Maintaining FS window mode - and Mixed window states (n/a to Kiosk mode) MSWindows: the FS state for default windows shall be established when a user exits the program in the FS state. (assume that the user wants to always be in FS because they happened to leave the application in that state). Mixed window states are possible, but behavior is inconsistent and unpredictable. Comment: This is bad for two types of users - users who want FS all the time, and users who don't. In order to get out of FS defaultness, you have to be clever (or lucky) enough to exit the app in an irregular or maximized window, then relaunch the app to get normal window behavior again. Mozilla: be in FS state until the user actively decides to change the state for any active window. Which means when spawning new windows we should continue to adhere to the state of parent windows, whether they're "windowless" (ie FS mode), irregular or maximized. We should preserve the window state of an older, inactive, or minimized FS window, even when a user has exited FS mode in the active window. This is why FS mode will be more or less like a "super maximized" window. 3. Escaping FS window mode MSWindows: To exit FS mode, rely on users to find the "windowing" button in the black quagmire of title bar controls to the far right of the toolbar; or close the current window and launch a new window (when not under "granddaddy" clause). Or simply hit F11. Comment: This is clumsy and not intuitive. It requires users to first discover those controls (which are not the same controls in normal windows title bar) to escape the mode. Most users hit the "x" close button, open a new window, and reload the URL (3 extra steps to get to where you were before). F11 is only reliable for the <10%, advanced user. Mozilla: - offer more distinct and familiar button-like controls on the right side, which draw more attention for the occasionally trapped / curious user. - F11 should work across platforms (except for mac users which have the function key control panel loaded - not sure about this). - In addition [ESC] button will work particularly well for both mac and windows users (if there's conflict with [esc] somewhere please let me know). - For kiosk/dedicated terminal users a special passwd lockout feature will need to be implemented. A key combination followed by a passwd dialog sequence will get the user out of the mode. USING FS MODE: 1. The toolbar. Upon entering FS, all chrome is reduced to a single small, and "degraded" toolbar - this means enough features to "cover the bases". the toolbar buttons will scale by about 70%, the url bar groove is absent. Consequently, this is the same toolbar to be used for the "small buttons with no text" mode in Toolbar Customization (future), however it's appearance and behavior here is exclusive to the FS mode. The slim-line toolbar should be similar to that shown in the attachment. (the new theme images for this are ready). The slimline-toolbar should have an auto-hide mode which hides the toolbar when cursor moves away, and returns when mouse stays at the top most border of the screen (with a 0.5s delay to eliminate accidental bumping and over activating) This can be toggled through a FS slimline toolbar contextual menu. 2. The Win Task Bar / Mac Menu bar. - On windows, the start bar should be in "pop-up" mode as is customary with FS mode on that platform - On Mac 9.x users are rarely exposed to any kind of fullscreen functionality, however there is some precedence with Adobe products using both fullscreen and menubar-fullscreen, Mac DVD Player, QT player, and maybe a couple others. I think offering a menubar-fullscreen by default would be the ideal compromise between a maximized screenspace while maintaining a "Mac-like" UE. However if it is possible to hover over the menu bar for .5sec to get a similar hide/show effect which coordinates with the auto-hide feature, then that would be really slick. [ESC] is by all means necessary for Mac users to exit a FS window. A menuless FS mode by default on the Mac would not allow users in category 2 (from above) to navigate between different windows, so we should not take this route on the mac - unless it were an extra option to activate. An extra option in the way of contextual menu clicking on the slimline-toolbar or through a pref. - On OSX we should hide the dock if it's not already hidden, otherwise the rest of Mac 9.x applies here. 3. Contextual Menu - a Windows user should be able to toggle normal and FS window mode for that window by context clicking on the on the window title bar (not toolbar). - all users should be able to context click on the FS slimline toolbar to select window mode and get back.

a few more images will be finalized later (toolbar background, and right side window control/gray area)

"(if there's conflict with [esc] somewhere please let me know)" Oh no, not this again. See the majority of the comments from #69 to about #134, where Esc was finally removed as a way to exit full-screen mode.

Well since this is marked for ALL platforms, I just want to note something about Mac OS/OS X. Mac OS X has a full screen mode (accessible by either Draw Sprockets or CGDirectDisplay.h) which AFAICT doesn't have any issues if the full screen app crashes. The menu bar and Dock should reappear. Thus the task bar issue is moot in Mac OS X. However MacOS has the same kind of issue with the Control Strip which will remain hidden if the app crashes instead of exiting full screen mode cleanly (and even when that does happen, all mac users know how to make it re-appear). OS X has a futher advantage when using full screen mode in that it doesn't have to double buffer thus it's faster. A little tinkering may have to be necessary to make it behave correctly, however I'm totally against just maximizing the front-most window. If you have to do that in Microsoft Windows to prevent the task bar from being hidden in the event of a crash I hope that doesn't determine the functionality of full screen mode in other platforms.

1) Autohiding - definitely. Essential. People need to be able to find some controls some of the time, naturally. But forcing controls to stay on the screen defeats the whole point of FS. 2) The slimline toolbar looks great (attachment 59290 [details]). Will that be achieved by styling the existing one? i.e. lots of [fullScreen="true"] in themes. I hope so. Comment 199 still sounds like it's suggesting that a new toolbar is created, rather than styling the existing one. 3) The OS title bar shouldn't show when in full screen. I'm assuming that the comment about using the Windows title bar to toggle (section 3) must mean getting into FS - not out. 4) ESC - driving me bonkers. If ESC is going to exit fullscreen, it should be a pref and off by default, or left to keybindings. Do any of the people suggesting this use fullscreen in any other browsers? For any other program I would agree, ESC to exit fullscreen. But in a browser, ESC is a basic keybinding - stop pages loading. By making it do 2 things, both keybindings become unusable. a) If we have autohiding buttons/menus, people have an exit that's easy to find, so concern about them getting lost is less of an issue. b) And people use fullscreen on purpose. I think the concerns about hapless users getting lost are a bit misplaced. I've never been lost in IE fullscreen, and ESC doesn't get me out (thank goodness). And, most of the time, I argue that Moz's UI is not user-friendly enough - too dependent on knowing key bindings / startup commands / hiddend prefs. In this case, I just don't think F11 is too complicated.

> here's a rough sketch for the FS feature, comments, additions are welcome: It appears this rough scetch was made w/o a consideration of all the comments in this bug. I know the bug is long, but you just made it considerably longer by inlining your sketch which ignored all the comments. That's rude. If you're going to provide a long proposal which ignores everything in the bug, please make it an attachment. > a shortcut "F11" for all platforms @~NO!@! Absolutely not. Keyboard shortcuts should follow platform conventions. This means that when we get around to it the keys for macos should stop being evil. > In addition [ESC] button will work particularly well for both mac and windows users (if there's conflict with [esc] somewhere please let me know). It will not, please see the large arguement about this point, Comment 69, Comment 72, Comment 88, Comment 126, Comment 127, Comment 129, Comment 130, Comment 131, Comment 134. my compromise proposal (which no one liked) was Comment 87. fwiw there are actually a bunch of windows applications that do use escape to exit full screen mode, i can give a behavior list based on the apps i described in bug 111235 comment 17. Comment 96 kiosk mode is bug 3341 and you should update that bug w/ any relevant comments. > Kiosk mode should be entered through a distinct pref labelled as such, and not associated with Fullscreen mode. It'd be easy enough to make Kiosk mode a package and have it in the tasks menu (ala Netcaster), or we could stick it into View>Apply Theme> in a separate section as a checked item. Behavior A: (all themes magically support Kiosk mode) checking the menu enters/exits the mode. Behavior B: (themes require work to support Kiosk mode) if the current theme supports Kiosk mode, activate it, if not, provide a dialog listing themes that support Kiosk mode. > MSWindows What is MSWindows? I don't remember this from Windows3.1. If you mean MSIE (version X) please say so. Putting Kiosk mode in as a separate package and then having an item in profile manager offering a list of applications to start would solve this problem nicely, no interface to enter or exit it while browsing. > On windows, the start bar should be in "pop-up" mode as is customary with FS mode on that platform No. As dean says if you manage to crash you can leave the user totally confused. Correct behavior is to mark our app always on top and perhaps something else. w/ w2k ie5.5 fullscreening IE w/ taskbar set to always on top and not autohide: 1. ie fullscreens. 2. taskbar properties still say always on top and not autohide. 3. switching to a non fullscreened application the taskbar becomes visible again. 4. pressing the win key or ctrl-escape of course will *naturally* bring the start menu up. > On OSX we should hide the dock if it's not already hidden, otherwise the rest of Mac 9.x applies here. Oh goody, so when mozilla crashes the users can file a report saying we killed their dock. Please find a solution that doesn't involve permanent state changes of other applications. End first draft of complaints about marlon's post. Attachment 59290 [details]. I think i want the throbber outside of the toolbar area. this would match ie5.5win's general placement. Comments against Comment 213. > But forcing controls to stay on the screen defeats the whole point of FS. It does not. As long as it's a user option and we pick the logical default this isn't an issue. [I think the logical default is autohide, so advanced users can manually force the controls to stay put]. > The OS title bar shouldn't show when in full screen. The os title bar is shown inside the taskbar if you force the taskbar to display. > I'm assuming that the comment about using the Windows title bar to toggle (section 3) must mean getting into FS - not out. Actually it's more important that the menu allow getting out than in. Note that most applications do not modify the system menubar except in special cases and the non ms apps (wpsuite) that have done so have suffered penalties when ms released a newer os.

Generally, I like the rough sketch. However... As Dean said, Esc is already used for Stop and can't also be used to exit full screen mode. > - a Windows user should be able to toggle normal and FS window mode for that > window by context clicking on the on the window title bar (not toolbar). Am I right in thinking this means adding a 'Full Screen' item to the title bar's context menu (which currently has 'Restore', 'Move', 'Size', 'Minimize', 'Maximize' and 'Close')? That sounds like quite a good idea as its essentially another state the window can be in (along with the oh-so-intuitively named maximized, minimized and, er, restored modes). I like the attached toolbar image but the horizontal spacing between the different bits of it looks a bit too large. And why has the 'Print' button lost its drop-down (I know it's got nothing in it now but I believe the plan is to add 'Print Preview' and 'Page Setup' etc.)? The buttons are nice too but I think 'restore' is a better name than 'windowfy'. Also, if you look at a normal Windows 'Restore' button, you'll notice that the bottom-left window is on top of the top-right one; in the attached images it's the wrong way round. Would it be a good idea to add an 'Exit Full Screen' button next to the window contol buttons on the right of the full screen toolbar? After, all it's another window state, really. It would also prevent the nasty IE 'Restore' button problem.

I've attached a patch to bug 109593 to use CSS instead of JS to toggle full-screen mode, and happened to notice the queries about hiding the windows taskbar. My understanding is that all IE does is make its window very big and the taskbar will automatically hide. If you have some old Windows software that resizes itself to fit the screen instead of the desktop you will observe the same effect.

If we want to create an "Always on top" Window for full screen mode, I think the code to do that is already implemented in Mozilla. There is no need to program this feature on every platform again. The menuPopUp code creates an "Always on top" Window to display itself. See http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsMenuPopupFrame.cpp#206 > // XXX Hack. The menu's view should float above all other views, > // so we use the nsIView::SetFloating() to tell the view manager > // about that constraint. > ourView->SetFloating(PR_TRUE); I believe that all FullScreen applications on Windows and Linux works by creating and "Always on top Window" with no window manager decoration or border and setting the size to the size of the screen. Sorry if I'm saying something already known.

Neil: IE also changes the taskbar to auto-hide if it's set to always visible. Daniel: I don't think you want a topmost window. You want a window on top of all others, but you want to be able to switch to other windows. So, in Windows terms, HWND_TOP not HWND_TOPMOST.