Closed Bug 669104 Opened 14 years ago Closed 14 years ago

provide an easy way to exit fullscreen mode

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Version:
5 Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 474070

People

(Reporter: kwesson4, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30 Steps to reproduce: Not sure. Was switching between browser and other applications. Actual results: Browser controls disappeared: tabs, menus, title bar, everything. The browser consisted then of nothing but a rendered web page, with no controls other than the links on that particular web page. Restarting the browser did NOT fix this, so apparently I will need to reinstall. Expected results: Obviously, this should not happen spontaneously, and if the browser has any sort of "full-screen" mode, the standard toggle-full-screen-mode binding alt-enter should undo it and there should be a right-click menu option that undoes it, nor should it persist across restarts. As it is, whether this is a pure bug or a feature, plus bugs that can toggle it on randomly and that make it impossible to toggle it back off again if you don't know exactly how, it's rendered the browser virtually unusable since there's no obvious way to put it back to normal short of deleting and reinstalling Firefox.
Severity: normal → critical
Classing this as "critical" since unless you have memorized some magic key combination to undo it (and assuming that there even is one), there's no recovery short of a clean reinstall that will lose all saved passwords, tabs, form autocomplete data, &c -- so, this bug causes massive inconvenience, downtime, and data lass.
I've found a rather convoluted recovery method, but it's sufficiently nonobvious that a lot of users that run into this are very likely to resort to a reinstall before they discover it. 1. Restart Firefox and move the mouse to the very top of the screen. The tabs and address bar may come back or they may not; restart and repeat until it does. Once it's in this state, the controls will go away again if the mouse is moved down out of the top control area, but they will reliably come back if you move the mouse to the very top of the screen again. So now you kind of have your tabs and address bar back. The tab bar is missing the orange menu button at left that you'd use to try to get into preferences, etc., though, so this is not a complete recovery. 2. Right click the EMPTY SPACE NEAR the address bar and above the web page currently displayed. So, (with the default color scheme) in the pale blue stuff near the back, forward, and history buttons and address bar. 3. The menu will have an "Exit Fullscreen Mode" option; select this and FF returns to normal. This is still critical, since the above procedure is by no means obvious and the one truly obvious way to try to fix it is to reinstall it, which will lose data. Fixing it, however, should be extremely easy given its nature as a broken feature rather than a crash of parts of Firefox combined with file corruption: 1. Fix whatever it is that allows this state to be entered into spontaneously, without explicit user request. 2. Make alt-enter undo it, or even toggle it, as per most other applications with a full-screen mode. (Ctrl-enter instead on Macintosh keyboards, I suppose.) 3. Make double-clicking a blank part of the displayed page also undo it, as this is another very common way of going into/out of full-screen in e.g. media player apps. 4. Make "Exit full-screen mode" part of the right click menu that comes up if you right click a blank area of the displayed page, when in full-screen mode. The most obvious things people will try before a reinstall, namely right click menu browsing, double-clicking, and alt-enter, will then all work to put the browser back to normal if it somehow gets into full-screen mode unexpectedly, which should happen much less often to begin with if whatever caused the spontaneous state change gets addressed.
Oh, and 5. Don't have this state persist across restarts! A fresh Firefox instance should ALWAYS have normal tabs/menu button/address bar controls right after startup. Then the other obvious short-of-a-reinstall remedy for oddball states, closing and restarting the affected app, will also work.
just hit F11, you just went into fullscreen. you went into it without knowing
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Sorry, but it's not invalid. The actual behavior observed may be a feature, but the fact that you can get it stuck that way and not know any way to get it back to normal short of delete-and-reinstall is, emphatically, a bug. 1. Alt-Enter should exit, or even toggle, it. 2. Double click in empty part of web page area should exit, or even toggle, it. 3. Right click menu in main web page area should have option to exit this mode when in it, or even to toggle it. 4. It should not persist across restarts of Firefox. But right now, a) It can apparently go into that mode more-or-less spontaneously (as in, without it being clear to the user what triggered it); b) One way to fix it is data-losing (clean reinstall); c) The second way to fix it is a non-obvious complex sequence of mouse moves to get at a menu option that isn't easily found (described in one of my comments to this bug above); and d) The third way to fix it (apparently) is a non-obvious keystroke that isn't, to my knowledge, documented anywhere (and by the time the user has reason to want to know about it, presumably FF has gone into this state and they likely do not know of any way to get to the help menu to view the documentation anyway). Now c) is discoverable by foregrounding the affected FF process and then moving the mouse to the very top of the screen, e.g. to hit a navigation link at the top of the current page, and then right clicking around various parts of the reappeared parts of the browser chrome, and that's more or less how I discovered it, but relying on users being able to discover that seems wrong. Likewise, d) is not obviously discoverable short of the user frustratedly mashing the keys, or perhaps systematically pressing them one by one. Of course most won't bother with the latter, either presuming the browser is simply broken and needs a reinstall after more obvious remedies (like restarting it) have failed, or thinking ahead to the roughly six zillion ctrl-this, ctrl-shift-that key combinations they may have to try. (That they'd hit it before resorting to meta keys is not relevant; they'll be daunted by the sheer number of possible keystrokes to try before they try a single one.) And mashing, while actually fairly likely to fix it eventually, will leave them unsure which key actually did the job, and could trigger other poorly-documented features of a similar nature that might prove equally difficult to turn back off. So, I must judge the absence of an obvious way to put the browser back to normal, given that the user didn't intend to and doesn't know how it got into fullscreen mode, short of a clean reinstall, to constitute a bug in the fullscreen mode feature. Therefore, please implement double-click, right-click, alt-enter, and restart-Firefox methods of returning it to normal in the event of unexplained entrance into fullscreen mode.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Sorry, but it's not invalid. The actual behavior observed may be a feature, but the fact that you can get it stuck that way and not know any way to get it back to normal short of delete-and-reinstall is, emphatically, a bug. 1. Alt-Enter should exit, or even toggle, it. 2. Double click in empty part of web page area should exit, or even toggle, it. 3. Right click menu in main web page area should have option to exit this mode when in it, or even to toggle it. 4. It should not persist across restarts of Firefox. But right now, a) It can apparently go into that mode more-or-less spontaneously (as in, without it being clear to the user what triggered it); b) One way to fix it is data-losing (clean reinstall); c) The second way to fix it is a non-obvious complex sequence of mouse moves to get at a menu option that isn't easily found (described in one of my comments to this bug above); and d) The third way to fix it (apparently) is a non-obvious keystroke that isn't, to my knowledge, documented anywhere (and by the time the user has reason to want to know about it, presumably FF has gone into this state and they likely do not know of any way to get to the help menu to view the documentation anyway). Now c) is discoverable by foregrounding the affected FF process and then moving the mouse to the very top of the screen, e.g. to hit a navigation link at the top of the current page, and then right clicking around various parts of the reappeared parts of the browser chrome, and that's more or less how I discovered it, but relying on users being able to discover that seems wrong. Likewise, d) is not obviously discoverable short of the user frustratedly mashing the keys, or perhaps systematically pressing them one by one. Of course most won't bother with the latter, either presuming the browser is simply broken and needs a reinstall after more obvious remedies (like restarting it) have failed, or thinking ahead to the roughly six zillion ctrl-this, ctrl-shift-that key combinations they may have to try. (That they'd hit it before resorting to meta keys is not relevant; they'll be daunted by the sheer number of possible keystrokes to try before they try a single one.) And mashing, while actually fairly likely to fix it eventually, will leave them unsure which key actually did the job, and could trigger other poorly-documented features of a similar nature that might prove equally difficult to turn back off. So, I must judge the absence of an obvious way to put the browser back to normal, given that the user didn't intend to and doesn't know how it got into fullscreen mode, short of a clean reinstall, to constitute a bug in the fullscreen mode feature. Therefore, please implement double-click, right-click, alt-enter, and restart-Firefox methods of returning it to normal in the event of unexplained entrance into fullscreen mode.
Severity: critical → major
Summary: Browser controls spontaneously disappear; condition survives reboot and apparently requires reinstall. → Fullscreen mode persists across restart and has no obvious (discoverable easily inside the fullscreen mode UI) exit.
(Meta) How can this bug be made more readily findable in search results in case others run into this and come looking here? They might learn of the two known non-reinstall ways of putting FF back to normal, but only if the search works. I've retitled the bug to reflect what we now know about it accurately, but it's not clear that searches for "disappearing controls" or "disappearing tab bars" will find it, or any of the other likely ways someone who doesn't know much about what just happened would describe it. Thing is, though there's a "keywords" field above that seems tailor-made for putting extra search terms in to make bugs findable, it doesn't seem to work properly, producing some weird (and scary-big-red) message about "invalid keywords" -- search keywords by their nature are supposed to be arbitrary words, so this makes no sense. (And the keywords, and any other concurrent changes, are lost if you hit "back" after getting that message, which is rather nasty -- fortunately, I'm in Chrome right now and it has form autocomplete good enough to recover all the other changes, such as to the bug title, by typing the first few letters of each change into its box. Also, hitting "back" seems to have duplicated the comment above for some reason. "Back" navigation should never, EVER be broken in such ways by webapps that produce error pages rather than inline AJAX messages so that the natural workflow upon encountering one is to hit "back" and then edit the offending field.)
then this is an enhancement.
Severity: major → enhancement
Summary: Fullscreen mode persists across restart and has no obvious (discoverable easily inside the fullscreen mode UI) exit. → provide an easy way to exit fullscreen mode
bug 474070 may be of interest to you.
See Also: → 474070
Ken, please don't use fields if you don't know what they mean.
See Also: 474070 →
I'd say it's more than just an enhancement. As it stands, FF can get into a state that provides the user with no obvious means of restoring it to normal short of a full, clean reinstall of the browser with attendant loss of stored passwords, bookmarks, form completions, preferences, addons, and other stuff. And in that state: 1. The only UI the user may be able to find, besides whatever clickable links are in the currently displayed page, may be the right click menu on page elements and the page background, none of which provide an obvious exit. 2. The user will not be able to find and use the Help menu without having already solved their problem. 3. The ways out of it are not obvious enough to be confident that the user will find it without resort to the help. 4. If they have no other browser installed, they may be unable to navigate to Mozilla's site to search for help over there. It will depend entirely on what's reachable easily via the links on the currently displayed page. Though if the user discovers the mouse-to-the-top thing they can get at the address and google boxes to navigate with those, and to their bookmarks. 5. The most obvious "if all else fails" remedy of quitting and restarting the browser DOESN'T WORK, and really, IT SHOULD. I cannot stress this enough. There is NO good reason for fullscreen status to be remembered across restarts that I can think of and at least one VERY good reason why it should be forgotten. 6. Common methods of canceling modes (ESC) and, specifically, exiting fullscreen (doubleclick in window, ALT+Enter) do not work. THEY SHOULD, or at the very least two of the three should.
(In reply to comment #10) > Ken, please don't use fields if you don't know what they mean. What the heck are you talking about?
See Also: → 474070
"See Also This allows you to refer to bugs in other installations. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma. You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the Depends on and Blocks fields."
See Also: 474070 →
So you're the one who keeps deleting the see also? Jerk. And what is meant by "other installations"? Most people only have one copy of Firefox, but I expect every installation of FF 5 has this bug and bug 474070, rather than just mine. In any event, it sounds like the "See Also", "Depends", and probably "Keywords" fields are incorrectly named. "See Also" simply means "is related to this", yet when I use it in exactly that manner you claim that doing so is incorrect (and appear to be citing some document I'm not aware of). Meanwhile "Depends" should mean the inverse of "Blocks", so bug A "depends" on bug B if and only if bug B "blocks" bug A. If, as you claim, "Depends" actually means "See Also", and "See Also" actually means nothing that is at all obvious (or even, apparently, intelligible, unless the word "installation" is ALSO being misused by whatever your unspecified source is), then what the heck means "Depends" around here -- and what means "Keywords", given that "Keywords" is not apparently being used for its normal (in internet file contexts) meaning of "additional search terms this should come up under"? And why is nobody apparently using common English words and phrases like "See Also" and "installation" in a straightforward manner? If you want some weird, neologistic meaning for something you should give it an equally neologistic name, not, misleadingly, a normal English word or phrase from which everyone will infer a substantially different meaning than the weird one you actually intended. And I renew my objection to your implied claim that I don't know what the phrase "See Also" means. I do. It is apparently whoever designed this Web form that does not. Last but not least, this bug does not "depend on" 474070; neither bug blocks the other, though fixing 474070 would go a ways towards fixing this one. And what is with your editing the title again? Mine made it clear that the main problems were a) that fullscreen mode survived a restart and b) there was no way to exit it that could be easily discovered by a normal user from inside a fullscreen-mode FF session. Now it just says "provide an easy way to exit fullscreen mode" which someone will no doubt look at and say "already done, just hit F11" and mark this Closed (Fixed) when it really isn't. So once again your apparent fandom for putting misleading labels on things seems to be rearing its head there...
other installations refers to other installations of Bugzilla or other bug trackers. Example, launchpad. If you click the link next to See also, you get https://bugzilla.mozilla.org/page.cgi?id=fields.html#see_also, which describes all the fields in detail. Right now, no this does not depend on bug 474070, but that is why I referenced it in the comments. please keep your remarks civil. I changed the title to increase searchability. The title is just a quick summary of the bug, any developer will read you very lenghty comments and get the details from them. The title shouldn't be the whole bug. So please, keep it civil.
OS: Other → All
At this point I think it best to just dupe this to bug 474070 (duplication in this case meaning same general problem with same main fix proposed). UX has stated that Esc should probably close full screen mode, as it is what would normally be expected. If there is any other succinct enhancement request I would suggest filing a new short bug just for it as this one is now largely an unreadable mess, I'm sorry to say. The general policy is one bug report per specific issue/request. Out of your suggestions above, one that I tend to agree with would be to add "Exit Full Screen Mode" to the page context menu too. Double-clicking won't always work if the page captures clicks and Esc is the more obvious choice here anyway. That being said, I'm at a bit of a loss as to how you can find the top auto-hiding bar which animates away on full-screen mode start and not find the restore button on the right in between the minimize and close buttons. Regardless of there being some legitimate confusion and need for improvement here, Ken, you've posted a din of text (oft repeating), called the person patiently trying to help you a jerk, messed with fields you shouldn't be touching, and generally behaved poorly in response to nice attempts to explain things to you. First and foremost, you need to understand one thing: this is not a support site. This is a bug tracking database for use by Mozilla development. While we do attempt to work with people who are better served elsewhere, the actual support site is at support.mozilla.com, not here. The keywords, dependency fields, & etc. are for usage by people here to organize known issues and planning with respect to development. The terms are often of a technical nature because they're just not for you, simply put. The keywords field specifically only allows selecting from a preset pool of keywords with special meaning. The whiteboard field does allow for arbitrary additional keywords and text to be added to list important information or to make the bug easier to find in a search, as you were attempting with the keywords field.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
Oh, and as to the "see also" field, yeah, it's iffily implemented. It's not really for linking to bugs in this Bugzilla but it is done on occasion anyway. This isn't the place to complain about it, though.
(In reply to comment #15) > other installations refers to other installations of Bugzilla or other bug > trackers. How silly. In the context of a bug report form regarding Firefox, "installations" clearly will be inferred to mean installations of Firefox, not installations of the server-side software that happens to be generating the Web form. It looks like the proper words to use instead of "installations" would have been "web sites" or "bug trackers". As for the proper words to use instead of "See Also", maybe "Related Off-site Links"? > I changed the title to increase searchability. Due to the broken "Keywords" field. We *should* be able to make the title an accurate description of exactly what is wrong and use the keywords field to enhance searchability, instead of either having to cram keywords into the title or make the title misleading regarding the underlying problem or severity of the problem.
(In reply to comment #16) > At this point I think it best to just dupe this to bug 474070 (duplication > in this case meaning same general problem with same main fix proposed). UX > has stated that Esc should probably close full screen mode, as it is what > would normally be expected. Disagree. I didn't expect ESC. I did expect double click in blank area and/or ALT+Enter. So 474070 is too narrow. Better that that should have been marked as a duplicate of this than the other way around, since this one suggests all of ALT+Enter, double-click, and ESC now, not to mention the critically important DON'T MAKE THE FULLSCREEN STATE PERSIST ACROSS RESTARTS!!! matter. > If there is any other succinct enhancement request I would suggest filing a > new short bug just for it as this one is now largely an unreadable mess, I'm > sorry to say. And who is to blame for that? > The general policy is one bug report per specific issue/request. Fullscreen mode being a) capable of switching on unexpectedly and with a non-obvious trigger and b) not obvious how to exit from once that happens IS a "specific issue" and "make it not persist across restarts and exit on ALT+Enter, ESC, or double-click in a blank area" IS a "specific request". > Out of your suggestions above, one that I tend to agree with > would be to add "Exit Full Screen Mode" to the page context menu too. Are you claiming you DISagree with the others?! > Double-clicking won't always work if the page captures clicks A similar objection was raised in 474070 about ESC; but so what? If a page has a huge Flash crapplet that is 1280x1024 and captures ALL input, and fullscreen is entered, only the mouse-to-the-top thing might rescue the user short of clean reinstall. So that sort of argument could be used to veto ANY suggested improvement to the situation. It boils down to "we can't perfect it, so let's not even try to improve it", which is a kind of equivocation fallacy in my book. > and Esc is the more obvious choice here anyway. Not to all users, it clearly isn't. > That being said, I'm at a bit of a loss as to how you can find the top > auto-hiding bar which animates away on full-screen mode start and not find > the restore button on the right in between the minimize and close buttons. First of all, it's only there when the auto-hiding bar is un-hidden; and second, it's a normal Windows control with a normal convention of demaximizing/deminimizing the window. I used alt-tab and then the taskbar to demaximize FF in fullscreen mode when the incident first happened and it ended up, amazingly, as a borderless controlless opaque non-fullscreen window with a chunk of a web page on it cut off at four edges, rather than a normal nonmaximized browser window. So add demaximizing as something that should probably kill fullscreen. If the restore button has somehow been overloaded to do that, but the menu option from the taskbar button does not have the same effect, then that's just one more inconsistent mess here. So, if you ask me the messiness of this bug report accurately reflects the messiness of the problem you guys've created. :) > Regardless of there being some legitimate confusion and need for improvement > here, That's putting it mildly, since a lot of people might trip over this and not find a way to fix it short of a clean reinstall. It's like something out of a bad 80s horror movie -- The Revenge of Evil Duo Emacs and Vi, perhaps. Program can get into a state it's not obvious how to reverse? Check. In that state, it's not obvious how to access the help? Check. Can't exit easily/persists across restart? Check. The one major difference is that you don't immediately have that problem the instant you start up Firefox. :) > Ken, you've posted a din of text (oft repeating), So have you guys. And the main thing I keep repeating is stuff that apparently needs repetition to penetrate some subset of the skulls around here: 1. It should not enter this state seemingly at random. 2. It should not persist across restarts! 3. It should reverse from common keystrokes and mouse inputs that reverse similar states in other applications. You only seem to be noting point 3, and even then only partly agreeing with it. That obviously needs to change. > called the person patiently trying to help you a jerk, Only when he kept undoing helpful changes I made and falsely accusing me of misusing the report form. > messed with fields you shouldn't be touching, Wrong. If there are fields Joe Random shouldn't be touching, those fields should be read-only when logged in as Joe Random. > and generally behaved poorly in response to nice attempts > to explain things to you. If by that you mean I haven't been all sweetness and light when 1. verbally condescended to and 2. ignored repeatedly with respect to some crucial points here, such as that FULLSCREEN SHOULD NOT SURVIVE A RESTART OF FIREFOX!!! then I plead guilty to the high crime of being human. Sue me. > First and foremost, you need to understand one thing: > this is not a support site. This is a bug tracking database for use by > Mozilla development. Yes, and this is a bug. A serious one. > The keywords, dependency fields, & etc. are for usage by people here > to organize known issues and planning with respect to development. Define "people here"? You appear to be excluding me from that phrase, yet as far as I am aware I am in fact a person and I am in fact here, so I must assume that "people here" is yet another phrase that you folks are using in an idiosyncratic and non-standard way. > The terms are often of a technical nature because they're just not for you, > simply put. 1. This is a very nice example of what I mean about being addressed in a rudely condescending manner. 2. "See Also" is not a term of a "technical nature", unless "technical nature" is yet ANOTHER phrase you're using in a nonstandard way, and "Keywords" and "Depends on" have widely understood meanings in connection with searchable web artifacts and bug reports, respectively. > The keywords field specifically only allows selecting from a preset pool of > keywords with special meaning. This is broken, unless you're using the word "keywords" to mean something other than "keywords". > The whiteboard field does allow for arbitrary > additional keywords and text to be added to list important information or to > make the bug easier to find in a search, as you were attempting with the > keywords field. Well, there you have it. The fields are not correctly named. Apparently "Whiteboard" should actually say "Keywords" and "Keywords" should say something else. I don't know. "Flags", maybe, if that's what they are. Nobody would mess with a "Flags" field that didn't know what the specific flags were for but everyone and his brother is going to cram relevant extra search terms not in the title into the "Keywords" field. So we have five separate but intertwined problems here: 1. Fullscreen mode shouldn't "just happen". 2. Fullscreen mode shouldn't survive restarting Firefox. 3. A certain, elsewhere-specified set of inputs should exit fullscreen mode, if not intercepted. 4. The "old hands" here need to revamp this form and a lot of terminology they are using incorrectly. The following transformations seem indicated: a. "Whiteboard" -> "Keywords" b. "Keywords" -> "Flags", perhaps c. "See Also" -> "Off-site Bugs", perhaps d. "Depends on" -> "See Also" e. ??? -> "Depends on" or "Blocked by"; may need to add a field here. f. "people here" -> ??? g. "technical nature" -> "words and phrases we're using idiosyncratically, whether actually technical or not", except that if this is implemented this particular neologism will be obsoleted. 5. Condescending and somewhat brusque attitude of some of the users here who fancy themselves as know-it-alls.
Ken, first off, F11 is a well known and common key for exiting full screen. google how to exit full screen in firefox, F11. IE uses it, chrome uses it, safari uses it, opera uses it. Also, you can at anytime click the maximize button to exit full screen. You either have no idea of standard key and techniques for exiting full screen in browsers (maximize should be pretty clear, and every full screen will show chrome when you mouse up), or have no searching skills. (1)Fullscreen did not just happen, you hit a key, didn't relaize it, and it came up. It happens to me all the time, especially the Fn key on my laptop turns F11 into a volume control. (2)Restarting resetting the fullscreen mode, possibly could be a good suggestion. (3)The set of inputs are F11. Your other key combos are just as hard to fine as F11, and even harder to type since they are two key combos. Every single browser in the world uses F11. (4) no, we are not revamping BMo just because you don't like how we word things. People here are those who are Mozilla community members and employees. Eg, those with canconfirm and edit bugsprivs. And yes, BMO is a technical bug reporting database that Mozilla developers use. It is not friendly towards those who are not developers, because it is difficult to use. That is why we have SUMO, the newsgroups, IRC, etc. I'm working on trying to make BMO more helpful towards end-users such as yourself, but change takes time, and frankly, you haven't been listening to anything we have been saying this whole bug report. I'm sorry have to be blunt, but it doesn't seem like anything else is getting anywhere. Now, if you would like to be helpful, listen to the advice and suggestions those around you are giving you, then I'd love to work with you on making this bug better. But how you are acting now is not facilitating that.
(In reply to comment #20) > Ken, first off, F11 is a well known and common key for exiting full screen. Obviously not, or at least not well known enough. > google how to exit full screen in firefox, F11. If you're suddenly stuck in fullscreen unexpectedly you probably can't get to google. > IE uses it, chrome uses it, safari uses it, opera uses it. I don't use IE, Safari, or Opera and never stumbled upon this in Chrome. > Also, you can at anytime click the maximize button to exit full screen. This is not obvious. > You either have no idea of standard key and techniques for exiting > full screen in browsers (maximize should be pretty > clear, and every full screen will show chrome when you mouse up), or have no > searching skills. Correction: I have no idea of "standard" "key and techniques[sic]" for a feature never intentionally use in browsers and that does not use anything like the same "key and techniques[sic]" used by other applications (games, media players) that I do sometimes want to put in a fullscreen mode, and I have no searching skills under the narrow and specific circumstances of not being able to navigate to google.com because the browser's search and address boxes have mysteriously disappeared. :) > (1)Fullscreen did not just happen, Are you denying the veracity of my own personal eyewitness testimony? > (2)Restarting resetting the fullscreen mode, possibly could be a good > suggestion. Finally, some acknowledgment of what IMO should be blazingly obvious... > (3)The set of inputs are F11. Your other key combos are just as hard to fine > as F11, Obviously not, since I thought of ALT+Enter but not F11. Clearly, ALT+Enter and doubleclick in blank area are not as hard to find. Perhaps because one or the other is used to (de)fullscreen EVERY OTHER APP I'VE USED THAT HAS A FULLSCREEN MODE, from EVERY game that has one to EVERY media player that has one and so on. > and even harder to type since they are two key combos. A clearly specious argument. It's much less important that it be easy to type as that it be easy for a user to think of, WITHOUT access to the documentation and on short notice, based on their prior experience with other applications, if this suddenly happens. > Every single browser in the world uses F11. And nobody seems to actually use the fullscreen mode in browsers much, unlike those in media players and games, NONE of which use F11. > (4) no, we are not revamping BMo just because you don't like how we word > things. I'm not asking you to. I'm asking you to revamp it because Oxford, Webster's, Wiktionary, and dictionary.com all don't like how you word things and they, especially the first two, are far more authoritative that little old me; also because how you word things *leads to user confusion* and is thus *just plain bad ergonomics* any way you slice it. > People here are those who are Mozilla community members and > employees. I have a login here. Does that not make me a "Mozilla community member"? If not, I find it interesting that you a) don't consider ordinary users to be a part of the community and b) moreover don't apparently consider ordinary users to be people. Interesting and disturbing. It suggests a deep culture problem here that can only end badly for Mozilla, if it's a widespread attitude among "people here" (as you have defined the term) and not just among a vocal few people here (as normal people define the term). Perhaps mere users, unpersons and outside the community as we are, shouldn't have direct access to the bug tracker, if you find us all so useless and ignorant about your many arcane ways and nonstandard uses of standard English. > Eg, those with canconfirm and edit bugsprivs. "bugsprivs". You're improving. Now you're using neologisms instead of just making up new meanings for pre-existing words that already have very well established meanings. Nobody's going to misuse "bugsprivs"; they're just going to cock an eyebrow in incomprehension. That's a step forwards, I suppose. Of course, talking to users in plain English using standard dictionary meanings of the words would be a great LEAP forwards. > And yes, BMO is a technical bug reporting database that Mozilla developers > use. And that Mozilla users who run into bugs also use. > It is not friendly towards those who are not developers, because it is > difficult to use. If it's intended to be used by end users to file reports, then that is an ergonomics problem. If it is not intended to be used by end users to file reports, then you have a security problem. In either case, you have a problem. > That is why we have SUMO, the newsgroups, IRC, etc. I have no clue what SUMO even is -- certainly Firefox came with no built-in link or button for it nor was it offered alongside Firefox on the download page. I don't use IRC and though I sometimes use newsgroups, my news server (x-privat) doesn't carry any web-browser-related newsgroups that get much non-spam traffic. Perhaps a web forum (ugh) is in order, since nobody much uses usenet anymore, nobody knows what the heck SUMO is or even that it exists, and IRC is a place you go to when you want to get bombarded with the question "a/s/l?" sixty thousand times, then kicked and banned from some random channel for no logical reason you were able to discern. > I'm working on trying to make BMO more helpful towards end-users such as > yourself, Then I would think you should welcome my feedback on the matter, particularly as I've given some specific and precise advice based on real-world user-testing (to wit, my own attempts to use it), knowledge of what's in those old-fashioned tomes called "dictionaries", and general understanding of software HCI matters (having done some software development myself, in Java and Lisp). Oh, one more piece of advice: nobody will know what the heck you mean by "BMO" since it's not obviously a contraction of either "Bugzilla" or "Mozilla". > but change takes time, and frankly, you haven't been listening to anything we > have been saying this whole bug report. That's because each thing you've been saying, for the most part, has been one of: 1. missing the point in some manner, 2. tangential, but intentionally so, and 3. just plain wrong. I'm sorry to have to be blunt, but those are the plain facts of the matter. :) > Now, if you would like to be helpful, listen to the advice and suggestions > those around you are giving you, There is nothing more for me to do. The ball is in your court to a) fix fullscreen mode so all of the various things users with different patterns of experience are likely to try will escape from it (so, keep F11, and add double click in blank area, ESC, Alt+Enter, right click menu item in page, and ANY triggering of a window-geometry-changed event so any kind of demaximize will undo it -- not to mention RESTARTING FIREFOX SHOULD RESTORE IT TO NORMAL) and b) improve the ergonomics around here, in which I include the attitudes of "people here" (your definition), starting with the apparent tendency to regard "mere users" as unpersons that aren't members of the community and moving on from there.
First off, I will politely answer some valid questions: 1) Yes, BMO, SUMO, & etc. are abbreviations that most people probably can't figure out. BMO is bugzilla.mozilla.org (this site) and SUMO is support.mozilla.com (yes, dot com, not org for the 'O'; yes, it's stupid). Any other similar one you come across that's Mozilla related is probably another abbreviation for some domain name. (e.g. AMO is addons.mozilla.org) 2) Mozilla Support (SUMO) is what you get when you click menu/file->help in Firefox. It's where most people go for Firefox help. It has its own help article system, forum, and chat system. 3) The Mozilla newsgroups are commonly used through Google Groups, though yeah, I personally dislike them too. As to IRC, Mozilla runs its own private server so there's far less crap there. (aptly named irc.mozilla.org) 4) Alt+Enter is the shortcut for fullscreen in a handful of Windows media players. Mine here, however, use the 'F' key. There's nothing really standard in this regard, and it's not applicable to browsers anyway. F11 is what it is for browsers, for better or worse. 5) My point as to why double-click is probably not a good idea is that any interaction with the page itself is not a good idea to be a way to affect the browser state. Video and web pages do not have the same interaction expectations, and while I do agree that escape makes sense as well as the possibility of putting it in the context menu, we don't need yet more ways to get out of fullscreen mode. It's already in the context menu for the auto-hide/show top bar and in the menu itself, and the restore/maximize button that also shows is a fairly standard thing across many OSes. This all being said, your ranting here now has very little to do with your initial problem. 6) Not asked, but assumed: this is not a forum. We're trying to be polite to you and responding to your questions and confusions. (some valid, though with misplaced hostility) When a bug report is used as a forum it generally is ignored by everyone else simply because there's too much text to read in this fairly massive system with a din of work to get through. ----- This may or may not work, but I still feel the need to try: Ken, scroll to the top of this bug report and press page down, one at a time. Look at the wall of text you posted here and think about what you're trying to accomplish. Does this look like anything that will get your point across to anyone but yourself? Does it look like there is a specific point? Or, does it look like we should rename your account to Don Quixote? The path you're on right now is straight towards being ignored and if you spill over into any other bugs like this someone will probably ban you outright. You inadvertently got one thing correct, to some degree: there is a "security" problem with Bugzilla in that it trusts users to at a minimum edit their own bugs. (you cannot, however, edit someone else's bugs unless you have permissions in the system, as we do) It was set up over a decade ago and has evolved since, but it still places a large amount of trust in its average users. Over the years, it's proven to be no longer sustainable simply because of the din of horribly confused users who _should not be here_ fighting with triagers and, well, everything, apparently.
(In reply to comment #22) > First off, I will politely answer some valid questions This seems to erroneous presuppose that there were "invalid" questions from me and/or that there was something from me that should not be answered politely. > 1) Yes, BMO, SUMO, & etc. are abbreviations that most people probably can't > figure out. ... Then perhaps you shouldn't use them in communications with "most people". (At least you now appear to be acknowledging that us users fall within the umbrella of the category "people"...) > 2) Mozilla Support (SUMO) is what you get when you click menu/file->help in > Firefox. Ah. Not that that helps you if the very problem you have is of the nature that if you can click menu/file->help in Firefox you've already solved it. :) > 3) The Mozilla newsgroups are commonly used through Google Groups, though > yeah, I personally dislike them too. Eww. Google Groups. > As to IRC, Mozilla runs its own private server so there's far less **** there. > (aptly named irc.mozilla.org) And how would I have theoretically discovered this? Ah, yes, via menu/file->help, no doubt. :) And the missing search box was where I'd have started if I'd suddenly had a need to find and install an irc client. :) > 4) Alt+Enter is the shortcut for fullscreen in a handful of Windows media > players. It's the shortcut for fullscreen in nearly every Windows media player and nearly every Windows game with a fullscreen mode -- therefore, defacto, in nearly every media player and nearly every game with a fullscreen mode, given the overwhelming Windows market share among a) media player users and b) gamers. > Mine here, however, use the 'F' key. Let me guess: Linux? MacOS? How large a fraction of the web browser market do you think you're actually representative of in terms of your experience with what keys typically undo full screen modes? Or put another way, your argument from personal experience against alt-enter is exactly as valid as a similarly-structured argument in favor of using emacs bindings instead of arrow keys for navigation in multi-line input forms in Firefox. Whereas mine is akin to an argument for using the arrow keys *as well*, for I have not advocated against F11 retaining its current function, only in favor of some other keys that currently do nothing beginning to do the same thing F11 does. > There's nothing really standard in this regard, and it's not applicable to > browsers anyway. F11 is what it is for browsers, for better or worse. This seems to erroneously presuppose that there can be only one key for this function. If that were true, I'd have a very strong case that it should actually be alt-enter based on the likely expectations of the majority of users: Windows users who mainly intentionally use full-screen modes in media players and/or games but not in browsers. But in fact there's no theoretical reason why F11 and alt-enter can't both do the same thing. Especially since alt-enter currently does nothing. It's also less likely that a web app will intercept both keys than that it will intercept only one of the two. > 5) My point as to why double-click is probably not a good idea is that any > interaction with the page itself is not a good idea to be a way to affect > the browser state. Fullscreening/defullscreening the current page is no worse in that regard than adding the current page to the "bookmarks" bit of global browser state, and the latter is already on the right click menu for "the page itself". There's no big stretch from there to including "exit fullscreen mode" in that menu when in fullscreen mode, and no big stretch from that to making double-clicking the page background toggle fullscreen mode. > Video and web pages do not have the same interaction expectations, Actually, to a perhaps surprising degree they do, especially when a common web app these days is an embedded video player such as at YouTube. And you might as well argue that movies and video games do not have the same interaction expectations to argue that they should not have the same fullscreen mode binding. Yet they do, and no obvious harm has come of it. What harm is there in making alt-enter do the same thing in Firefox, particularly when it would NOT be at the expense of keeping the current behavior of F11? Likewise, clicks and double clicks away from specific controls in most applications are expected to bring up generally-useful functions and menu options. And right now FF ignores double clicks in blank areas. So I'm not proposing displacing some preexisting input binding there either. > and while I do agree that escape makes sense as well as the > possibility of putting it in the context menu, we don't need yet more ways > to get out of fullscreen mode. We do. > It's already in the context menu for the auto-hide/show top bar which the user may not stumble upon easily > and in the menu itself, which doesn't appear to the left of the tabs in the auto-hiding top bar in full-screen mode, so is only available it seems if you've already gotten out of full-screen mode > and the restore/maximize button that also shows is a fairly standard thing > across many OSes. Requires finding the auto-hiding top bar, once again, and then guessing that this button won't just change the window geometry without bringing back the missing chrome. > This all being said, your ranting here now has very little to do with your > initial problem. On the contrary, my so-called "ranting" has been very much focused on the initial problem and the potential risks it poses to other users, despite the apparent efforts of some others here to sidetrack the debate. No-one can read my earlier comments and honestly argue that I haven't kept steering things back to the main points I raised more or less right away, regarding alt-enter, the right-click menu, and NOT PERSISTING THIS MODE ACROSS A RESTART! > 6) Not asked, but assumed: this is not a forum. It supports comment threads with threaded replies, so it is, in fact, a forum, among other things. If you don't think that comment threads should exist, go file a bug for Bugzilla itself suggesting removing the "Additional Comments" field from the bug report form. On the other hand, if that's not what you think then your point above appears to be invalid. > We're trying to be polite to you and responding to your questions and > confusions. 1. This erroneously presupposes that I'm doing something that makes it difficult for you to be polite to me. 2. Such "confusions" as I have are the result solely of Principle of Least Surprise violations for which you yourselves seem to have the primary responsibility -- some in Firefox, some in Bugzilla, and some in your own personal pattern of use of language in discourse here. > (some valid, though with misplaced hostility) You seem to interpret honest disagreement as hostility. I wonder why? > When a bug report is used as a forum it generally > is ignored by everyone else simply because there's too much text to read in > this fairly massive system with a din of work to get through. Then hopefully most people will read as far as my explicit and specific list of steps to fix Firefox and stop there before getting mired in all of the nonsense objections that have since been raised to adding menu items, alt-enter bindings, and the like and REMOVING THE PERSISTING OF FULLSCREEN STATE ACROSS RESTARTS! > This may or may not work, but I still feel the need to try: Ken, scroll to > the top of this bug report and press page down, one at a time. Look at the > wall of text you posted here and think about what you're trying to > accomplish. More and more, I'm coming to suspect the closest analogy is "teaching a pig to sing". If you disagree with that, *prove* me wrong by being more reasonable about the suggestions and sticking more closely to the core issue of FF's fullscreen mode behavior. > Does this look like anything that will get your point across to > anyone but yourself? It looks like it should get my point across adequately to any sane and reasonable person with commonplace Windows computer and application experience, basic human-factors knowledge, and a lack of near-religiously-clung-to preconceived notions. I can't vouch for anybody else. > Does it look like there is a specific point? The bits I emphasized very early and have since kept repeating: make alt-enter work. Make double-click-on-blank work. Add right click menu item. DON'T PERSIST THE STATE ACROSS A RESTART. > Or, does it look like we should rename your account to Don Quixote? Disrespectful acts of vandalism against a fellow user's account would constitute clear abuse of privileges if you had them, and criminal hacking if you didn't. > The path you're on right now is straight towards being ignored Being ignored by a loud and vocal minority who seem to have a slippery grasp on principles of basic reason and difficulty sticking to the initial topic would probably be a blessing. Everyone else could then read the salient points and get some useful work done without the noise. In the meantime, what is your REAL objection to my suggestions regarding the right-click menu, alt-enter, and not persisting fullscreen across a restart? Your articulated objections against alt-enter seem to erroneously presuppose that you can have either F11 or alt-enter, but not both, and your articulated objections against double-click seemed based on some vague notions of esthetics or a form of purism rather than on hard and pragmatic things like ergonomics. I haven't seen a coherent argument raised against adding a right-click item or not persisting fullscreen across restart. Note: I don't consider your remarks about me, personally, and about my "rantings" and "walls of text" to be valid arguments against any of those things. If you intended them as arguments against fixing fullscreen mode at all, then they are clearly-invalid ad hominem arguments. And if you didn't, they are gratuitous strayings from the topic at hand and muddyings of the waters. > and if you spill over into any other bugs like this someone will probably ban > you outright. Amazing. I suggest some minor, non-compatibility-breaking added bindings for certain keystrokes and mouse inputs that presently do *nothing*, and that a single bit not be persisted across a browser restart that no-one has yet raised a good argument for persisting across a restart, and you actually *threaten* me? So we have ad hominem arguments, appeals to authority and to tradition, appeals to emotion, and now an appeal to force but STILL no VALID argument against alt-enter, a right-click item, or not persisting fullscreen across a restart. What this tells me is that you have no rational objection to any of those suggestions, but you have some strong emotional distaste for all three, and you are improperly allowing the latter to sway your judgment and potentially endanger FF users' data someday rather than accept the truth of the situation. > You inadvertently got one thing correct, to some degree: Erroneously claims it was inadvertent and erroneously claims I've gotten anything else wrong (indeed, that I've gotten *every*thing else wrong). > there is a "security" problem with Bugzilla in that it trusts users to at a > minimum edit their own bugs. When I tried that, people undid my edits and snapped at me for allegedly using the "see also" field wrong when I used it the way its name implied I should use it. > It was set up over a decade > ago and has evolved since, but it still places a large amount of trust in > its average users. Over the years, it's proven to be no longer sustainable > simply because of the din of horribly confused users who _should not be > here_ fighting with triagers and, well, everything, apparently. The system's designers made it so any FF user can get a login here so they clearly disagree with you regarding who should and should not be here. Furthermore, any "din of horribly confused users" is a result of *you being confusing*, your web site being outright misleading here and there, and your response to users you perceive as "horribly confused" being: 1. Condescend to them and look down your nose at them. Expected behavior by users: they will ignore you and not listen to any of your advice regarding how they should conduct themselves, defaulting to the basic rules of normal civilized debate or, in some cases, to the basic rules of normal uncivilized debate. Why? If you tell a user "you're doing it wrong, you ignoramus, you do this instead of that even though the user interface says otherwise" then that user has two choices. He can either reject any truth in what you said, or accept it. Since accepting it means accepting the "you ignoramus" part in particular and the general "you deserve to be slapped down and spanked for what you've done!" attitude, he will obviously reject it. But rejecting it means rejecting the "you do this instead of that" part as well, and now that falls on deaf ears. 2. Assume that it is the confused users and not the confusing user interface (including both the web form and *you*) that need to be changed. One confused user out of thousands means the confused user is wrong. 999 confused users out of thousands means the user interface is wrong. Human Factors 101. Expected behavior by users: object to the user interface being broken, in some cases. Most may meekly go along with the wackiness, but every one of those is promptly replaced by 10 new confused newbies, and that will remain true until the real cause of the confusion (which is not user stupidity but user interface HCI problems) is corrected. Why? Because you can't change users to better fit your needs, and simply shutting them out kind of defeats the purpose, but you CAN change your own systems' user interfaces to suit your users' needs. 3. Reject anything they say, because "they are confused" and therefore 100% of what they say has to be wrong. Expected behavior by users: Some will just leave, and switch to Chrome or Opera. Some will continue to use FF but switch as soon as they encounter a fresh problem because "FF's support is horribly rude and it's like walking 300 miles across a plain of broken glass barefoot to get them to even acknowledge that something about FF's behavior is a problem, let alone actually patch it in the next version". A few will stay and vociferously argue with you. Why? Because they're right and, moreover, just because they can. Users who see it as "tilting at windmills" (to use your own earlier metaphor) to try to get any bug in Firefox fixed will abandon Firefox eventually to a newer, still-agile and still-responsive-to-user-concerns (or perceived as more responsive than Mozilla, at least) browser. A few won't give up on you without a bit more of a fight and will repeat the points you keep ignoring, e.g. that FULLSCREEN STATE SHOULD NOT PERSIST ACROSS BROWSER RESTARTS and that when some users will find the application in a state for which they can think up/find no apparent remedy short of a data-losing clean reinstall, then some users will experience data loss and if you can do something easy and non-tradeoff-involving to reduce/prevent that and you don't, then all of that data loss is your fault. The fact is, a user can be confused about one thing and still be quite correct about another. You don't like me. You think I'm horribly confused. Mammalian life requires oxygen breathed in to live and, in particular, normal atmospheric partial pressures of oxygen are not a deadly poison to human beings. Are you now going to assume that since I'm horribly confused, I must always be wrong, and therefore normal atmospheric partial pressures of oxygen *are* a deadly poison, and upon this horrible realization promptly try to save yourself from deadly poison by asphyxiating yourself with a plastic bag or in your toilet bowl? Somehow I doubt it. :) Yet your implied ad hominem argument against alt-enter and not persisting fullscreen across a restart is identical to a hypothetical ad hominem argument that because I said oxygen at normal pressures won't poison you you should asphyxiate yourself. And as for "fighting with tragers and, well, everything, apparently", I have one more question for you: Why are you fighting your users? If a large number of them are saying something's broken, then it's broken. If a large number of them are fighting you about something, then you're wrong about that something. Now please articulate, for the record, your full and impartial objections on pragmatic grounds to each of these suggestions, and for each one for which you have no such objections, implement it: * Non-intercepted Alt-Enter in client area should toggle fullscreen where it currently does nothing, without removal of the existing F11 binding that does likewise. * Non-intercepted double-click in blank client area should toggle fullscreen where it currently does nothing. * Right click menu in client area should include option to toggle fullscreen, without removal of any of the existing menu items. * Window geometry change events should turn off fullscreen if it's on, without other changes to the existing response to such events (such as reflowing the displayed page and resizing tab bar, etc); on all such events, the fullscreen flag for the affected window should be turned off if it's on, then the chrome for that window re-set-up based on the new window geometry, then the client area for that window reflowed and page and chrome rerendered to the backscreen buffer, and finally the host told that that window's bounding rectangle is dirty. * Fullscreen state should not be persisted through a browser quit and restart. On startup the browser should come up exactly as it would in current Firefox if all fullscreen windows had been given one F11 keypress event each right before shutdown and all other things had been equal.
Keep it civil. Bugzilla isn't the place for long rants or demands.
How fortunate then that was I wrote is civil and consists of long lists of advice and useful suggestions instead. :)
You need to log in before you can comment on or make changes to this bug.