In the recent Linux builds, the context menu that pops up when you right-click on images are no longer including the 'back' and 'forward' menu items. While this may simplify the menus, it also makes it harder to use the back and forward items as quick gestural tools. I never use the back or forward buttons or the keyboard equivalents.. far less hand motion and effort to just press the right button and make a small wrist movement to go back or forward. Now I have to worry about whether the pointer happens to be resting on an image when I go to make the 'back' gesture. Was this intentional, and would it be possible to undo this change?

Yes it was intentional, it was checked in as "overhaul of main menu and context menus" for bug 108099, and bug 75338

Marking invalid, since this is as designed and thus not a bug.

Yep, the Back and Forward items should still be present for a non-link image (since it's often not obvious where such images end and the rest of the page begins), for precisely the reasons you mention. --> XP Apps: GUI, CCing Bradley since he was talking about this bug as well.

Gah, mid-air collision. Clearing resolution ...

Thanks, Matthew, that's a fine compromise. I'm still a bit troubled by the loss of back and forward at any time, but I read all the commentary on bug 75388 and I see folks have put a whole lot of thought into the new context menus, and with full appreciation of the criticality of muscle memory and keeping context menus as stable as possible.

Changes to the spec need to go to the spec maintainer (currently marlon) / be brought up at pixeljockeys / be discussed in the newsgroup. I implemented by the spec, so this is not my bug.

The problem with this is that its confusing - if I want to go back, why do I have to be sure that I don't click on a link/image/selected text/form element/etc first?

because otherwise we have huge menus and we're back to square one. It's not hard to avoid images. It's even easier not to use the conext menu for non-contextual commands.

Well,if we're not going to use the context menus for non-contextual commands, why not remove 'Back' and 'Forward' from all the context menus? In fact, why not remove the context menu entirely if the user right-clicks on an area onscreen with no specific special context? Right now, right-clicking on an undifferentiated section of a page gives you 'Back', 'Forward', 'Reload', 'Bookmark this Page', 'Save Page As', 'Send Page', 'View Page Source', and 'View Page Info', none of which is context-based. Oh, wait, I know why.. because the right-click menu is the very most convenient way of doing those tasks, and just about every single user of Mozilla to date has depended on the context menu for doing back/forward page navigation. Let's not throw the baby out with the bathwater, here. I think that Matthew's suggested revision of the spec, to allow Back and Forward on non-link images, will help some, and beyond that we'll just have to see how many more users scream about the sudden unreliability of the gestural back command. I'm certainly willing to give the new context menus at least a fair try for the sake of cleanliness.

qa --> sairuh@netscape.com

This is needed for Mozilla1.0. More and more web pages have more and more of their space taken up by images. Many web sites uses images in a seamless way on the web page. It can be hard to find whitespace/text to click on to get the right context menu so you can click "back."

I also greatly miss Back and Forword in context menus on images. Using context menus is much faster then going all the way up to the buttons. Especialy if you have some high resolution monitor. As it is said images on some pages are all over the page and you have to think too much to find a clear spot. And what if you have some images blocked and it doesn't even apear on page?

I forgot to say that I think that 4 main buttons should be on every Browser context menu at the top. So Back, Foreward, Reload and Stop should be always available. Maybe you should only remove the items that are grayed out.

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

#9 To go back, go forward, or to print something is in the context of the page displayed, so when right-clicking on the page, these options should be visible. To do the same is not in the context of any image though.

Sören, the image is part of the page, so Back belongs to the image's context menu too. (not that I really care about this bug, just wanted to point this out)

#16 I disagree. If you think that because a certain object (whether it's an image, plain text, or a 3d animation through a plug-in) is part of a page, it should have a "Back" contextual menu item as well as the page itself, then even Java applets *need* to have that item since they are in most cases very important parts of the page they're on. I think a contextual menu should only have items which are in *direct* context. Just take a look at the several context menus in Windows or in Mac OS - I'll exclude other OS'es here because we needn't go into much detail. The context menu of the trash / recycle bin doesn't have an item "format drive". But yet, the trash on Mac OS is an invisible folder "Trash" on the certain drive, and the recycle bin on Windows is an invisible directory "RECYCLED" on the certain drive. Does Apple, IBM or someone else provide any good HIG's for context menus?

Sören -- by that logic, the "back" button (and other full-page related choices) should never be on the context menu. After all, you're never actually clicking on the whole page -- you're clicking on some text, or an image, or a link, or the background of the page, or some whitespace. While it might be strictly true and logical, it doesn't make for a nice user interface or user experience. Making the navigation options available in all page-element-contexts is the right thing to do.

Look, regardless of whether you think it's "logical" for there to be a Back button on the context menu for an image these things are all true: - many, many, many people expect the first element of ALL context menus to be Back, because that has been the case for eight years; - it is terribly convenient -- one can go Back, regardless of where the mouse is in the page, by moving only a few pixels, instead of reaching for the keyboard, or moving the mouse all the way across the window. It's really a very good and handy thing; - on many, many web pages, it's impossible to tell whether you are over an image or text, or whether you are in a frame cell; - if you do not put Back in the same place all the time, then muscle memory is useless, because the user has to read the menu each and every time. All utility of having Back on the menu at all is gone, if it's not consistent. Please don't overintellectualize this and paint yourself into a corner where your "logic" instructs you to hurt usability.

"many, many, many people expect the first element of ALL context menus to be Back, because that has been the case for eight years;" Uh, what? This isn't the case in 4.x or IE.

> Uh, what? This isn't the case in 4.x or IE. It most certainly is the case in 4.78 and 3.02. Whether you click over nothing, text, an image, a link, or a frame cell, the first two items on the menu are always Back and Forward. In 4.x, item 3 is always Reload or Reload Frame. I'm trying to care about MSIE's behavior, I really am... nope, it's not working.

Not on Windows. And if you're talking about Linux, then even if you're talking about every user you're not talking about "many, many, many people"

> Not on Windows. I'm trying to care about Windows, I really am... nope, not working. I entered bug 136050 as Linux-specific, and it was marked a dup of this bug. > And if you're talking about Linux, then even if you're talking > about every user you're not talking about "many, many, many people" Oh, blow me.

> Not on Windows. It is, for every 4.x version of Win32 Netscape I've used. They may not be at the topmost position, but "back", "forward", "reload", and "stop" is always present no matter which area of the page you right-click (well almost, except native windows widgets and embedded plug-ins). But this shouldn't have anything to do with this bug. The fact is now Mozilla requires users to be *very* careful about where they right-click, and even then it isn't always possible to bring up "back" and "forward". This can cause great confusion and is a serious usability issue. We computer geeks have been trained to reason mathematically and logically, but many of non-geek users do not want such a high level of logic sophistication when they encounter a user interface. What are users going to praise, "oooh... the context menu is so logically arranged that all commands are relevant to context!" or "ooooh... I can access back and forward anytime with a right-click! cool!" ?

Danny: Blake wasn't denying that it appeared on every 4.x menu. merely that it didn't appear at the top, which is what jwz said. People in favour of adding Back and Forward: What two menu items would you remove from the menu in order to insert Back and Forward instead? Don't say "none" because the whole point of the reorganisation was to decrease the size of the menus and they were still not decreased as far as would have been liked. Personally I still can't believe this is that much of a deal. There are already four ways to go back (the back button, alt-left, right clicking on the page and choosing back, and choosing "Back" form the "Go" menu). To quote someone on IRC a few seconds ago: <ho> hah <ho> why do i need to use the context menu to go Back by clicking on an image <ho> who does that?

> People in favour of adding Back and Forward: What two menu items would > you remove from the menu in order to insert Back and Forward instead? Hey, remove 'em all for all I care -- the only context menu items I *ever* use are Back, Copy Link, View Image, and (sometimes) View Frame Source. I use Back three times a minute. I use Copy Link every few hours. I use the others once a week. > Personally I still can't believe this is that much of a deal. There are > already four ways to go back The context menu is by far the fastest of the four (unless your hands are already on the keyboard, which mine rarely are when using a web browser.) > <ho> why do i need to use the context menu to go Back by clicking on an image > <ho> who does that? I think the point your missing is that those of us who use the Back menu item on the context menu do not look at the page and think, "I know, I'm going to bring up the context menu for *this image right here* and then go Back." The image is irrelvant. The object under the mouse is not the focus of attention. The *page as a whole* is. We simply click right *wherever the mouse happened to be*, jerk it a couple of pixels down and to the right, and release -- this action completes before the menu text has even registered on our eyes.

> What two menu items would you remove from the menu in order to insert Back > and Forward instead? Don't say "none"... The people who want "Back" and "Forward" shouldn't necessarily be the people who decide that. We are asking for our feature back. We are not trying to dictate which other features should stay or go. > There are already four ways to go back... Having "Back" in the context menus provides a *consistent* navigation method, because until recently you could always right-click and find "Back". It's quite a shock if you've always used this method to suddenly find that your context menu doesn't have "Back". You suddenly have to search for another way to go back. This is an issue when a page has a very large image or many images. You have to search for a place with no image to right-click in. > who does that? You will also find that there are many users who neither know they can go back with Alt+LeftArrow or by going to the Go menu. Some people only use the "Back" button in the Navigation Toolbar. So, would you propose we get rid of those, too? Who uses them? I would conjecture that one fellow on an IRC channel is not a representative sample of users.

> I use Back three times a minute. You must have a very odd way of browsing the web. I hardly ever go back. > We simply click right *wherever the mouse happened to be*, jerk it a couple of > pixels down and to the right, and release Then I suggest you take a look at mozgest: http://optimoz.mozdev.org/gestures/installation.html > Having "Back" in the context menus provides a *consistent* navigation method, Oddly enough, the other four methods are just as consistent. > So, would you propose we get rid of those, too? Personally I think the Go menu is pointless, so yes, I would get rid of one of them at least. I personally use the other context menu items more than I use Back/Forward. In fact I don't ever recall using Back/Forward and I would be just as annoyed as you are now if the top two menu items were not those I use the most. Well, the arguments from both sides have been put forward, so I guess it's down to marlon to decide whether the spec should be changed or not.

For what it's worth, I'm with Jamie in using back (from the context menu) quite frequently, although perhaps three times a minute is faster than I move around. I don't think his way is particularly "odd", and I think the fact that this bug has caused such a stir is a testament to that.

> I personally use the other context menu items more than I use Back/Forward. In > fact I don't ever recall using Back/Forward and I would be just as annoyed as > you are now if the top two menu items were not those I use the most. The difference being, of course, that Back/Forward have been on every context menu in Netscape/Mozilla for a very, very long time, and some of us are very, very used to using it. The context menu Back is _the_ primary user interface element of Mozilla that I use, right after clicking on underlined words. ;-) Sure would be nice if this could be a simple GUI pref item, or something.

The fundamental problem here is that different people have different browsing habits. You have to be one of us whose browsing habit depends on "back/forward" in context menu in order to understand the importance of this bug. By cutting out "back" and "forward", you're basically saying "your browsing habit is illogical! Don't do this anymore!" I know this is not what the UI designers meant to say, but that's what's happening to us. We, the users who goes back using context menu, are being denied of our browsing habit. What if someone comes along and says "the accessibility features are cluttering up the UI and the code, so let's cut them out"? What would those accessibility-dependent users say?

your browsing habit is illogical! Don't do this anymore!

Although comment 32 was indeed roll-on-the-floor hilarious, i'd like to suggest that we keep flamebait off this bug. This bug has keywords mozilla1.0+ and nsbeta. Doesn't this mean that it's already been decided that this is a bug and that it will be fixed?

I want my Back back too! Since I use a sv/fi keyboard layout that doesn't have a right Alt key Alt+Left is a two handed procedure for me. I'm pretty sure this goes for German keyboards too. As I can't use Alt+Left and Backspace only works on Windows, the context menu is the only reasonable navigation method. (The toolbar button is to far away. So is the Go menu.)

#26+#28 jamie>> I use Back three times a minute. ian>You must have a very odd way of browsing the web. I hardly ever go back. you should try browsing a gallery of thumbnails linked to their larger counterparts then. no ctrl-leftclick/middleclick cheating though :) if the viewed image is large enough to fill the entire canvas, you don't have any unused space left on it to access back via context menu since it was disabled for images.

>no ctrl-leftclick/middleclick cheating though And why not? Tabs rule, plus they work great for me.

i like tabs, too. but opening a new tab prevents you from experiencing the inconvenience of a missing back-link in the context menu since you probably just close it. you can of course do so with your left hand around wasd - keyboard-back would mean letting go of the mouse or travelling half the keyboard with your left. for left-handed people it probably works better the other way round.

Well then I think we've found the solution: people whe use the back feature a lot should just use tabs instead. :-)

Makes me think of another solution. XULPlanet.com used to offer some kind of context menu editor written in XUL, right? How about extending it and offereing multiple presets: - the way it was in 0.9.9 - the way it currently is (and hopefully WILL stay!) - perhaps others This will make anyone happy :-D

Actually, upon thinking about it: why are the context-menu items so general? I mean, if I click on the letter "A", I should only get menu options corresponding to that letter -- I clicked on an A, so it's really unorganized and messy to show options that might have to do with X, Y, or Z, and of course things relevant to the whole word -- or God forbid, the whole page -- are right out. Same thing for images: if I click on a specific blue pixel, I don't want to see any menu choices which might have something to do with the whole image. That's so unlogical. Or something like that.

Why not just use "Save this pixel as..." or "Save this character as..."? Why must clicks be so screen-oriented? I'd prefer mouse-oriented context menus, which would be much more logical. Why not just have "Save this click as...", "Block clicks from this mouse", "View this click...", "Bookmark this click...", and "Send this click..."?

Please file such suggestions as separate bugs.

> Well then I think we've found the solution: people whe use the back feature a lot should just use tabs instead. :-) If only it's that simple. But tabs are no substitute for navigation commands. By your reasoning we could get rid of "back" and "forward" all together, including those buttons on the toolbar. Then people would just browse with hundreds of tabs open in one window. Oh man imagine the fun we'll have. Tabs are no substitute for "back".

for what its worth, i'd really like to keep back/forward in all context menus. i personally use them all the time, and my biggest gripe with IE is that you have to fiddle with mouse positioning before they become available. also, has anyone considered how difficult this will make browsing porn? :-)

imagine using only your mousehand to navigate porn, like in previous versions which allowed us to use the spare hand for .. other tasks. without mouse-back we'd actually have to ... wait. let's not go into details :), but it would be a lot more ... comfortable with easy back-access (+mouse2, 0.5cm down, -mouse2 (oops, doesnt show until i release the button... when did that happen?)) also, the possibility of using altgr+leftarrow does exist in linux, but does not in windows, forgot to mention that. therefore, keyboard-back should be considered to require two hands.

