2002022003 win98. Go into fullscreen mode with the sidebar visible. Expected result: fullscreen with no sidebar Actual result: fullscreen with sidebar.
This is probably not something we want to do. It could be quite useful to have the sidebar while in full screen mode, and if you don't want it, it's only one click to kill it. marlon, what's your call on this?
joe i think what we discussed was to have FS to remember its state separately. when you enter FS for the first time by default you should have no sidebar. otherwise we're not giving people what they asked for in the firstplace - fullscreen mode. however, once you hit f9 or context click to open sidebar it should persist across subsequent FS sessions until it's closed.
This is a tough call. I think there may be users who would like the sidebar to persist, or at a minimum be available through a mechanism more discoverable than the keyboard command or context menu. Any ideas on how we could do that Marlon - maybe use the design we have for sidebar close/open that you've spec'ed but have it overlay the fs mode toolbar instead of the personal toolbar? Personally I use fs mode a lot and often find having the sidebar available very useful. I know how to toggle it, but I expect most users do not.
i think that's definitely a nice-to-have. the primary senario is for full screen presentation. the full-time use aspect is meant for more advanced users, who are apt to discovering it wherever we put it. i am saying at some point we could have a sidebar icon on the fs toolbar, but even if we can't do it now, we still will have met our primary goal for the feature in machv.
What about prefs - something like Appearance: [x] Hide Sidebar in Full Screen (And UI engineers should just discuss what should be the default...)
Full screen is full screen. Full screen is not full screen with a side bar. Pretty annoying.
In IE, when sidebar is open, and then fullscreen is switched to (very easily by a button that can be added in the "customize" section (right click to find it)) moving mouse to the left border of the screen (entire left border is the "hotspot") opens the sidebar. Moving the mouse off the sidebar lets the sidebar "slide" closed. It's an an incredibly useful way of doing it and why I have been addicted to IE since 5.5 or so when the feature first appeared. MS may have faults, but UI design is not one of them.
*** Bug 183333 has been marked as a duplicate of this bug. ***
"MS may have faults, but UI design is not one of them." ¿Que? Sorry, couldn't resist :-) I would insert a reference to the Interface Hall of Shame, but that website seems to have disapeared ... And to make this pot a bit on-topic, I was actually surprised when IE removed my sidebar when I toggled it to full-screen the first time. I would prefer to keep my layout the way it was (with or without sidebar) when going to full-screen and back, and I would like to decide myself if I would like to toggle the sidebar status. That wouldn't require an extra preference in the (severly bloated) preference dialog. Actually, my personal preference (sic) would be the opposite from what IE is doing : because of the larger screen-space, I would show the sidebar in full-screen mode and not in regular mode. And automatic opening when you approach the left-side of the screen ... shudder. This would be totally unusable for my grandmother, who has very poor hand coordination, and has to use a kind of joystick instead of a mouse. She would hit the left-screen (and the sidebar) much too easily.
I believe we should have 2 different settings: 1) sidebar size/position for regular mode 2) sidebar size/position for fullscreen (by default, same as 1) I think that a user should be able to decide whether they have 2 different settings or the same one. I believe that when you go fullscreen, the sidebar should stay the same, and when you go into regular mode, it should stay the same. The only exception is when you explicitly choose two different settings. The only difference with this and comment #3 is that I don't think the fullscreen setting should persist seperately unless you tell it you want independant settings through some preference. This is more functional than comment #6 because it allows more than just remembering to hide the sidebar in fullscreen. Prefs: [ ] Use independent settings for saved sidebar positions and sizes in full-screen and regular browsing mode (just an example) --- As we should only have 1 issue per bug, there are two many issues being discussed in this bug. The three issues being discussed are: 1. comment #8 - Auto-hide ability (like windows taskbar's Auto-hide) - which is what I was more interested about in bug 183333 so I'm unduping it. 2. Preserving independant settings (and possibly only if chosen in prefs) for the sidebar in full-screen mode and regular. 3. Hiding the sidebar for fullscreen (won't be what every user wants) Please let me know if you don't agree, but I'm changing the summary to reflect choice 2 since choice 3 is not as flexible. I'm also unduping my bug since I'm more interested in the ability to make the sidebar appear if you hover over the left side of the screen (comment #8) and three issues is too much for one bug.
What about "easier" (less complex) and more user-friendly solution without polluting prefs? If user is switching from normal mode to fullscreen mode for the first time, Mozilla should preserve sidebar appereance. If user is switching to fullscreen mode for the second time, restore sidebar layout as it was last time when user turned off fullscreen (switched to normal mode or closed the window). In other words, Mozilla should remember what was the last user preference when he was using fullscreen. If she turned off sidebar, she probably doesn't like sidebar in fullscreen and vice versa.
Good idea... Though where are you going to save this? It still seems as though it will be a pref (though not hooked up to UI)
Mozilla is already saving somewhere things like sidebar status and position between restarts so it could be there - just to remember the sidebar status/position in fullscreen mode too.
*** Bug 196410 has been marked as a duplicate of this bug. ***