64749 - [mac only] Add point "Open link" to context menu when right-clicking on a link.

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement, P2)

Description

[Mark Slater]

Currently, right-clicking on a link opens a context menu. As it is right now, it
only offers the ability to open the link in a new window, amongst other things.
That menu should also offer the ability to open the link in the current browser
window.

Comment 1

[R.K.Aa.]

A menuitem like you suggest has never been implemented in mozilla, nor in NC
4.*, so this is not a bug but a feature request.

I suggest it be marked WONTFIX, since it would be reduntand bloat: Users who
want to open a link in current window simply left-click on it.

Comment 2

[Mark Slater]

Sorry, yes should've been enhancement. I still think it would be nice, though :-)

Comment 3

[Matthias Versen [:Matti]]

I find, it´s easy to left click and I don´t understand why this should be in the
context menu.

This should be marked as wontfix

Comment 4

[Matthew T (active 1999-2002)]

Yes, `Open' should be in the context menu, and should be the `default item' 
(bug 37596) for the menu.

Such an item is present in 4.x for Mac OS, and in Internet Explorer for Windows 
(and probably IE for Mac OS too).

Comment 5

[sairuh (rarely reading bugmail)]

i'd also recommend wontfix.

Comment 6

[Matthew T (active 1999-2002)]