This appears to be beaten to death, but since there's still a lot of opposition and I really want this back, I'd like to weigh in. It is not the app's job to dictate policy to the user. Additionally, I find 'back' context item to be THE most efficient means of navigating pages. My typical usage is one hand on the keyboard, using Alt+key combinations to move my windows around, close them, launch xterms, etc. The other hand is on the mouse. When I want to go back, I follow Fitt's law; the place on the screen I can get to the quickest is the spot directly under the mouse. I don't want to move the mouse to the back button, nor the tab menu, or any other location. I want to leave my mouse where it is, right click and choose the top option - the fastest possible thing I could do. Heck, in many cases I don't even want tabs if I'm doing some linear task (like looking at screenshots or porn). I look at 1 image, go back to the index, load another, and so on. I may not want to load all my images at once, and woe be it to the UI designer that tries to tell me I shouldn't. A lot of people who try a commercial branded Netscape release are going to be very disturbed to see this missing. They haven't seen tabs yet, and it's going to take a while for people to even notice that they're there, much less realize that ctrl/middle click opens them. As for finding something to remove to fit in space for these items, there are a number of items that can be removed. When viewing an image by itself, there are several redundant/useless items like View Image (already viewing), Save Page (same as Save Image), Send Page (same as Send Image), and View Background Image (there is no background image). All of those should be removed, as well as possibly the Bookmark option since it's not really a webpage. If you were to simply reenable back/forward only when looking at a standalone image, I'd personally be happy with that. As for embedded images, the only item that seems unnecessary is possibly the "bookmark this link" option since the user hasn't even seen that page yet. Send image also seems weak - I'm not sold on this send image/page option, I doubt that most users send embedded images frequently enough to warrant a context menu item. However, View Image -> Send Image may be inconsistent and fool some users. Even if no items can be found to remove, this is sufficiently important to bloat the menus slightly - I use back more than every other feature in the context menus combined and I'm not the only one. I'm pretty sure mpt and many others would concur.

I understand that AOL and Netscape might want to not display "back and forward" in certain context menus. There is probably a very good business reason for this decision. Is this something, though, that we could fix on Mozilla, and still leave as an optional extension for distributors/embedders, including AOL, Netscape, and others?

folks, we had to decide which principle was more important for *common use*: 1) prioritize toward convenience, or 2) exposing features within a context (power or mere convenience). We decided that 'usable' power was favored over 'messy' convenience; and, our most common users don't need a replicated main menu buried deep down in an expanse of submenus. At least, it's not how the predominant user would tend to navigate, so we scaled back the presence of page navigation to just within the page context. I fully understand the page space vs inline image ambiguity with the design of many webpages, but the hard fact is that adding those 4 items to the necessary inline image set would result in a 16 item menu, and would push contextual image items further away from the cursor (if placed at the top). We can't afford to jeopardize utility of the menus to support the occasional, heavy contextual navigation scenario. i'd rather solve the navigation issue in gestural mousing and chording solution, rather than burden the context menus.

Is there anything that absolutely speaks against the iCab way, that is, create a lot of context-sub-menus like "page", "images", "links", etc.? I'm sure someone has iCab installed here and can make some screenshots; if not, I will do so tomorrow. It keeps the context menus clean and yet provides a lot of items. BUT I still think that it is against the term "*context* menu".

Marlon -- it's not just visual "ambiguity". As I tried to point out (a bit sarcastically, I admit), images and "page space" are conceptually on the same contextual level. Images are just as much part of a page as a bit of text is. Therefore, page-context items shouldn't mysteriously disappear just because you've happened to click on an image. Pushing the image-specific context items down by four (or one -- I'd be happy with just restoring "back") doesn't reduce the utility by a measurable amount: bringing up image context menus doesn't come into "*common use*" very often at all. And when it does, having a really really short context menu doesn't improve things very much. As for encouraging "power" use -- the right-click menu "back" is arguably a more powerful and quicker way to browse, so if that's what's at issue, the navigation options should *definitely* be returned. If things really must be removed, they should be even less common items like the Bookmark/Save Page/Send Page ones (but again, I think those should stay for images if they should stay on any context menus at all).

I know this is a bit late, but in regards to comment #25 where it was asked: "What two menu items would you remove from the menu in order to insert Back and Forward instead?" Instead, how about moving the image related items to a submenu? I know I personally don't use them all that often. This way, nothing is removed, but we still get smaller menu's and back/forward buttons. I don't mean to beat this to death some more, but I felt I should provide a suggestion.

"Well, the arguments from both sides have been put forward, so I guess it's down to marlon to decide whether the spec should be changed or not." Why was Marlon's "spac" allowed to trump all the good work that mpt has done with UI specs? While I hardly use the nav. buttons in the context menus, I can understand the reasons why others do. But more importantly, mpt's reasons in this case and all others that I've read his comments on "make sense". They are based on good UI principles. The alternative seems to be based on something else. I've tried to be a good Mozilla advocate but the UI work in the interface has been one of the stink bombs in this project.

> Why was Marlon's "spac" [sic] allowed to trump all the good work that mpt has > done with UI specs? Marlon took input from mpt and other pixeljockeys and n.p.m.ui members. > I've tried to be a good Mozilla advocate but the UI work in the interface has > been one of the stink bombs in this project. Please take this to the newsgroups or staff@mozilla.org. Bugzilla is not the appropriate forum for this. Anyway. Based on marlon's comments, the spec is staying the same. WONTFIX.

Wait, how is this both mozilla1.0+ *and* "Resolved/Wontfix"?

Re: Marlon's comments: "At least, it's not how the predominant user would tend to navigate, so we scaled back the presence of page navigation to just within the page context." Since the behavior of "the predominant user" justified the closing of this bug, could Marlon provide the statistics/surveys/testing that support this conclusion? I would be most interested in knowing how the behaviors of "the predominant user" were determined. Yes, of course, most of this belongs in the newsgroups but these comments are directly related to the resolution of this bug.

Is the WONTFIX overruling mpt's suggestion that the nav items be added back to the non-link image case?

Hmmm, I obviously care a little too much about Mozilla when having a bug like this marked "wontfix" actually makes me really sad -- it feels like one of the great little-but-powerful advantages Mozilla had is suddenly thrown away for no good reason and our chances for world domination decrease. But obviously I need to get a life. If this bug is indeed dead, I've opened bug #136665 "[RFE] make pref. for page-navigation options on all context menus", for the good of the future.

Marlon, I'm confused about your complaint that including the 4 navigation items would make the context menu 16 items long. They currently include 7 image items and 3 page items. Adding all 4 navigation items would make the menu 14 items long, not 16. Also, it makes sense to remove the page items (send/save) because they're easily confused with image items and not near the top of the context menu, but the navigation items cannot be confused with image-related commands and are often used as gestures. Removing the page items and adding "back" and "forward" would make the context menu shorter. I'm also not clear on what you mean by "the predominant user". Is that an average browser user, an average browser user who chooses a browser and recommends it to his friends, or an average browser user who often intentionally right-clicks on images?

Reopening - technical discussion is still taking place, and we're going to need a dup target.

Re comment 58, there are currently 12 context menu items when the image is also a link. Do all of us who want "Back" really also want "Reload" and "Stop"? I would happily sacrifice these if that brought back "Back".

"Bookmark this page", "Save Page as", and "Send Page" are other full-page-context items which currently show up on the image menu but seem less frequently required than Back/Forward.

using back mostly when browsing image galleries, its function would equal that of "stop" in this context whereas "reload" and "forward" would hardly be useful. i therefore agree with Leston Buell (comment 60)

the "predominant user" explanation I gave is an estimation based on knowledge and experience that has been accumulated by marketing and usability. But since this question boils down to an argument of principle, as i pointed out in my previous (power=feature*context; power vs mere convenience), it's trivial to answer about something so general and well established as design principles. So while we don't pull up numbers from some infinite database of randomly collected data to support every minute menu item, we do know for a fact that the sophistication level of our predominant web user does not match a model for the 'context menu navigator' user type. there are exceptions, we do know that things for certain like [Set Image as Wallpaper] was highly preferred.

Marlon -- I'm a bit confused. You characterize this as "power vs mere convenience". I'm all for power over "mere" convenience (I'm a Linux user, after all!) but I'm having trouble seeing why removing Back/Forward is somehow more powerful. (I agree, it's certainly less convenient.) At first I thought it was because the idea was to only show the options applying to the most narrow relevant context (comment #40), but that's obviously not true since several options left on the the menu relate to the whole-page context, and since the navigation options do appear when you click on some types of page elements. So that can't be it. (And even if it is, I'm not sure that significantly increases the "power".)

I don't think that most "predominant users" even use right-clicking much. I think that if you're sophisticated enough to learn about right-clicking, you can also handle a non-trivial context menu. I don't understand why we're being so concerned about the cluttering effect of menu items some users deem essential when they occur in the context of a menu that few users will ever see anyway. The typical user uses a browser to navigate the web. It is only a more sophisticated user who will be using "Send Image" and only an even more sophisticated user to use "Block Images from This Server". Did we have people clamoring about the image context menu being too cluttered the way we have people clamoring about the disappearance of the "Back" item?

the Inline Image Menu is a widely used and popular example, as are Image as Link, and Text as Link. These 3 heavily used menus are naturally going to have a propensity to receive everyone and their grandmother's most favored behavior represented. These 3 cases are also at some level of ambiguity, as we all certainly agree. Therefore I tried to established (as indicated in the spec) a core set of items for each, that would represent the fundamental utility of the menu and rate each item individually according to it's value to that menu. The Content Area Core includes: Back Forward Reload Stop ----------- Bookmark This Page Save Page As Send Page Create Destkop Shortcut [Back], [Forward], [Reload], and [Stop] were identified as 'expendable'; [Bookmark This Page], [Save Page], (storage items) were identified as 'less expendable'; [Send Page] was identified also as 'expendible' however less costly (only one item as opposed to four). The main goal of the Inline Image Menu then, is to provide tools for interacting with images, secondary would be the core page specific items provided for ambiguity caused by most web sites. i am wondering if it would be possible upon right click to determine the percentage of total page size that an image occupied, and if it met some sort of predefined value say 75%, then we would leave in the navigation items in the inline image menu.

Thanks, that's helpful stuff to know. I guess the main point of this bug is to ask you to revaluate the "expendableness" of [Back] and [Forward] -- they're obviously "less expendable" to a lot of people here, and apparently "extremely vital" to some of us. [Stop] and [Reload] are "more expendable" -- see comment #60. And perhaps [Forward] would only show up if there's actually something to go Forward to? (Not sure how that fits with the mozilla UI rules.) If [Send Page] were also dropped, this would leave the menu exactly the same size in the case where there is no [Forward], and only one item bigger otherwise. Also, I find that big images *aren't* the primary thing I'm running into. Rather, it's sites which use transparent images as spacers -- very common on the web today. I think that's a much worse case than the gallery one. Same thing for sites that just use a lot of graphics in their design in general.

> i am wondering if it would be possible upon right click to determine the > percentage of total page size that an image occupied, and if it met some > sort of predefined value say 75%, then we would leave in the navigation > items in the inline image menu give me strength... by god man, that has got to break every UI rule in the book. i think it's fairly obvious that the people have spoken here: just put the damn back/forward menu items back in. if netscape wants it some other way, they can obviously have it their way. mozilla users prefer the navigation menu items intact.

>[Stop] and [Reload] are "more expendable" -- see comment #60. And >perhaps [Forward] would only show up if there's actually something to go >Forward to? some time ago we established [Back], [Forward], [Stop], [Reload] as a characteristic grouping, making it easy for users to identify and understand. Much like clipboard shortcuts - cut, copy, paste, select all - these kinds of groupings depend on their combined association to convey clear and unambiguous use for a given context. therefore, [back] without the associated [forward], [stop], and [reload] would be undesirable.

I just read an interesting chapter in a UI Design book call "Designing for Both Sides of the Screen" The chapter was about respecting the physical effort that a user has to go through in order to perform certain tasks. One of the big points in there was to minimize the amount of effort that a user had to put forth in order to perform common tasks. I will try to apply this here as best I can by looking at some of the alternate forms of going back/forward, stopping a page from loading, and reloading a page. 1. Navigation buttons. A person can move the mouse pointer over to the navigation buttons in the upper left-hand portion of the screen to perform the four basic navigation functions. This is fine if the user already has the mouse there. For example, let's say the user has their mouse pointer in the middle of the screen. There may be a link, button, etc. that they are interacting with, but they need to perform a reload or go back to a previous page. To access the nav buttons, the person has to move the mouse pointer about eight inches depending on resolution (I'm at 1024x768). The problem here is that the mouse pointer is not where it was anymore, thus you are forcing the user to bring the mouse pointer back to where it is supposed to be. By having the four basic navigation items in the context menu, the mouse pointer stays close to where the user is working and has become more convenient and efficent. 2. Keyboard shortcuts. Ask yourself this question: do you like switching from a mouse to a keyboard and back all the time? By forcing a user to do this, you're breaking the flow of what they're doing. Another perspective is handedness. (I hope that's the right word) I'm right-handed and typically have my left hand on the keyboard, thus it's easy for me to reload or stop a page using the keyboard. It is inconvenient for me to move my right hand to the keyboard to perform a back or forward operation. For a left-handed person, it's probably the opposite. Ultimately, we don't want to interrupt the user's "flow" when using an application. It is good practice to minimize the amount of work a user has to do to perform simple operations. I can't claim to be an expert on this subject, I just read this chapter about fine minutes before I posted this long message, (Sorry!) but I hope I at least get the point across. If you happen to have a copy of the book around, read it. So far, it's a pretty nice read.

Marlon, sorry to tell you that, but your choice looks rather stupid to me for all the reasons exposed before and for some other obvious reasons like these : - The suppression of back/forward items forces you to have the Navigation toolbar open which makes the new Full-screen mode rather pointless (Most of the screen estate saved, results of hiding the navigation bar). Do you mean that if I am in real FS mode and want to go back I have to click on the grippy to get the navigation bar back, click on the back button and then click a third time on the grippy to hide the space-consuming navigation toolbar ? - I select a blank space to right click and I do not get my "back" option... Instead I get a view image link but there is no image, even not a spacer gif. Oh, I forgot that I blocked all add images from this site !!! So instead of a back option, I get image options for images I precisely blocked. Another nice Mozilla asset loosing some of its interest. - same thing happens if you surf with images off to speed up your surf, you get the option to "view" the images you did not want to see (of course it doesn't work since images are blocked) but you can't use the fast access to the back/forward feature when you were precisely looking for speed. - what about accessibility for disabled people who have the greatest difficulties to move the mouse and are probably very happy to find a fast and easy access to navigational options ? Will they have to go all the way up to the toolbars because Mozilla UI specialists think that having a permanent instant access to back/forward in a browser is not "logical" ? - by definition a browser is used to browse pages. From a Web surfer POV going back and forward is his main activity. Does it mean that Mozilla will not offer the possibility to do a basic task faster than its competitors so a to please those in favor of an ordered world ? Are you sure that you are not mixing up "Ordered" and "Logical" which are two very different concepts ? - If contextual options are such an absolute notion, why can't I see "select all" or "Find in page" when I right-click on text ? Is Viewing an image a more common task than selecting or searching text ? Following your logic, there is absolutely NO reason to have back and forward items in ANY contextual menu. Indeed, your argumentation is based on the fact that the available options have to be related to a specific context and I think that everybody will agree that back/forward is related to the general browsing context. (Of course, I do not even speak of the "keyboard alternative", a keyboard shortcut mobilizing both my hands is hardly what I'd call a nice surfing experience :-) Pascal

In 0.9.9 back/forward still there on linked images, but shifted down. Please keep back/forward on links and linked images. I would prefer back/forward always be at the top (like ns 4.x) since that is the reason I am right-clicking 99.9% of the time, regardless of where I am on the page.

> [Back], [Forward], [Reload], and [Stop] were identified as > 'expendable'; [Bookmark This Page], [Save Page]... 'less expendable' I don't understand this. I use "Back" after every few pages. I use "Bookmark This Page" and "Save Page" only once or twice a day. Who on earth uses storage functions more often than basic navigation functions? And it is not fair to say that the basic navigation functions are not image-contextual and are also available by other methods (through the toolbar and by keystroke), because "Bookmark" and "Save Page" are also not image-contextual and are also available by these other methods.

would it be possible to re-enable the "back" menuitem when the document type is image/*? this should at least solve the gallery problem.

>From blockcipher@yahoo.com 2002-04-10 18:26 ------- > >1. Navigation buttons. A person can move the mouse pointer over to the >navigation buttons in the upper left-hand portion of the screen to perform >the four basic navigation functions. This is fine if the user already has >the mouse there. For example, let's say the user has their mouse >pointer in the middle of the screen. There may be a link, button, etc. that >they are interacting with, but they need to perform a reload or go back to >a previous page. To access the nav buttons, the person has to move the >mouse pointer about eight inches depending on resolution (I'm at >1024x768). The problem here is that the mouse pointer is not where it >was anymore, thus you are forcing the user to bring the mouse pointer >back to where it is supposed to be. By having the four basic navigation >items in the context menu, the mouse pointer stays close to where the >user is working and has become more convenient and efficent. actually there are far superior alternatives to using context menu for navigation which i am in favor of, such as 'spider-menu' or 'mouse gesturing' (the latter opera has somewhat interestingly but questionable implementation). I intend to pursue such cool ideas on future PRD. >2. Keyboard shortcuts. Ask yourself this question: do you like switching >from a mouse to a keyboard and back all the time? By forcing a user to >do this, you're breaking the flow of what they're doing. Another >perspective is handedness. (I hope that's the right word) I'm >right-handed and typically have my left hand on the keyboard, thus it's >easy for me to reload or stop a page using the keyboard. It is >inconvenient for me to move my right hand to the keyboard to perform a >back or forward operation. For a left-handed person, it's probably the >opposite. actually, at the moment our users predominantly use their mice rather than keyboard. however we're not debating about keyboard vs. mouse here, but I agree with your point nevertheless. >From pascal@chevrelbureau.com 2002-04-10 19:36 ------- > >- The suppression of back/forward items forces you to have the >Navigation toolbar open which makes the new Full-screen mode rather >pointless (Most of the screen estate saved, results of hiding the >navigation bar). Do you mean that if I am in real FS mode and want to go >back I have to click on the grippy to get the navigation bar back, click on >the back button and then click a third time on the grippy to hide the >space-consuming navigation toolbar ? when we designed fullscreen's primary usage it was to support full time browsing, however we did give it much consideration which is why you see a fairly useful and browsable fullscreen mode today. it's primary intention is for big screen presentation where keyboard navigation or custom navigation suffices. right clicking in white space of course will definitely supplement this case >- I select a blank space to right click and I do not get my "back" >option... Instead I get a view image link but there is no image, even >not a spacer gif. Oh, I forgot that I blocked all add images from this >site !!! So instead of a back option, I get image options for images I >precisely blocked. Another nice Mozilla asset loosing some of its >interest. The spec is decidedly Netscape feature specific, so it doesn't unfortunately address the image blocking stuff. so i understand this point entirely and perhaps mozilla UI experts could decide how to handle the blocked image case better for us. >- same thing happens if you surf with images off to speed up your surf, >you get the option to "view" the images you did not want to see (of course >it doesn't work since images are blocked) but you can't use the fast >access to the back/forward feature when you were precisely looking for >speed. i would say that is more of an error in our implementation, which you could file a bug for if you'd like to help out. clearly if all images are turned off, there's not much reason for an image context menu, right? >- what about accessibility for disabled people who have the greatest >difficulties to move the mouse and are probably very happy to find a fast >and easy access to navigational options ? Will they have to go >all the way up to the toolbars because Mozilla UI specialists think that >having a permanent instant access to back/forward in a browser is not >"logical" ? presence or lack of context menu based navigation should not affect users with disabilities. access keys and accelerators provide better means with accompanying hardware/software setup for some cases. >- by definition a browser is used to browse pages. From a Web surfer >POV going back and forward is his main activity. Does it mean that >Mozilla will not offer the possibility to do a basic task faster than its >competitors so a to please those in favor of an ordered world ? Are you >sure that you are not mixing up "Ordered" and "Logical" which are two >very different concepts ? none of the other competing browsers (except 4.x who's context menus weren't designed) have navigation items in their inline image menu. if it's not common usage, we shouldn't support it. (technically Opera does have a Page flyout with absolutely every item they could offer, but i don't think we should go that route) >- If contextual options are such an absolute notion, why can't I see "select >all" or "Find in page" when I right-click on text ? in the regular content area menu? because those aren't features aren't decidedly 'contextual' - items i can do already in the main menu. >Is Viewing an image a more common task than selecting or searching >text? i don't know >Following your logic, there is absolutely NO reason to have back and >forward items in ANY contextual menu. that's not my logic. >Indeed, your argumentation is based on the fact that the available >options have to be related to a specific context and I think that everybody >will agree that back/forward is related to the general browsing context. you are correct, but when there are possibly 3 levels ambiguity how can you offer up the most *related* set of task for the intended goal? conversely, if i intentionally right clicked on an image, why do you give me a huge menu with some navigation at the top when i intend to do something with this image? that would seem slow and impractical, over the course of interacting with several images over the entire span of the relationship browser and user - too cumbersome. it's too much clutter for my image-based tasks, when the predominant model for navigation is toolbar based (and keyboard based) the purpose of the context menu, again, is to support contexts for low to high frequency marginal cases, not to replicate mainstream *work flow* menu items. (pay attention to 'mainstream' in contrast to 'high frequency') it is a special 'toolbox' for performing a local task, not the entire garage. It is not a question of who uses what more often, but "how or what can i do to this object?", "how can it provide a 1 step shortcut to a two or three step goal?", and does it allow me to build a concise routinely behavior with what normally would take several operations. This is the definition of a 'shortcut' - too often confused with another term which you're advocating called, 'redundancy' >From Leston Buell 2002-04-10 21:34 ------- > >> [Back], [Forward], [Reload], and [Stop] were identified as >> 'expendable'; [Bookmark This Page], [Save Page]... 'less expendable' > > >I don't understand this. I use "Back" after every few pages. I use >"Bookmark This Page" and "Save Page" only once or twice a day. Who >on earth uses storage functions more often than basic navigation >functions? And it is not fair to say that the basic navigation functions are >not image-contextual and are also available by other methods (through >the toolbar and by keystroke), because "Bookmark" and "Save Page" are >also not image-contextual and are also available by these other >methods. the purpose of the context menu, again, is to support contexts for low to high frequency special use, not to make redundancy of regular work flow items. as i said above, it is a special 'toolbox' for performing a local task, not your entire garage. >From Lars Hugentobler 2002-04-11 07:23 ------- > >would it be possible to re-enable the "back" menuitem when the >document type is image/*? this should at least solve the gallery problem. the spec has indicated a case called, "Image as URL" , which blake might not have implemented yet

howcome such a major menu alteration was left so late in the day? should such major changes be made on the eve of moz 1.0? by reading the comments here it would seem that a lot of the mozilla community will be sticking with earlier milestones instead of using the official 1.0 release.

Marlon, Thank you for your response. While there may be other, better alternatives to context-menu navigation, since they haven't been implemented yet in the default browser, context-menu navigation is still the most convenient method. However, if these better methods were implemented on top of existing navaigation, I would be interested in trying them out, but that's for another bug.

Couldn't this be something you can set in your preferences?

vcato -- bug #136665 is RFE to make this a pref.

From Marlan's list: Back Forward Reload Stop ----------- Bookmark This Page Save Page As Send Page Create Destkop Shortcut My opinion on the 'expendability' of these items: Back - useful Forward - less useful Reload - possibly useful, but generally not Stop - possibly useful, but generally not Bookmark This Page - simply drops the bookmark for the current page at the end of the top level of bookmarks. It does not bring up a dialog box the way File Bookmark does. This means that I essentially *must* go to Manage Bookmarks immediately thereafter (or eventually, if I'm lazy) to actually put it where it belongs. As such, there's no point in using the context menu version, and I'd be better off using the normal File Bookmark command. Expendable, unless this is changed to act like File Bookmark. Save Page As - saving a document is a common command in any program. The three most common ways of doing that are: File menu; toolbar icon; Ctrl-S. Toolbar icon isn't relevant. File menu is present. Ctrl-S is present. Why do I need to have this in the context menu? I can't think of any programs I commonly use that place something like that in a context menu. Expendable. Send Page - potentially useful, if it actually used my system's default mailer instead of always bringing up Mozilla's email. So for me, completely useless at this point, but generally useful for those who use the built-in email. On the other hand, I don't see it as overly useful in a context menu. Probably expendable. Create Destkop Shortcut - I don't even see this on any of the context menus, so I really don't know what to say about it. So for the question of which items I'd sacrifice to get the other items replaced: On standard images, I would drop Bookmark This Page, Send Page and Save Page As and bring in Back and Forward, though I'd keep Bookmark This Page if it was changed to act like File Bookmark. For linked images, on the other hand, I wouldn't change anything for the same reason you don't have Back/Forward in the menu of regular links. Comments for Bookmark This Page/Link would still apply, though. So, I would propose that you don't have to change the size of linked image context menus (leaving them at 13 items), and that standard menus could be adjusted to be either remain at 10 items (if you only add Back/Forward), or expand to 12 (if you insist on keeping all four items as a group). Either way, you're still not increasing the maximum size of the context menus, and have the option for dropping only one of the possible menu items and have it match the size of the linked image menu.

I'm all for making every software as customizable as possible to suit all user's needs. This is exactly what Micro$oft is not doing. They are writing a piece of software and push it down the user's throat. No IE developer ever asked users if they want tabs or a back function on the context menu. So let's make the context menu customizable. Instead of putting Backward and Forward on some context menus and on others not, make an option: [_] Put Backward, Forward, Stop and Reload on top of every context menu If it is enabled, Mozilla will try to put it onto every context menu it can (excluding Java applets and plugin menus), if it is disabled, it's never there. I hardly ever use it, so I would disabled it to keep my context menu tidy. But there are some people who do use it and they will want to enable it. If it is disabled, it will not be displayed on any context menu. BTW, another idea would be to make Stop and Reload exlusively. While the page is still loading, the third entry is Stop, if it has finished loading or was stopped, the entry is Reload. Since you can't stop a stopped page or completely loaded page anymore and since it makes no sense to reload a page that is still in the loading process (not unless you stopped it IMHO), there's no need to always display both. So the option should be: [_] Put Backward, Forward, Stop/Reload on top of every context menu

Have you seen the number of prefs we already have? And you want to add more?!

Ian, it's pretty clear that a good number of people actually depend on the presence of the back menu item in the context menus.. I actually came across a complaint about the removal of the back menu item in an entirely unexpected, non-mozilla context.. see the eighth message in this talk forum: http://forums.ttgnet.com/ikonboard.cgi?s=3cbb3bdd7e8cffff;act=ST;f=19;t=446 You've made it clear in this bug thread that you don't use the back menu in the context menus at all, if you ever even go back at all. That's fine, and you shouldn't have to. Please understand that many of us do, and that this is a big deal to many of us, whether it seems logical to you or not. In any case, discussion of a new preference item for this should go on bug 136665, not here.

Maybe this is one of those features which should result in a different browser for different users, as described by hyatt in http://mozillian.blogspot.com/2002_04_07_mozillian_archive.html#75279564 Since marlon has clearly stated that his spec won't change, I am again going to mark this WONTFIX. This does not preclude further discussion, but please do not reopen this bug unless the spec is changed.

My opinion: Context menus should be *context* menus only. Don't add generic convience stuff with "Back" to it. IIRC, the spec showed the menus of MSIE and Opera and another browser, and the 4.x way to put everything in there is an abnomination. I do think, however, that there should be *some* means to access Back and other commands in all cases, e.g. by readding the menu bar, if the site hid it.

In that case, I've filed bug #137655 -- make the UI consistant. It's worse to have the back command appear and disappear arbitrarily.

Ben -- the navigation commands aren't "generic convenience stuff". They're specifically in context for a web page. (They wouldn't be relevant for a mail message, for example.) The question is whether the context menus should only have the narrowest possible focus or whether it's more useful to have that be a bit broader.

Re comment 85: As other comments have pointed out, the browser is always in the *context* of a page. And also as other comments have pointed out, the image context menu still contains some items which have nothing to do with images, such as "Bookmark this page". Frankly, if this bug is being marked "wontfix", then the way this bug has been treated makes me angry. For the sake of entirely conceptual motivations (such as elegant design), a feature and a consistent behavior has been taken away from people who use it regularly and consider it important. The designers have told us that our browsing habits are odd and have dictated to us the newly prescribed modes for going forward and backward. No concessions have been made, and no evidence has actually been presented to the effect that these features went unutilized by users of earlier versions of Mozilla and of Netscape. Furthermore, no evidence was given to the effect that any users actually want this feature removed.

> no evidence has actually been presented to the effect that these features went > unutilized by users of earlier versions of Mozilla and of Netscape. For the record, I am told that Netscape actually did do usability studies on this and this heavily influenced marlon's decisions regarding the spec. I'm sure Netscape have their reasons for not publishing the results publically.

Thank you for pointing that out. I asked about this earlier, but no one responded to my question.

That would probably be comment #66. My guess, not knowing the details, is that the methodology of the study was biased against this to begin with -- concentrated on the usability of context menus as narrowest-focus UI elements. This would be consistant with comment #48 and the conclusion that having less items on the menu is more powerful. People who want this bug fixed, by contrast, are focused on the usability of various ways of going back one page -- a very common navigation option. Obviously my experience isn't a scientific study, but in my observation, once people learn to use the right-click->Back option, they rarely bother to use any other way. This experience is supported by all the other people flustered people here. The difference between these two starting points explains the highly polarized and frustrated comments from both sides -- we're not really talking about the same thing.

Once again I'd like to ask for clarification.. a number of good suggestions have been brought up in the course of this bug, from mpt's suggestion that Back and Forward be put back on non-link image context menus, to questions about the necessity of 'Bookmark This Page' and 'Save This Page' on more context menus despite them being each far less frequently invoked actions than 'Back', to the Stop/Reload item merge.. all of that is being rejected, in specific opposition to the generic 'put back/forward on everything' sentiment? Is this continuing to be a matter for discussion in the newsgroup everyone is referencing? Where is this newsgroup at?

I wonder if these were the same kind of Netscape usability studies that led to the Shopping button being added to Communicator 4.7+? Everyone knows how important a UI feature that was! At least in that case, Netscape had the sense to include a preference to disable that button.

I reply to Marlon (comment #75) >when we designed fullscreen's primary usage it was to support full time >browsing, however we did give it much consideration which is why you >see a fairly useful and browsable fullscreen mode today. it's primary >intention is for big screen presentation where keyboard navigation or >custom navigation suffices. right clicking in white space of course will >definitely supplement this case Full Screen mode is a very popular feature among IE users. I don't think that it is because evreybody uses it for big screen presentation : it is simply the best way to save real estate screen. Your proposed alternatives : 1 keyboard navigation : highly unefficient, I have to leave the mouse and use my two hands to go back. It means for instance that I can't surf while holding the phone, drinkink tea, smoking... 2 clicking on a blank space : ok, but first I have to find one in a page full of images, and since the menu does not take into account image blocking, I am not sure that it will always work (inconsistency). What about the many sites created which are made up of image maps ? (fireworks is a very popular program among graphic designers :-) ex : http://www.gdbi.com/ >The spec is decidedly Netscape feature specific, so it doesn't >unfortunately address the image blocking stuff. so i understand this point >entirely and perhaps mozilla UI experts could decide how to handle the >blocked image case better for us. Do you mean that taking image blocking into account into the code would be possible whereas having different menu options for Netscape and Mozilla distributions wouldn't? I have the disagreable impression that this Netscape spec is more based on the idea that it will not disturb the IE user target than on ergonomics. Some quick observations: -I filed a bug for the image menu problem (137662) - When I talked about disabled people, I precisely thought of tetraplegic people, they can't use a keyboard but can sometimes slightly move a mouse. I think that it would be bad news for them. - the argument "if it's not common usage, we shouldn't support it." sounds very harsh to my hears. Most of Mozilla features (starting with standards compliance) are not common usage and this is precisely why I like this browser : it has a different approach of the web than IE and Opera. I get the overall impression that a Netscape marketing wish is being forced to us with some lame conceptual excuses to give it technical justification, and this just before the release of 1.0. People here have given lots of valid points against this change, both pratical and conceptual, but it really looks like this decision will be "Netscape only" despite the fact that this is one of the most voted UI bugs. Pascal

As perhaps the most vocal defender of this bug, I'd like to say: enough is enough. I don't think the UI designers are doing this because of some evil corporate Netscape mandate -- they've done it because they think it's the right thing. I'll personally miss this feature, but Mozilla is a great browser nonetheless (and I do appreciate all the work they've done on making its UI very nice). That said, I still think Mozilla needs an equivalently easy way to go back or forward, regardless of context. Please join me in netscape.public.mozilla.ui to discuss.

> For the record, I am told that Netscape actually did do usability studies > on this and this heavily influenced marlon's decisions regarding the spec. On further thought... Although this may be true, i would assume that many earlier versions of Netscape also underwent usability testing. Why was it decided to retain (or add) the navigation items in the context menus at that time? It's hard to argue either way with data one isn't privy. I don't see what Netscape could possibly have to lose by sharing the results of such testing with regards to this particular issue. Of course, if none of the participants in the testing ever uses right-clicking for navigation, then the study would be biased against those of us who do, as suggested in comment 91. The fact that the navigations items were retained for so long does suggest that the motivation to remove them couldn't be terribly strong. (I'd like to echo Matthew and say that i don't think that the UI people are incompetent or conspiratorial, as some comments here seem to have implied. I just don't agree with this particular decision.)

I agree to comment #84. It should be up to a Mozilla distributor to decide whether fixing this bug in their releases is useful, since it depends largely on the target userbase.

#92 nntp://secnews.netscape.com/netscape.public.mozilla.ui is the Mozilla UI newsgroup and thus the perfect place to continue this discussion.

First to all people that always say "A context menu is limited to a certain context": If this is what you want, then remove back, forward, stop and reload of ALL context menus, because no matter where you click, it's never in the context, IMHO. Removing it only from some menus is inconsequent. If I click somewhere on the page where nothing is (although hardly possible on many pages), I have clicked on the page, and "back" is not part of the context of the current page, it's a browser command ("go back to the last page") that has nothing to do with the current page. Also who do you expect to use these entry anymore if they are not on top of all menus? If they are on top of all menus, users can rely that they will always select back if they righ-click, make a quick movement and left-click. If this is not the case (like it is now), users can't rely on that (and they also can't rely that at the location where they just clicked no image spacer is located, poor design, should be made with CSS, but still used rather often) and the time users waste to look if back is actually present at the context menu or not, and if not the time they waste to find a location where it might be present, makes the whole idea of having it there pointless (as I think the point of having it there is to save time) and users will be faster when moving their mouse to the top of the window and hit the back button or hit backspace on keyboard. IOW nobody will use it any longer and then you can remove it from all menus. To #82: The number of prefs has decreased since 0.9.8 (at least the number of prefs you find under preferances, hidden prefs that users can only alter by altering the config files don't count). There are now much less option under Tabbed Browsing and rejecting Cookies by site policy is missing completley. I don't see how this tiny option would be a big deal, considering that other programs allow you to customize all menus for example, as well as which symbols appear on the symbol bar and in which order (IE allows you to do that last one for example). I'm pretty sure there are also programs that allow you to customize the whole context menu. BTW, a context menu customizer exists for Mozilla, so you don't have to know XUL to customize it yourself, however, it only allows you to say which context menu entries are allowed to be there and which ones not and the ones that are not will simply never be there. It does not allow you to decide WHEN the allowed items are displayed (if you click on a picture, link, marked text or the page).

Hixie: > For the record, I am told that Netscape actually did do usability studies on > this and this heavily influenced marlon's decisions regarding the spec. I'm > sure Netscape have their reasons for not publishing the results publically. Well, since this is an open source project I frankly don't care and I think drivers should handle it the same way. Come on! If I present an inconsistent UI change (tell me leaving the Back button in some context menus isn't inconsistent) and back that up with some usability study that I won't disclose, would my patch go in? Didn't think so. > Maybe this is one of those features which should result in a different > browser for different users So we all agree that Netscape can apply the patch in their branded release but that it gets backed out in Mozilla? After all, this browser is for developers and they seem to use the Back item in the context menu fairly heavily (look at the votes and comments). This bug makes me angry too, simply because of one fact: it DOESN'T get backed out, although it would be the sensible thing to do. If Beonex or any other "smaller" corporate contributor came up with such a drastic change so late on the 1.0 road everyone would say "You can include it in your product if you want, but Mozilla 1.0 won't have that change". But since it's Netscape that doesn't happen. And this sucks. Mozillas audience DOES WANT this feature. Act accordingly. Since we are on the topic, when gets all the AOL/ad thing that we have in Netscape 6 checked into the trunk? Why does that take so long?

Mozilla's target audience is not web developers. Mozilla's target audience is distributors such as Netscape, Beonex, IBM and RedHat. And it is clear from the argument in this bug that "Mozilla's audience" is not wholy on the camp of wanting this feature. staff@mozilla.org have said that the module owner gets to decide what goes in. The module owner has said that we should follow the spec. The spec is clear about where the menu items in question appear. The author of the spec has explained his position and is unlikely to change his opinion since no new arguments have come to light. The module owner has no reason to not trust the UI designer. Therefore the only way you are likely to see this changed in Mozilla builds is to get staff@mozilla.org to change the module owner to someone who agrees with you. I suggest you ask your Mozilla distributor (if you use RedHat, Beonex, Netscape, etc) or embedder (if you use OEOne, Galeon, Chimera, etc) to change the context menu in their release. Failing that, as I mentioned above, you could always start your own distribution or embedding project whose target audience expects to be able to use the "Back" menu item in all context menus.

Ian, we've been arguing whether this is good or bad for ordinary users this whole time. The point of an open source project is to decide things publicly. Your suggestion of sending private e-mail to the all-powerful authority is the same advice I could receive by asking for some change in a closed source, proprietary software program. This bug is just one issue in an otherwise superb piece of software. The Mozilla Project has generated an enormous amount of goodwill in the technically skilled portion of the Internet using population. I'm confident that Mozilla will be a much larger success than it is already. Goodwill toward Mozilla felt by skilled techs and developers will play a significant role in Mozilla's success. On the other hand, if the Mozilla Project exhibits the kind of arrogance, disregard, and egotism toward people who are contributing to the Project as has been exhibited in this bug, then the goodwill Mozilla has today will begin to disappear.

There are three reasons for leaving this as WONTFIX: 1. ian has changed this to wontfix *not* out of egoism or arrogance, but because the UI designer made it clear *why* this *won't* fix. 2. others agreed with this. 3. the fact that mozilla itself doesn't have the back and forward contextual menu items in certain cases does not at all mean that every distro or embed will copy this decision. It's just a spec, or call it a "recommendation" like the W3C would. It's not an order from the lord. There is one reason for reopening this: 1. Some people apparently didn't understand the concept of module owners (which, admittedly, has its flaws, but that's an entirely different issue), but still want to influence this project for their benefit.

Hixie: > And it is clear from the argument in this bug that "Mozilla's audience" is not > wholy on the camp of wanting this feature. Who (besides Netscape) wants this? > staff@mozilla.org have said that the module owner gets to decide what goes in. > The module owner has said that we should follow the spec. The spec is clear > about where the menu items in question appear. The author of the spec has > explained his position and is unlikely to change his opinion since no new > arguments have come to light. The module owner has no reason to not trust the > UI designer. Therefore the only way you are likely to see this changed in > Mozilla builds is to get staff@mozilla.org to change the module owner to > someone who agrees with you. 1. The spec is founded on a internal usability study. Noone can see if the results are as stated in previous comments or what's more important, take a look at HOW they came to this conclusion. This is how it works in open source projects: You make all the information public and then the community decides. That's what Sun did with OpenOffice and Gnome. 2. UI designers make mistakes. mpt himself writes in his blog how inexperienced he is. This doesn't mean he doesn't know what he is doing, but it means that he could be wrong. 3. I think the whole "this is more logical" argument is moot. The new context menus aren't more logical, just shorter. Nobody seems to argue about that AFAICS. Logical or not, the old "back" in context menu was used by a lot of people because it was CONVENIENT. 4. How can the module owner have no reason to distrust the UI designer? Have you missed all the discussion on this bug? Have you missed the other bugs that are being filed just because this one won't get fixed? WHERE ARE THE USERS that rejoice because this fundamental flaw in Mozilla has finally been fixed? I STILL think something like this couldn't happen if there weren't so many people in decision-making positions being paid by Netscape. > Failing that, as I mentioned above, you could always start your own > distribution or embedding project whose target audience expects > to be able to use the "Back" menu item in all context menus. While I agree with you I still haven't seen one explanation why it shouldn't be the other way around. So Netscape has a closed usability study. They are free to implement the suggestions made there in their own branded distribution, since they are not willing or able to share the study with the rest of the community. Why do they have to abuse their power on this project to force such a change so late in the 1.0 development?

> Mozilla's target audience is not web developers. What on earth does navigation have to do with developers. I use back and forth when i'm surf, not when i'm developing. I suppose the XBL test suite under "Debug" and the "Web Development" submenu under "Tools" are also to be construed as targeted towards end users rather than towards web developers. > the fact that mozilla itself doesn't have the back and forward contextual > menu items in certain cases does not at all mean that every distro or > embed will copy this decision. It's just a spec, or call it a > "recommendation" like the W3C would. It's not an order from the lord. Yes, but it's wise to keep people like me and the many other people tracking this bug using Mozilla rather than some by-product. You might not like our input on this particular bug, but between us, i'm sure we've filed and helped fix many, many other important bugs. Do you really want to send us away to use another browser, thereby discouraging us from participating in the Mozilla project. If we were to switch to using Beonix, we wouldn't be very useful to the Mozilla project anymore.

Whislt speaking personally I am disappointed with the way the currently used context menu spec was arrived at, to be honest our content menu creation speed is so slow on linux that its probably faster for me to go to the toolbar anyway. As a result, I'd propbably end up supporting bug 137655 instead, but not too strenuously. I do, however, think that this behaviour is bad because it introduces an inconsistancy in which items are shown when and where, meaning that I can't rely on a particular item being at the top, so I have to stop and waste time looking for the item I wanted anyway. (the 'memory muscle effect' the new spec was supposed to improve) That said, this is the spec, which was implemented with the approval of the xpfe UI module owners, and its obvious from discussion in this bug that the spec will not be changing. Marking VERIFIED. Please do not reopen this bug unless you are a member of staff@mozilla.org, drivers@mozilla.org, or a UI module owner.

Okay people, here's the ULTIMATE solution for this problem, that should stop all arguing! Let the Mozilla people do it the way they want it to do and then let me fix it :) It took me about 15 minutes to find out where the pop-up menu is located and how to hack their JS code, so I can now pretty much implement ANY context behavior you want. You can have back, forward, reload and stop always there if you like or only when you click on certain items. Also I can put ONLY back there, for people who don't need forward, stop or reload or maybe just back and reload, whatever you want. To be honest I have no idea about JavaScript so far, but for someone who is good at Java coding, it's not such a big deal to read JavaScript code (also it looks rather poor compared to Java). First I had a problem to get menu items into the right order (certain functions were always displayed on top of back, which is of course undesired), but then I found this XUL file, which is XML, meaning it looks pretty much like HTML and it took me maybe another 5 minutes to figure out where the menu items are defined and they always appear in the same order like defined in that file. So now I can also alter the order in any way you want. I hope that these code changes are platform independent, but why shouldn't they (JS and XUL looks the same on all platforms). Unless the Mozilla programmers change this code completely in the near future, it will be no problem to implement whatever context menu you want into Mozilla 1.0 and even if they alter this piece of code, I'm sure I will also figure out how the new code works. So just count on me! If navigation stays out of 1.0 or the relaese candidate RC1, I will put it in again and offer the modified code my webpage. Basically you will just have to overwrite a single file in the Mozilla install directory with my modified file (at least I hope this will work). The question is only: How should I modify the code? Should I put the whole navigation stuff on top again, or just "back"? And should it be always there or only if you click on certain context and if so, in case of which context should it be there? Or should I offer different versions and if so, which ones? Well, this is certainly not the right forum to discuss that, my e-mail address is tgos@spamcop.net (just for the case), but we could take this to an appropriate Newsgroup if you like (suggest one) and discuss it there. I will be glad to help people out of this misery. You know the old saying: If you want something done right, you have do it yourself ;) For me this bug has died, I will retreat my vote, there are more important things that needs to be fixed and that I can't fix myself.

> Okay people, here's the ULTIMATE solution for this problem, that should stop > all arguing! Let me thank you for that. [ Patch using modified XUL + JS chrome ] > To be honest I have no idea about JavaScript so far, but for someone who is > good at Java coding, it's not such a big deal to read JavaScript code (also it > looks rather poor compared to Java). Well, it's a scripting language - it's made to be simple and efficient for scripting stuff, not for coding a whole application. [..] > Basically you will just have to overwrite a single file in the Mozilla install > directory with my modified file (at least I hope this will work). Does that mean you'll offer the modified .jar archive? In that case, yes, that would work. Someone might even be able to put it in an .xpi so it will be a one-click install(TM). > [..] Or should I offer different versions and if so, which ones? It's up to those that feel the need for this (I don't belong to them, but respect and understand that they need it), but I believe to offer multiple versions is best (and really not much effort other than the diskspace and bandwidth on the server). > Well, this is certainly not the right forum to discuss that, my e-mail address > is tgos@spamcop.net (just for the case), but we could take this to an > appropriate Newsgroup if you like (suggest one) and discuss it there. I will be > glad to help people out of this misery. netscape.public.mozilla.ui is probably the best place to discuss this, as mentioned earlier. You know the old saying: If you want something done right, you have do it yourself ;) > For me this bug has died, I will retreat my vote, there are more important > things that needs to be fixed and that I can't fix myself. And I agree and would really like it if people stopped *still* spamming this bugs with "I can't believe this is WONTFIX!" comments. :-) That kind of discussion shall take place in the mentioned newsgroup, or at mozillazine.org, etc.

Comment #102 From Andrew Hagen: > > Ian, we've been arguing whether this is good or bad for ordinary > users this whole time. I was replying specifically to the statement made in comment 100. > The point of an open source project is to decide things publicly. The point of free software is that it be free of licensing restrictions. That's the only point. It is only *because* this is free software that you are able to take the source code and change the behaviour to suit you as you wish. That this is a free software project is totally independent on how it is run. (Take Linux for example. Linus controls everything in the source tree, and he does not need to explain himself.) > On the other hand, if the Mozilla Project exhibits the kind of > arrogance, disregard, and egotism toward people who are contributing > to the Project as has been exhibited in this bug, then the goodwill > Mozilla has today will begin to disappear. Again, I urge you to contact staff@mozilla.org and explain your opinion. They set the rules. Comment #103 From S?ren "Chucker" Kuklau: > > There are three reasons for leaving this as WONTFIX: [...] Thank you. You summed up the situation quite nicely. Comment #104 From Stephan Jaensch: > > Who (besides Netscape) [doesn't want the back menu item] ? Based on the comments in this bug, the following people who are not Netscape employees have said they are happy with the current situation: Dean Tessman, S?ren "Chucker" Kuklau, the majority of Netscape users in a usability study, and me. (Personally I don't really mind that much, if the spec is changed I would accept it.) > This is how it works in open source projects: You make all the > information public and then the community decides. That is nonsense. There is nothing inherent about a free software project which makes it a democrary. > The new context menus aren't more logical, just shorter. Nobody > seems to argue about that AFAICS. FWIW, I think they are more logical. > the old "back" in context menu was used by a lot of people because > it was CONVENIENT. A "lot" of people? So far evidence suggests that it is used by a mere dozen people, most of whom are here. The back menu item is still there on the page menu anyway. The huge magority of users use IE, which doesn't have the feature you are asking for. Even 4.x had the menu item in a different place on each menu on Windows. So far no browser with noticable market share has had this the back menu item at the top of all context menus, it fact. > 4. How can the module owner have no reason to distrust the UI > designer? You'd have to ask the module owner. > Have you missed all the discussion on this bug? Have you missed the > other bugs that are being filed just because this one won't get > fixed? WHERE ARE THE USERS that rejoice because this fundamental > flaw in Mozilla has finally been fixed? They are browsing the web, happy. Comment #105 From Leston Buell: >> >> Mozilla's target audience is not web developers. > > What on earth does navigation have to do with developers. I use back > and forth when i'm surf, not when i'm developing. See comment 100. > I suppose the XBL test suite under "Debug" That is targetted at Mozilla QA, the only people who should be using Mozilla-created binaries of the Mozilla source. (Mozilla QA includes all of us.) Comment #107 From tgos@spamcop.net: > > So just count on me! If navigation stays out of 1.0 or the relaese candidate > RC1, I will put it in again and offer the modified code my webpage. Basically > you will just have to overwrite a single file in the Mozilla install directory > with my modified file (at least I hope this will work). Thank you!!!

> A "lot" of people? So far evidence suggests that it is used by a mere > dozen people, most of whom are here. Evidence surely does not suggest that, as this bug has 28 votes, in addition to comments on this bug from a number of people who did not bother to vote, in addition to at least one comment that I've seen on mozilla out 'in public'. I don't see any XP GUI bugs in bugzilla that have more votes. Of course, two or three dozen votes is nothing against 'usability studies on the majority of Netscape users', so.. It's obvious this matter is considered settled for now by the UI owner, and that's that, but it would be nice to at least have the grace not to lowball the evidence of dissatisfaction on this item. Aaaand I'm going to call it a day on this bug. Anyone have any suggestions for a more productive way to get involved at this point? I've spent at least half an hour a day for the last several days worrying over this bug, sure would be nice to get at least some return for my time if I'm going to devote this much energy to Mozilla.

When you say Netcape has done usability studies, what is probably meant is: "MS did usability studies, and we are just copying their menus". Well, the lack of page context in certain occasions is one of the most annoying "features" of MSIE, and oone of the things that made me stick with Netscape and Mozilla even at 0.8.X builds. I'm looking for a project fork that implements context menus right.

About the "lack" of votes and/or response: I have been using 0.9.9 until yesterday, and the behaviour was right. When I read this bug I thought it has been already fixed. Then I downloaded a nightly (04-18), and was quite surprised on the speed improvements, until I tried to go back during navigation, and I found myself staring at an absurd image (fortunately it was not a transparent gif, or it would have been a blank page). Then I remembered what I had read a few days ago, and felt terribly angry. How do you expect feed back from users when this misfeature has only been available in nightly build for a few days? I have added my vote to this bug, (I have subscribed for that). I agree with comments about page context being the only significant one for navigation. As an example, five minutes ago I had selected a paragraph and then, as I wanted to go back, I moved the mouse away from it and right-clicked, only to find "undo" there. Wrong! I am left handed, as some of the other people commenting, so this can make a difference. I'm quite sure you (where you is whoever "fixed" this) are doing "the wrong thing" here. I'm also quite sure that there will be much more people angry about this when the next release build is there. Let us wait and see. P.S.) WRT losing time on this one, I think that changing years long navigation habits is a much greater effort. This is the reason why I'm willing to lose time here (subscribing, commenting, voting) and willing to contribute to a project to deliver a better contextual menu system for me and for other people. People feeling the same please contact me to organise ourselves.

A "lot" of people? So far evidence suggests that it is used by a mere > dozen people, most of whom are here. The reason I, and probably others, have not submitted comments to this bug is because the existing comments, for the most part, expressed my concern of removing the feature. I've actually lost sleep over this one. The loss of the back item definitely changes the way I browse. It is a *feature* I have enjoyed for the last 5-6 years and not just a menu item. The 110 comments in this bug, the other bugs opened for the same problem are based on nightly builds. I imagine there will be more complaining once the next milestone and updated netscape versions are released? I agree fully with comment 111, the usability studies were probably created with IE users. Having the back button appear "sometimes" prevents it from being usable.

sgala@apache.org: > P.S.) WRT losing time on this one, I think that changing years long > navigation habits is a much greater effort. This is the reason why I'm > willing to lose time here (subscribing, commenting, voting) and willing to > contribute to a project to deliver a better contextual menu system for me and > for other people. Sadly, Mozilla is not a project with a real open source spirit, at least that's the impression you get when reading this bug (and many others that include "political" decisions, for that matter). Just read Ian Hickson's comment regarding Free Software: "The point of free software is that it be free of licensing restrictions. That's the only point." That's NOT the only point. A real Open Source project like the Konqueror browser (part of KDE) would NEVER simply remove a widely used feature like this. And stop the FUD about "nobody cares", we have THIRTY VOTES without even a milestone out with this change!! SUN published their usability study on StarOffice 5.2. They published their usability study on GNOME. And then they worked with the community to implement the needed changes. Everyone helped, everyone could see WHY these changes needed to be done. Netscape just wants people to find bugs and otherwise shut up. They make the decisions, and as you can see from this bug they really don't give a shit what the Mozilla users/testers want. They could have simply made the change to the branded Netscape release, but why bother?

(please review comment 35 for preface) i cant speak for others, but what annoyed me most about it is exactly that. optimoz is a nice way of navigating, but with few mousebuttons, i dont have a spare one available to gesture-navigate an image (mouseL=drag&drop, mouseR=context, mouseM=paste). prehaps resolving bug 138074 would help most of us (moved my vote) and keep the developers happy, as it would be according to the spec.

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

Just for the archives (all the action seems gone by now): In http://www.mozilla.org/projects/ui/communicator/framework/contextmenus/digest.html, Marlon Bishop says: >In my proposal, the Frame Subset context menu is designed so that: 1) frame >specific items are relatively burried in a flyout, and 2) structured to offer >users *site-driven, goal-oriented* functions, not *engineering-driven, document >oriented* functions. This model promotes bookmarking of "netscape.com", not >"nav.html" There are two key points in the paragraph: - Users don't need document-oriented functions, but goal-oriented - what matters is "netscape.com", not "nav.html" So, we have that a user don't see the page as a compound document (or only marginally so) but as a page. My daughters, 10 and 7, just learning to use text processors, browse pages, not documents. They are just learning that you can further decompose a page. Jamie Zawinski expresses it very well (#26): >I think the point your missing is that those of us who use the Back menu item >on the context menu do not look at the page and think, "I know, I'm going to >bring up the context menu for *this image right here* and then go Back." This comes handy with my previous #111 (and harsh, I was really angry) comment about : >Well, the lack of page context in certain occasions is one of the most annoying >"features" of MSIE, and oone of the things that made me stick with Netscape and >Mozilla even at 0.8.X builds. Eureka! now I see: the reason why MSIE has **** context menus: it is because Microsoft is a highly document centric company, and they think that a user looking at a web page is really seeing images, tags and frames. Well, when I do this I need a holiday for sure. What remains to be explained (to me, at least) is the apparent inconsistency between the statement opening this comment and things like #48, both from Marlon Bishop: >folks, we had to decide which principle was more important for *common use*: >1)prioritize toward convenience, or 2) exposing features within a context >(power or mere convenience). We decided that 'usable' power was favored over >'messy' convenience; and, our most common users don't need a replicated main >menu buried deep down in an expanse of submenus. > >At least, it's not how the predominant user would tend to navigate, so we >scaled back the presence of page navigation to just within the page context. >I fully understand the page space vs inline image ambiguity with the design of >many webpages, but the hard fact is that adding those 4 items to the necessary >inline image set would result in a 16 item menu, and would push contextual >image items further away from the cursor (if placed at the top). We can't >afford to jeopardize utility of the menus to support the occasional, heavy >contextual navigation scenario. > >i'd rather solve the navigation issue in gestural mousing and chording >solution,rather than burden the context menus. Given both the internal inconsistency of this comment and the disagreement of the conclusions with the previous one (are frames more intrusive than images?), the only reasonable conclusion is politics. When you are about to move several millions of users from MSIE by any other name to Netscape by any other name, and the usability tests are run on those precise people, you see what the results will be. So here usability is an euphemism for legacy support. But still I don't get it. Why don't you just do it in Netscape, and leave Mozilla for us poor souls that have been using Back since Netscape 3.0? Sorry for the long rant. Back to my poor life. I feel better now. :-)

Why not just do it in Mozilla, and leave it to your distributor (whoever that is) to add the items you want in your version? I don't see why Netscape should be the distributor to have to change this in their tree, given that the only actual research done on this subject supports what we have now. But that's irrelevant. The reason this is staying as is is that the module owner said he is following a particular spec. Per staff@mozilla.org rules, the module owner gets the final word. When Netscape disagrees with the module owner, then Netscape change things in their tree; when _you_ disagree with the module owner, _you_ should change things in _your_ tree.

> Why not just do it in Mozilla, and leave it to your distributor (whoever that > is) to add the items you want in your version? I don't see why Netscape should > be the distributor to have to change this in their tree, given that the only > actual research done on this subject supports what we have now. I'd say making this change in Mozilla and hearing the screams should itself count as some sort of research. There is a lot in the spec that seems questionable (cut, paste, delete and undo in a non-editable page? wtf?), it's hard to imagine that the research was done on these menus.

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

> I'd say making this change in Mozilla and hearing the screams should itself > count as some sort of research. Possibly. But only for a "geeky" target audience. What about the general user? If you want a browser for "geeks", then do as hixie suggested and change it in your tree (or, recommend / propose / suggest a maintainer of a tree for "geeks" to do so). > There is a lot in the spec that seems questionable (cut, paste, delete and undo > in a non-editable page? wtf?), What about forms? What about the URL bar? > it's hard to imagine that the research was done on these menus. We're not here to reveal a Netscape conspiracy. If they claim they did research on this, then we're supposed to believe they did. And the module owner seems to agree to the results of that research, which are packaged in Marlon's spec.

>Possibly. But only for a "geeky" target audience. What about the general user? >If you want a browser for "geeks", then do as hixie suggested and change it in >your tree (or, recommend / propose / suggest a maintainer of a tree for "geeks" >to do so). It's not the geek in me that protests, but the naive user. Most users don't know this can be changed at all.My daughter's reaction to such issues is: "The computer won't allow me..." They take program behaviour as a given, not something that can be changed. Raising awareness that this decision is not well grounded, and can be changed back is what I'm trying to avoid with my noise. Also, some users are forced to use bad browsers (MSIE comes to mind). If you present most people with an ergonomic chair, a lot will feel uneasy about it, and you can find amazing results unless you are very careful in the setup of the test. So saying that usability studies have been done, without presenting the statistical evidence to be peer reviewed has null value. I'm getting patches for this, but I would prefer to deliver a "polilla" project (Spanish for moth), a POLished mozILLA, as source code patches that can be used to enhance usability. Another example is the absurd resistance that the URL bar has to lose focus in certain contexts (If you press ESC, for instance, and then page down to keep browsing). >> There is a lot in the spec that seems questionable (cut, paste, delete and >>undo in a non-editable page? wtf?), > >What about forms? What about the URL bar? The URL bar is outside the page context, so context there should be different. WRT forms, I agree that input fields need additional context *when they are active*. I use the mouse to select sentences when I'm reading long papers and move to reference material in a different tab, to have a visual clue when I come back. For this "intrapage-bookmark", the undo/cut/paste menu is again useless. I agree this is possibly personal, although features like having a visual bookmark when returning to a page would be definitely useful. A different use case: I'm searching for "context" in a Google search result. The browser selects the word. I discover quickly that this paper is not related with this discussion. So I go Back... ****! a grey Undo is there... :-) This is another use of text selection as a visual bookmark, but this one is "built in". This is how I learned the "select to know where I was" clue. >> it's hard to imagine that the research was done on these menus. > >We're not here to reveal a Netscape conspiracy. If they claim they did research >on this, then we're supposed to believe they did. And the module owner seems to >agree to the results of that research, which are packaged in Marlon's spec. > Point take. Nevertheless, I'm supposed to have right to doubt about something that has only been vaguely quoted. I would be much happier with third party public studies. Specially since there is a heavy logical jump, that I commented in #117, between the general principles of the spec and the conclusions, and it is only backed up by vapour-studies. Quoting from: http://www.cosc.canterbury.ac.nz/~andy/papers/gestureNav.pdf Web browsing applications support many mechanisms for revisiting web pages, including `favorites' (or bookmarks), history tools, and the back button. The back button is a dominant source of user actions. In Catledge and Pitkow's study, the back button accounted for 41% of all page requests. Tauscher and Greenberg [11] also found heavy use of `back', with it accounting for 30% of commands. The forward button, in contrast, was lightly used, accounting for only 2% of actions. This is in heavy contrast with Ian's comment (#28): jamie>> I use Back three times a minute. ian>You must have a very odd way of browsing the web. I hardly ever go back. So, maybe we are not the geeks, after all :-)

I definitely fall into the geek category, but I actually picked up the right-click-back behavior from my non-geek father-in-law, who uses netscape navigator maximized with all the toolbars turned off. People in general like efficiency and ease-of-use -- that's not just a geek thing.

>> I'd say making this change in Mozilla and hearing the screams should itself >> count as some sort of research. > Possibly. But only for a "geeky" target audience. Since we have been given no info on Netscape's research, we don't know what it's biases were. So it's hard to say that removing the feature reflects general user bahvior and retaining reflects geeky behavior. I see nothing inherently geeky about using a context menu to navigate. I think that Santiago gives very sound reasoning in comment 117 that page decomposition (being conscious that a page can be decomposed into subparts) is actually the geeky behavior.

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

> Possibly. But only for a "geeky" target audience. What about the general user? > If you want a browser for "geeks", then do as hixie suggested and change it in > your tree (or, recommend / propose / suggest a maintainer of a tree for "geeks" > to do so). The general user is more likely to need/want to do 'Save Page As' or 'Send Page' from the context menu (in the case where he happens to click on a text link, say) than he is to go back? What a very interesting fellow this general user must be.

It will be interesting to see which path the various distributions follow. I'm going to guess that while Netscape may be the largest distributer, it will be in a distinct minority in implementing this spec.

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

Slashdot discussion of this issue at http://slashdot.org/comments.pl?sid=32436&cid=3500584

The decision to not fix this bug is crazy. Since the majority of users browsing are only using the mouse to browse, and the most common task (besides clicking on links) is going back, the back item should be visible on every context menu. Otherwise thought train of the user is as follows o Okay I want to go back. o Right click o Oh! - why isn't the back option on this menu? I must have done something "wrong" o Let's try again o It's still not there! o Oh it was because I right clicked on an image. Let's try again. o It still didn't work - I clicked on a link o ... repeat ... Since this is the most used navigational feature - fix it! If you want to clean up the context menus, try right clicking on an image without a link. The context menu contains "bookmark this page", "save page as", "send page". Mad! I'm sorry this breakage is making me angry. Time to move to opera I suppose... Consistency is good, but you can't force your users to go through a ten second thought process every time they go back. If you force them to click on the back button or move the mouse and right-click, you're introducing RSI problems.

This whole thing is getting blowen out of proportion. Context menus are just that. They should only show info for that particular object. If you want an easy, non-keyboard way to navigate without having to go to the menu all the time. Then what you should really be look at is a gesture system (or something else if you can think of it). However. It's probably a good idea to have the 'back' commands there as an option for people who are in the habbit of using them.

"Context menus are just that. They should only show info for that particular object." Nobody cares what the right mouse button menu is called - "context", "global" or anything else. The function of the menu is important - primarily, to navigate. Only developers of the Web browser know or care what this menu internally is. The user only wants to right-click and see options for the *page* - because the user does not think in terms of Web layout; user does not know where what object is on the page. User deals with the page as a whole. This is why the Back menu item should be restored. Its absence is a MAJOR usability flaw, in its gravity only comparable to Evolution 1.0.4 not having an audio alarm on mail arrival...

I see frequent references here to a gesture system as a holy grail. I'm using the gesture component, and I wish I instead had the back button on the context menu. For starters, there's no good button to assign to mouse gestures. IMNSHO, overloading buttons is a much worse UI blunder than losing the perfect concept of the context menu in favor of convenience. There simply is no good button to assign to the gestures. The mere fact that there is a preference to select the button is proof of this fact. When assigned to the primary button, it interferes with selection. I've found the "solution" of gestures cancelling after a delay to be confusing and unsatisfactory. When assigned to the secondary button, the context menus sometimes pop up when I gesture, sometimes not. (Presumably when I don't move the mouse quite fast enough initially.) Some machines don't even have a tertiary button. Others, like mine, have a scroll wheel that is awkward to drag. I can't think of any other user interface that requires a tertiary-drag, for good reason. Also, the tertiary click is taken as well - it navigates to the URL held in the clipboard. It's confusing to have that happen if I don't move the mouse quite far enough for it to register as a drag. I also can't think of any other interface that has such a radically different action happen if you click instead of dragging. In most cases, a single-click instead of a drag would do nothing. Unless someone can come up with a good solution to this problem, I don't think I (and others) will ever be happy with the gesture solution. I was happy with the context menus, when they consistently contained "Back" and "Forward" as the first and second items. If clutter is a concern, I have never used the "Bookmark", "Send", or "Save" options. Comments here indicate that others use them rarely, if at all.

Save and Bookmark get a lot of use. We should keep Save and Bookmark, dump Send (from the context menu), and restore back. (I'd also like to see forward, but hey, whatever.)

Having "bookmark this page" on the "context menu" for an image, but not the far more common operation "back", makes no sense to me. I'm voting for a return of at least "back", perhaps "forward" on all or most of the right-button menus. But don't bother including less frequent stuff like "reload", "stop", etc. everywhere, when it would crowd out more interesting context-sensitive choices.

Argh. The transparent gif issue with this bug is the most annoying thing. Would it be possible to at least bring back the navigation options when the bit of the page one happens to click on turns out to contain an invisible image? Is it worth making a separate RFE bug for that?

http://linux.ee/~duke/transp - just a simple web page with a few paragraphs of text. And no matter where I right click on the web page, I don't get "Back" (or "Forward") in the context menu. It's rather stupid dirty trick really (as you will learn if you look at the source), but still, I my opionion this demonstrates that "context menu" in the web browser cannot be just that, because objects can be invisible or stacked on top of each other. I can only speak for myself of course, but if I surf the web, I do not want to figure out how the (possibly rather complex) web page is built, so that I can find a spot on the page where the "Back" option in the context menu is available. It is a tad annoying, if it's not there and I'm forced to move the mouse all the way back to the top of the browser window. And yes, I suppose I could go and patch my copy of Mozilla so that it works as I am used to, after all I do have the source.

Bamm filed bug 144912 for "Transparent images should have the same context menu as the page."

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

w/r/t the comments about including navigation commands in the context menu on transparent images -- what if the image isn't transparent, but is instead the same color as your background? You run into the same problem, and of course the solution is easy... I always thought that a core principal of good UI design was to avoid making the user perform a context switch. In a page consisting entirely or even mostly of images, someone who is only navigating with the mouse is faced with the following options when they want to return to the previous page: (1) Mouse across a (possibly large) screen to the "back" button at the top of the browser, (2) Move from the mouse to the keyboard -- a solution that may also involve moving from one hand to two (one for the modifier, one for the arrow). Neither of these solutions is ideal. A better solution would be to include, minimally, a "Back" (and maybe a "Forward") menu item in every context menu, on the theory that these two actions are always in context.

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

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

Okay, so if this is going to stay "wontfix", then does anyone know of a vendor that has some linux bin's of mozilla 1.0 that has "back" in all contexts? Please! Ximian, help us! Whoops? Did someone say "Fork"? I'd hate to have this conversation come to four letter words.

The notion that Mozilla-as-Mozilla won't be widely distributed, and for that reason it is unnecessary to be concerned about making intelligent user interface choices (since the vendors will be able to patch things up) is a false one. Mozilla is an Open Source poster child, and there's little incentive to go to the effort of producing a forked version when most users will be clamoring for "the real thing". Debate about this is off topic (you can e-mail me if you want to argue), but the basic point is relevant. I believe that time will demostrate that I am correct, and I hope that eventually this issue will be revisited and fixed. That's why my vote is staying on this bug even though it has been verified wontfix.

Yeah. What's particularly galling about this bug is the aspects of it that just obviate any of the justification for keeping back/forward off of images. Bring up a gif, jpg, or png file in the browser solo.. no html file, and what do you have in the context menu? View Image Block Images from this server Copy Image Location ------------------------- Save Image As Send Image.. Bookmark This Page Save Page As Send Page Properties Of these, View Image, Save Page As, and Send Page are clearly redundant/useless. More than enough space to put Back and Forward back in. Perhaps another bug could be opened on this? It seems that this bug has gained a response of 'no way, this is writ, no discussion necessary', despite obvious misfeature aspects.

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

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

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

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

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

So how about the "prefs.js" file have an option that power-users (e.g., very experienced browsers like myself and many others here who use the back on right-click-menu 3 times a minute (that's about my average as well, sometimes in photo-album hopping i hit 30 times)) can turn on that's something like "back menu item always present". That way, those who want back there under all circumstances can have it, and those that don't (or are new to browsers except IE which already has no back item except in specific circumstances) can just be happy and content with having harder navigation. This is a user-preference problem, not a "we dictate how the world browsers and we're gonna do it just like that _other_ browser" problem. User preferences should be just that, preferences that can be set. sheesh, why are things like this always all or nothing?

Joseph -- see comment #57, at which point I created bug #136665 suggesting there be a pref for this, which was shot down by mozilla developers and heavily mocked in their weblogs.

the file you will need to edit in order to have them back is chrome/comm.jar:/content/communicator/nsContextMenu.js unpack with jar or zip, then start editing. search for "context-back", "context-forward", etc and edit the conditions for showing this button to resemble this.showItem( "context-back", !( this.onLink || this.onTextInput ) ); this is just my preference, but it should suffice as an example. then, update this file in the archive. if you require back at the top of the menu, you'll need to edit contentAreaContextOverlay.xul as well, contained in the same directory. it's an acceptable workaround, you'll probably be testing less nightlies with this post-install procedure.

Just to add to Lars' comment, I posted a patch to mozillazine some time ago that does that. You can find it at: http://www.mozillazine.org/talkback/read.php?f=3&i=1236&t=1236 It is a bit of a hassle to patch with each new nightly, and simply copying the old comm.jar is dangerous.

This document is a rough "Howto" guide to taking the solution to the problem into your own hands. This bug had enough comments to me that I felt that the specification of Mozilla was in error. This is a DIY guide to fixing the problem yourself. Hopefully it's right, as it was written a while ago.

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

Ok... I'm hoppig on the bandwagon a little late... I can't beleive this has been marked WONTFIX ?! That's insane... there should be at least an option to enable/disable it at will. Mozilla has had my strong support until now but this is probably the most annoying issue I have with Mozilla and it's been scrubbed by the powers that be?

Re: Comment #157 From Steve Brecht 2002-09-09 08:56 Steve, this comment I'm writing is Comment #158, which usually means that a bug has been discussed to death. Adding another comment that doesn't differ from many others in any way does not help. > Ok... I'm hoppig on the bandwagon a little late... Yes. > I can't beleive this has been marked WONTFIX ?! The first ~40 comments should sufficiently explain the reason. The person who wontfix'ed it was hixie; tor reopened it, but hixie wontfix'ed it again. And I agree to that, for reasons I've described already. And I know that this reply comes way too late, but: Re: Comment #18 From Matthew Miller 2002-04-07 09:42 > Sören -- by that logic, the "back" button (and other full-page related > choices) should never be on the context menu. After all, you're never actually > clicking on the whole page -- you're clicking on some text, or an image, or a > link, or the background of the page, or some whitespace. When I would want to go back through a context menu, I would right-click on the *background* of the page. And the background of the page, is, by CSS's definition, part of the whole page body (AFAIK, in HTML up to 4.01, it may even be part of the whole HTML). So, the context of the background is the page, and it's the page which you want to change. Makes sense, doesn't it? Back to comment #157 ... > That's insane... there should be at least an option to > enable/disable it at will. Mozilla has had my strong support until now but > this is probably the most annoying issue I have with Mozilla and it's been > scrubbed by the powers that be? I cannot believe that you consider the lack of a menu item where it doesn't belong (and hasn't ever been present in the browser that 99% of the market use - or missed by its users, even) *the* definite Usability issue of Mozilla. Not that I care much, really.

In response to Steve's bandwagon-hopping, I must say I've never really been happy about the fact that this bug is marked WONTFIX. I continue using Mozilla because it is better-featured in many ways and because I want to support free software, but I have always considered this one of the major annoyances of using Mozilla, simply because this interferes with one of my long-established browsing habits. I don't think the issue was resolved. I don't think that the reasons given, which to me appear to be obscure reasoning based on standards, answers many of the concerns given, the most important of which is the tremendous demand from users for the context menus to be changed, but also other issues such as the frequent inability to distinguish background whitespace from images, which severely hampers navigating for people who prefer this form of navigation on MANY web pages. If this change won't be made, at the LEAST some of these issues should be addressed. Otherwise what the heck are we giving our feedback for?

More comments... >> Sören -- by that logic, the "back" button (and other full-page related >> choices) should never be on the context menu. After all, you're never actually >> clicking on the whole page -- you're clicking on some text, or an image, or a >> link, or the background of the page, or some whitespace. >When I would want to go back through a context menu, I would right-click on the >*background* of the page. And the background of the page, is, by CSS's >definition, part of the whole page body (AFAIK, in HTML up to 4.01, it may even >be part of the whole HTML). So, the context of the background is the page, and >it's the page which you want to change. Makes sense, doesn't it? So how come when I right click on the background of a page when text is selected I don't get "Back" as an option by your logic? And what about links to an image that is larger than your browser window... hence it's difficult to find whitespace to click on? I'm not sure the logic that it wasn't missed by IE users is valid since they never experienced it. Mozilla is supposed to be the next generation browser for all browsers... and users that have had this feature miss it.

Re: Comment #160 From Steve Brecht 2002-09-09 10:06 > More comments... Yay. > So how come when I right click on the background of a page when text is > selected I don't get "Back" as an option by your logic? Hmm interesting. This is not the case in Chimera, but indeed the case in Mozilla - I just tested it. I'd call that a bug. But if you read the summary here carefully, you'll notice that it's another bug. > And what about links to an image that is larger than your browser window... > hence it's difficult to find whitespace to click on? Tech Evangelism. A page that consists of a pure image is not a page... An exception is you point Mozilla to an image URL itself. In that case, I'm not sure... then again, a browser is not mainly an image viewer. > I'm not sure the logic that it wasn't missed by IE users is valid since they > never experienced it. Right, they always experienced a UI that is quite a lot tidier than that of Mozilla. > Mozilla is supposed to be the next generation browser for > all browsers... and users that have had this feature miss it. If "next generation browser" means "browser with all sorts of pointless features here and there" to you, I recommend Opera to you. As to Mozilla, I don't want that mess to be duplicated.

Forgive me for posting again... just more thoughts. As a full time developer I try to think like users think when working on my apps. In my opinion most users view a web page as a complete entity. We as developers know that it is a collection of text, images, and other objects... and as such some might see the logic in applying a context menu only to that object. I don't think the average user is that savy though... they see a web page as a complete item... like a sheet of paper. I know it would confuse the heck out of a lot of my users when text was selected that they don't get a "Back" option... or if they right click on a picture. Maybe this is hard to accept by experienced developers... but I think it makes sense on a convenience level too. When using a browser I am always dealing with both the sub items on a page and the whole page itself. I should have options to work with both. Again... just my thoughts... I don't want to stir up a can of worms. But I do strongly feel this deserves to be reconsidered. Will it stop me from using Mozilla? Of course not... will I still mutter about it under my breath... yep :) I find it annoying... and it seems I'm not alone. ok... I'll shut up now :)

>> And what about links to an image that is larger than your browser window... >> hence it's difficult to find whitespace to click on? > Tech Evangelism. A page that consists of a pure image is not a page... In other words, a geeky fixation on extreme sub-categorization trumps usabilty. See comment #40.

The missing back function is bad design and impedes usability. To argue that the space used up by the additional entry in the context menu is worse than the benefit of a consistent menu and of finding a function where it is expected is just absurd. There are situations where a large or all of a html page is occupied by an image and in that cases the functionality is missing badly and 90% of the users will just wonder why they cannot do what they are used to be able to do elsewhere. Please, swallow your pride and maybe listen to the people who actually want to use Mozilla.

Hi, I have two comments: First, I really think it was a bad idea to remove the navigational commands from the context menu. They were by far the most convenient way of getting around. Keyboard shortcuts don't necessarily work, depending on where keyboard focus is on a page, and the button bar is pretty far from the middle of the page on my browser. As for this "click on a non-special area to get those commands" business... it's the -web designers- who know what the special areas are. Users like me expect the common commands to be close at hand all the time. There have been a number of irritating scenarios that have turned up for me personally: - Using the "find" command on the page, then attempting right-click-back (but since "find" selects the matching text, that doesn't work) - Attempting navigation over a "special" area that's well-integrated with the rest of the page (frankly, I regard the whole page as a unit. That's how most pages are designed, anyway) Anyway, I really wish the Mozilla UI folks would reconsider this, and at least put back "back" and "forward". My other comment: I used the HOWTO to put these commands back into the context menu (at least until next time I upgrade Mozilla... <sigh>) but there's an error there: where it says to enter "TRUE" in the javascript, it should actually read "true".

Somebody mentioned that this behaviour is actually specified in the context menu specification - so I opened bug 164440 on it. Maybe going that way works.

This bug is already too long, but the comments I'm about to make are for the purpose of explaining how to keep future bugs from becomming similarly long. In short: rather than marking something like this WONTFIX in the future, dupe it against a (futured nobody@mozilla.org) bug for either an XPI or a pref. That will save you from 100+ angry comments (and more still rolling in). Explanation follows: This bug is a symptom of a larger problem. Duping this bug against a bug calling for the ability to customize more things, rather than marking it as WONTFIX, would probably have resulted in less argument. Here's why... There are three basic types of users: end users, power users, and developers. End users are irrelevant to this bug, because they don't understand context menus in the first place. For similar reasons, end users are irrelevant to most of the high-argument bugs. Developers do things like hack the XML to fix it themselves. This bug then is about what power users want... The problem is, power users are highly opinionated, develop habbits that other people consider unusual, consider those habbits superior, and _want_ things the way they want them. (Hence, the people loudly arguing that this is bad design, that back is the most important item in any context menu, that the spec is wrong, and so on. Those people are behaving as typical power users.) But they don't all have the _same_ weird habbits and preferences and therefore will never all agree on how something should be. I, for example, cannot imagine using the context menus for back (much less forward/reload/stop, which I never use at _all_), but feel strongly that the first item on any link context menu should be New Tab, and on a non-link image should be View Image. Most power users have strong opinions about such things. The real issue here is, power users want to be able to custimise _everything_, including the layout and arrangement of the menus -- all the menus, including the context menus. When they can't customize, they have loud stupid flamewars like the one in this bug. If you tell them, "Go to the prefs panel, under Advanced, under Really Advanced, hit the Customize Context Menus button, then navigate to Images and choose Not Linked, then hit Add and select Back from the Navigation area, then use the arrows to move that to the top. Do the same thing for linked images", they stop arguing and tell you how really wonderful the product is. Yes, really. The other argument-preventative resolution for this bug would have been to dupe it against a bug for creation of an XPI that restores the items in question. Power users don't mind installing add-on components; it makes them feel like they're getting extra functionality, and they like that. > Have you seen the number of prefs we already have? And you want to add more?! Yes, but that's another bug, and nothing further needs to be said about it here.

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

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

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

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