Closed Bug 135331 Opened 22 years ago Closed 22 years ago

Context menus on images no longer includes back, forward

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: jonabbey, Assigned: marlon.bishop)

References

Details

Attachments

(1 file)

A HOWTO guide for restoring the "Back" context menu.
12.91 KB, text/html
Details 
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.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
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.
Assignee: mpt → blaker
Status: RESOLVED → NEW
Component: User Interface Design → XP Apps: GUI Features
Ever confirmed: true
OS: Linux → All
QA Contact: zach → paw
Hardware: PC → All
Gah, mid-air collision. Clearing resolution ...
Resolution: INVALID → ---
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.
Assignee: blaker → marlon
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
QA Contact: paw → sairuh
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."
Keywords: mozilla1.0, nsbeta1
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.
Keywords: mozilla1.0 → mozilla1.0+
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.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → 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?
Blocks: 136665
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.
No longer blocks: 136665
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?
Keywords: 4xp, regression
Reopening - technical discussion is still taking place, and we're going to
need a dup target.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Keywords: 4xp, regression
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → VERIFIED
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.
Blocks: majorbugs
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. ***
Product: Core → Mozilla Application Suite
No longer blocks: majorbugs
*** Bug 318269 has been marked as a duplicate of this bug. ***
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: