Closed
Bug 64749
Opened 24 years ago
Closed 13 years ago
[mac only] Add point "Open link" to context menu when right-clicking on a link.
Categories
(SeaMonkey :: UI Design, enhancement, P2)
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: mark.slater, Unassigned)
References
Details
(Keywords: platform-parity)
Attachments
(1 file)
(deleted),
image/gif
|
Details |
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.
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.
Reporter | ||
Comment 2•24 years ago
|
||
Sorry, yes should've been enhancement. I still think it would be nice, though :-)
Comment 3•24 years ago
|
||
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•24 years ago
|
||
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).
Assignee: asa → ben
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: GUI Features
Ever confirmed: true
Keywords: 4xp
OS: Windows NT → All
QA Contact: doronr → sairuh
Hardware: PC → All
Comment 6•24 years ago
|
||
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•24 years ago
|
||
Adding ui keyword. Triaging the Most doomed (which Happens to Ben right now :)
Keywords: ui
Comment 9•24 years ago
|
||
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...
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
Comment 10•24 years ago
|
||
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•24 years ago
|
||
Waiting for the context menu spec, so letting this slip.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla1.0
Comment 12•24 years ago
|
||
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•24 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
I do not believe this is worthwhile. Marking wontfix.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
![]() |
||
Comment 17•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
> 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•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 22•23 years ago
|
||
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 24•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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)
Updated•23 years ago
|
Hardware: All → Macintosh
Summary: Add point "Open link" to context menu when right-clicking on a link. → [mac only] Add point "Open link" to context menu when right-clicking on a link.
Comment 33•23 years ago
|
||
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•23 years ago
|
||
That's not what this bug is about... (that other bug is still a dup however, just of a different bug).
Comment 35•23 years ago
|
||
Lee: The bug about opening the page in the current window even if the page says otherwise is bug 78037.
![]() |
||
Comment 37•22 years ago
|
||
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•21 years ago
|
||
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".
Updated•21 years ago
|
OS: Mac System 9.x → MacOS X
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•18 years ago
|
Assignee: bross2 → guifeatures
Status: REOPENED → NEW
QA Contact: bugzilla
Comment 40•17 years ago
|
||
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
![]() |
||
Comment 41•13 years ago
|
||
After discussing this with our OSX expert (stefanh@inbox) this bug is WONTFIX.
Status: NEW → RESOLVED
Closed: 23 years ago → 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•