It is convention on both Windows and Mac OS to include, in the context menu for 
an object, an item which does the same thing as single-clicking or
double-clicking the object does. It is also convention in Windows generally, and 
in 4.x for Mac OS, to make this item the default item in the context menu -- this 
provides a convenient but unobtrusive way of asking the question `what would 
happen if I clicked here?'.

Comment 7

[Keyser Sose]

Adding ui keyword.

Triaging the Most doomed (which Happens to Ben right now :)

Comment 8

[Blake Ross]

-> me

Comment 9

[Blake Ross]

Waiting on context menu spec in 75338.  I somewhat strongly object to placing 
this item first in the menu, although it's first in IE and I never seem to 
mind...

Comment 10

[Jesse Ruderman]

I agree with Blake: on Windows and Linux, putting "Open" at the top would make 
the "Open Link in New Window" context-menu-gesture harder to get right.

Comment 11

[Blake Ross]

Waiting for the context menu spec, so letting this slip.

Comment 12

[Jesse Ruderman]

See also bug 86649, "Personal toolbar bookmark folder context menu should not
contain Expand".  It doesn't always make sense to include the default option on
a context menu.

Comment 13

[Alex Bishop]

Adding myself to CC list. I don't really care either way, but we should be
consistent. At the moment, context menus for bookmarks have the default action
(Open) in them, but no other menus (that I've come across) do.

Comment 14

[Tim Powell]

Recommend wontfix. Adding Open to the context menu is bloat because there's no
reason not to simply use a regular click. The default action should not be in
the context menu if it is accessed by a single click. 4.x (windows) has always
had Open in New Window as the first context menu item. Changing this to not be
the first item will be horrible as it is by far my most used link context menu
item and speed of access here is a serious concern. If mac does it differently,
then this should be pp.

Comment 15

[Blake Ross]

I do not believe this is worthwhile.  Marking wontfix.

Comment 16

[sairuh (rarely reading bugmail)]

v

Comment 17

[Boris Zbarsky [:bzbarsky]]

Reopening.  This will lead to terrible usability on Mac.  Consider:

1)  You click on a link to just follow it
2)  You hold just a tad too long
3)  The context menu comes up
4)  You get the link in a new window or something like that instead of what you
    actually wanted.

This is usually not a problem on Unix and Windows which don't do context menus
on click-hold.  Blake, please reconsider in light of this glaring UI problem.

Making this mac-only and pp if people object to it on the other platforms, but
on the Mac this really is necessary.

Comment 18

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The context menu for an item should have the default action (e.g. the action
that occurs when you click) highlighted in bold, usually at the top of the
context menu. This is a Windows UI standard. I think the Mac has such a standard
as well.

Comment 19

[Andrew Thompson]

BZ has the strongest point of all those above. Remember on Mac OS we wait for a
small amount of time then post the contextual menu if the user doesn't move the
mouse. This is a real boon to those with only one mouse button.

Here's a brief history lesson / some perspective:

On Mac OS 9 (whether these are good or bad I'm not saying, I'm just defining):

Contextual menus never have greyed out items, nor do them have Bold items
Contextual menus always have "Help" as the first item
Contextual menus appear on Mouse Down, not Mouse Up as in Windows
Contextual menus appear with the first item inline with the mouse pointer, but
to the right and they hang down from there [*]
On 9 only, they don't mind being clipped by the edge of the screen, autoscroll
arrows solve the problem

[*] is the most important. This means if one posts a menu on Mouse Down, then
simply release the mouse pointer without moving it, nothing happens. The menu
remains on screen and the user can choose an option or click elsewhere. It
requires a slight movement to the right to select an opton (which would usually
be Help). Cuts down on errors.

Nav 4 always ignored all of this on Mac OS
It posted menus if you clicked and held the pointer down (non standard, but 3.X
actually predated the standard Apple implementation anyhow)
It posted the menu with the default option under the cursor, so if you hold down
then let go it *is* activated.
The default option wasn't necessarily the one at the top - the menu would adjust
where it posted itself such that what nav4's designes thought was the best
option for the context was under the cursor when the menu is drawn. Doesn't
matter if its the first, fifth, eigth item.

So for a link in Nav 4 the default item was "Open This Link" which solves the
accidental context menu activation problem by doing the same things as a "left"
click (omagine you only have one mouse button)

Mozilla behaves like this (at least with Modern on OS x / Fizilla)

If the menu will fit on the screen, the pointer *almost* appears in the standard
Mac OS place (ie, just off the top right of the first item in the menu) - in
reality it should be half way down the side of the first item.

If the  menu isn't going to fit on the screen, it moves the menu up or down
until it will, then displays it slighty to the right of the pointer.

Over a link, if one brings the menus  up and simply lets go, on misses the menu,
because  its offset to the right, and the event is delivered to the link below,
with a one button mouse its as if you clicked the link!

So: 


1/ QA contact: whatever these people decide to do you have to get this tested on
a Mac and make sure it doesn't do something *really* nasty like trigger an
unexpected action if the user holds the mouse down for a fraction too long.

2/ Nav 4 has the item on Mac OS, Windows IE I don't know, Mac IE doesn't have
the open item. I don't jhave a strong feeling except that in general its a good
idea for the reasons mpt gives. Question is whether we want to follow the
general rule...

3/ Context menus in Mozilla suck. They have all sorts of usability issues (like
what they do when too close to the edge of the screen, especially the right
edge. And there's that "event falling through to what's below" bug too. Who do
we cc: who would know if we have bugs on these issues?

Comment 20

[Alex Bishop]

> Nav 4 has the item on Mac OS, Windows IE I don't know, Mac IE doesn't have the
> open item.

Windows IE has 'Open' on link context menus. It appears at the top of the menu
in bold (i.e. it follows Windows conventions).

Comment 21

[Tim Powell]

This bug is now MAC only. I see no reason to change Windows. The convention 
that IE follows on Windows with context menus makes some sense in other parts 
of the operating system where you have to double-click to load items. Adding it 
to the context menu for single-click items just wastes time. Because of this, 
and because Open in New Window is by far my most used item on the context menu, 
IE's context menus always feel clunky to me compared to Mozilla/Netscape. 
(Well, that and the silly names like copy shortcut and favorites, but now I'm 
ranting.)

So add it to the Mac. Leave other OSes alone, please.

Comment 22

[marlon bishop]

The reason i believe MS is doing this is to accommodate some beginning users
which in lab studies seem to not understand or distinguish the difference
between right or left clicking. specifically, some users tended to wander around
the entire time using the right button to click. Unfortunately, this default
menu items do make sense. if we want to follow those guidelines we would add the
default action to some menus which required them.. These would include any
object such as a link.

The other piece to this puzzle lies in the unofficial click and hold behavior
that we started doing on the mac. This makes it extremely easy to bring up a
contextual menu for any variety of users who's natural behavior seems to include
click-hold-and-ponder. Either you embrace what we started and place the default
action item under the cursor, or you elminate click and hold, and go with the
platform standard. The problem is that now, Netscape, Opera, and IE are doing
click and hold, and it would really upset users who depend on it if it were to
go missing. So i would have to argue that the default item belongs on the mac as
well.. One convention i don't really agree with is placing [help] as the topmost
item of every menu. as i am fairly certain it mostly happens in the OS.


i have posted the 2nd draft to the Context Menu Revision 2 document located:

http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-2.html

Comment 23

[Jesse Ruderman]

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

Comment 24

[Mark Bitterling]

As a Mac user, I do not understand why Mac users would want the default left
click option at the top of the context menu any more or less than a user of
another platform.

In regards to c#17 and c#22 :

Single button mouse Mac users do not "click-hold-and-ponder" because they know
that clicking and holding brings up the context menu. (Perhaps some Windows
users "click-hold-and-ponder" but I do not know what good it does them.)  I have
never known any Mac user to click and hold until the context menu pops up in
order to just open the link in the current window. As it is now though, if
someone did accidently hold for a bit too long and the context menu pops up, all
they have to do is let up on the mouse and click again to open in the current
window; they will not accidently open in new window unless they accidently hold
for too long AND then move their mouse over the context menu AND then let up (if
this happens very often for a specific user then the user is defective and is
probably have many similar issues with all of their software).

Nav 4 required the default click option on the context menu because the context
menu was displayed directly under the cursor; now that that has been corrected
by placing the context menu to the side of the cursor, the default click option
is no longer needed.

As for users who do not know the difference between right and left clicks, they
need to learn sometime.  There is no reason for Mozilla to facilitate their lack
of learning.

I strongly recommend WONTFIX.

If someone decides that this will be done then I strongly recommend that the
same be done for all platforms; I see no reason to single out Mac users alone to
have to suffer from having a pointless default click context menu item in the way.

Comment 25

[Andrei Boros]

In reply to the suggestions of WONTFIX : 

This feature is quite usefull in Netscape 3 as it _OVERRIDES_ target attribute 
of a link.

Left click on a link in a window with a target frame set will often open that 
link in another window if that window contains a frame with that name, instead 
of the current window. So left-click isn't always straightforward.

Comment 26

[Andrei Boros]

Attachment: Example of situation where "Open this link" would be a lot of help.

This image shows a Yahoo mailbox open. There are 2 browser windows. The first
one (hidden, left on the bar) contains the main Yahoo mail interface and I am
browsing a mail folder there. 
I opened another mail folder in a new window, then I opened a message, then I
forwarded that message. And I got to the window shown here. I want to get back
to the folder index where this message is, and the link for this is "fido"
which as you can see, it is marked.
Page in this window contains no frames. This link has a target property and
refers to a frame name present in the other browser window (not visible here,
the  yahoo mail main frame based interface).
If I click this link (simple left click), the URL of this link WILL OPEN IN THE
OTHER WINDOW, IN THE RESPECTIVE FRAME. As users sees it, left-click on link and
nothing happens. Change the browser window and you will find that the folder
"fido" is listed in the frame here, while the page you had here is lost (need
to press "Back" to get it.
This is confusing. I click on a link and nothing happens here. Another window
will fetch the URL instead of retaining it's contents.
I get a context menu and look at it. From what it contains, there is NO WAY to
open the link "fido" in _this_ window (never mind tabs). 
Either I let it open in another window where it finds a frame with a matching
name, or I have to open a new window for this exact link.

Before Yahoo moved its clubs to groups, the clubs interface was also frame
based.	If I opened let's say 3 clubs and open some pages in new windows then,
any click on a link in these windows would open in one of the pages with a
matching frame name, often even opened a page from one club in the frames of
another, increasing the confusion. While Yahoo clubs existed, I only browsed
them with Netscape 3 just because of this annoying behaviour.

This is why I request the addition of a menu entry "Open this link" to be able
to open a link in the same browser window (and tab for that matter) overriding
the target attribute of that link, if a frame with the the name targeted exists
in another window...

Comment 27

[Mark Bitterling]

Comment #26 seems to be requesting "Open this Link in THIS Window" which as I
understand it would be different than the "Open Link" item that most people have
been talking about here which would be the same as a left click.

Comment 28

[Andrei Boros]

To: Mark Bitterling
That's what I was trying to explain from the beginning. I said it repeatedly: it 
should override target attribute of the link (if exists)

Comment 29

[Jesse Ruderman]

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

Comment 30

[R.K.Aa.]

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

Comment 31

[Lee]

Why is this marked for mac ?

Comment 32

[Alex Bishop]

> Why is this marked for mac ?

See comment 17.

Comment 33

[Lee]

But I want this funtionality in PC also.

i.e, Force a link to open in same window, even if it is specified to open as a
new window.

http://bugzilla.mozilla.org/show_bug.cgi?id=145012.

Comment 34

[Boris Zbarsky [:bzbarsky]]

That's not what this bug is about... (that other bug is still a dup however,
just of a different bug).

Comment 35

[Jonas Jørgensen]

Lee: The bug about opening the page in the current window even if the page says
otherwise is bug 78037.

Comment 36

[Jesse Ruderman]

See also bug 133449, same bug but for all platforms rather than only Mac.

Comment 37

[Boris Zbarsky [:bzbarsky]]

See comment 34.  These two bugs are totally different. This was a request for
hte NS4 behavior of having a context menu item equivalent to simply clicking the
link, as far as I can tell...

Comment 38

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 39

[Mark Bitterling]

This bug is as valid for OS X as it is for Classic.

Comment 40

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 41

[Philip Chee]

After discussing this with our OSX expert (stefanh@inbox) this bug is WONTFIX.