Wow. I used a nightly build for the first time in awhile today...our context menus are now as long as IE's, and, in some cases, longer. Matthew, can you please post the context menu spec you had somewhere? I won't be changing wording (probably) or adding new features under this bug, but rather, just working on showing/hiding/enabling/disabling items as is appropriate for each context.

Mine! I'll take this bug until I finish the spec for these context menus, and it's published on mozilla.org. Then the bug can be marked fixed, and various bugs can be filed for particular contexts. Such bugs could be fixed by Blake, Gerv, or anyone else in the UI hit squad. Unfortunately, context menus are not a movable feast. It's not good if we get the context menus mostly right now, and then add/remove items from them later, as that will continue to disrupt the muscle memory of those people who rely on the context menus for quick access to features. So we *may* need to add items which are disabled because they're not yet implemented. I am now onto the third draft of my context menu spec, which is quite different from the first draft I posted earlier. I'm just dealing with context menus in the content area, for now -- in particular, those for: * HTML form controls * page * frame/iframe * mailto: link * link for protocol other than mailto: * image * image link To those arriving from the bugs which I've marked as depending on this bug: it is, of course, possible for those bugs to be fixed without this bug being fixed. However, after the design is finalized, such bug-fixes may be rendered irrelevant by the renaming or complete removal of the relevant item. So you may want to spend your bug-fixing time doing something else instead. :-)

adding bug 73322 -- "[rfe] Image resize" to depends list.

mpt: please post your spec to the ui newsgroup before posting it on the mozilla.org website.

Yes of course.

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

CCing self in anticipation of getting some work to do. This is about the only code in Mozilla that I currently feel happy working with :-) Gerv

Adding dependency on bug 73847 -- being able to tell the document's mime type from chrome. That would allow us to do a different context menu for image URLs

ping pong. Any hope for this soon?

An old version of mpt's spec is attached to bug 26939 as attachment 20873 [details].

We really need to tidy up the contextmenus some before 1.0 Mpt, what's the status on the spec?

<shudder>. I'm working on a couple of bugs to get mail context menus up to jgclick's published spec, and have a couple of patches waiting. mpt: we need to know how much of the currect spec will be superceded asap, I don't want days (weeks!) of work to be driven over :).

I am an end user of Mozilla and the one feature I truly liked about netscape and miss in IE is the Send Page option. There have been many occassions when I have sent an article, a technical page, an rfc, some document to either myself or a friend by using the context menu's "Send Page" entry. If you look at everything from a developer perspective, why include features like Ctrl+L to select the text in the location bar, you had might as well press Tab till you get to the location bar. As developers, we create products for end users and the reason why IE is ahead of Mozilla is that it makes products for the lowest common denominator, for a newbie user. If netscape/mozilla is to ever climb back up the "charts", it has to be good enough to make people want to download it, make them feel that Mozilla gives them a better browsing experience...

*sigh* ... Sorry about the double attachment, apparently it was a Bugzilla-wide slowdown which made Mozilla time out the first time. Anyway. Priorities for this design: 1. Keep the menu short. In this design there are from 8 to 13 items in each menu, depending on the context. In comparison, Mozilla currently has from 13 to *26* items in each menu, depending on the context. 2. Keep the menus as consistent as possible between contexts. The most noticable manifestation of this is that for a non-link image, the link-specific items are dimmed but still present; this is because it is often not obvious whether a particular image is a link or not. 3. Follow a general two-part structure. The first two items in each menu are for quick gestural navigation, and for indicating what an ordinary click would do. The rest of the menu concentrates on items specific to the context. Tasks remaining: * Finish the `Folder/Group' and `Message in thread pane' context menus. * Add accesskeys. * Discuss with Jennifer Glick whether she wants the mail/news context menus to have consistent structure with Navigator, or to retain the structure in <http://mozilla.org/mailnews/specs/threepane/MailMenus.html#standalone>.

Right. I'm happy to make a patch for this, if I can be reassured that there won't be months of argument between People Who Matter (mpt, blake, ben, german, jglick etc.) after it's completed. How would you like to do it? One mammoth patch? One for each context menu? A patch that does all the easy stuff first, quickly, then work on the rest as we have time? Gerv

Comments: Navigator: Frame content area ------------------ If you have a frameset, you can't bookmark or save the entire frameset from the context menu, because whichever frame you are in, you will always get a frame-specific context menu. Would it not be reasonable to require people, if they want to bookmark or save a particular frame in a frameset, to View Only This Frame it, or Open it in New Window first? This would simplify things. In a similar vein, why do you need "File Bookmark For Link"? Why not click on the link and then File Bookmark? Image ----- Copy Link Address, Save Link, File Bookmark for Link and Link Properties should not be in this menu, as you aren't clicking on a link. Why both Link Properties and Image Properties? The current Properties window does all the relevant properties in the same window, so both menu items would do the same thing. As I understand it, this isn't going to change. * in internal link ------------------ Please explain this [Open Link | Submit Form] business. Image in * link ---------------- I thought we decided to kill "Save Image" in favour of View Only This Image and then Save As...? What's the point of "Hide Image"? I understand Show Image. Text field ---------- How about Redo? Why not "Change Text Direction" instead of Left To Right and Right To Left (which, I assume, is a radiogroup.) Text in mailto: link -------------------- You've forgotten "Copy Email Address". You don't want "File Bookmark For Link", surely? Bookmarking a mailto link is a bit strange. I suppose bookmarking a news:// link makes sense, but mailto: seems odd. And "Save Link As..." makes no sense either. (Sidenote: We want to disable Save Link As and probably File Bookmark For Link for news:// links which refer to a newsgroup or server rather than a message. We could also change Open Discussion to Open Message.) Gerv

My responses to some of Gerv's comments: "In a similar vein, why do you need 'File Bookmark For Link'? Why not click on the link and then File Bookmark?" We've had this function (previously called 'Bookmark this Link' - which I think is better wording) for ages. It's useful if you want to visit a link, but not now. It's also handy if the server's down: you can bookmark the link and try again later (without the menu item it would be impossible to bookmark the link). "I thought we decided to kill 'Save Image' in favour of View Only This Image and then Save As...?" IMHO this would be a bad idea. Pretty much the only reason I ever call up the image context menu is to save the image. I don't want to go through the hassle of viewing the image and then saving it. Also, inexperienced users probably wouldn't twig this. Almost all Web browsers have save image functionality in the context menus. It would be breaking existing conventions (I bet nearly all generic Web browser guides mention it). These are just my immediate thoughts. I'll probably have other, better-developed comments in the future.

Hope no one minds my 2 cents: 'Why not "Change Text Direction" instead of Left To Right and Right To Left (which, I assume, is a radiogroup.)' One problem with "Change Text Direction" is that it doesn't tell you which way the text is rendered right now. Although mpt's suggestion uses 2 menu items, it would be clearer. One other comment is: if there is ever going to be help/hint text on the status bar, does that text need to be planned out now? Otherwise, the next context menus seem much better.

Why is reload after page properties? normally properties is the *last* item in a context menu. File Bookmark for Frame is more awkward than most bad text i've seen in mozilla. Bookmark Frame ... while not in the style of the spec you supplied sounds much better. what's the reason to say View instead of Show in ... only this Frame? Again, the string Verb only this Object sounds really awkward. Send E-mail is less accurate than Compose E-mail, but in my style I'd just say E-mail ... Send E-_mail ... <comments above Add t_o Address Book ... <do you have some reason that t isn't good enough? _Copy Copy Link _Address <you could use L if you wanted to give A to Add which would be nice. _Save Link As ... <what does it mean to save an email link? perhaps you mean Save As _VCard ... File _Bookmark for Link ... <what's the purpose of bookmarking an email address? Link Propert_ies vv P_roperties when possible and prefered. any other usage is guaranteed to confuse windows users like me who expect that the accesskey be the r. for my convenience since it took 2 google searches: http://msdn.microsoft.com/library/books/winguide/appxb.htm. I'd like responses to these questions before I continue. Warner: change text direction for now is just inconsistent w/ what eveyone expects and would require us to consult bidi people which will further delay this work (poor gerv) fwiw, there was a browser or metaphore that used 'Follow Link' which actually makes more sense than Open Link, does anyone here like it?

"Reload" should be where it is now: after "Back" and "Forward". Yes, "properties" should be the last item. How about "Bookmark this Frame"? View vs Show this Frame - we need to decide if the user is *actively* giving commands ("Show" me this, "DO" that), or *passively* "Viewing" or "Following". I personally like the active posture as a user. While I'm sitting on my but, the illusion of "doing" something is somehow less guilt-feeling-inducing ;) Don't use the word "object", it could mean anything or nothing to most users. "A" should be for Address Book, "B" for Bookmark Like "follow link"? - No, "Open link" is better. People don't want to "passivly" follow things, they are "doing" things (see comment above on "view" vs "show"). We (regular users) really need an "E-mail this page" for web pages.

Regarding separate "{image|link} properties" I think we could bring up the Page- info window and bring up the {image|link} tab with the selected {image|link} shown. So I think it's a good idea. However I do miss some item to bring up the properties window for stuff other then links and images. It would also be nice to be able to bring up "form properties" for form- elements which would work as I described for {image|link}s

Let's not get offtopic with feature requests now.

[ This comment is also posted in the newsgroup; please continue discussion there, as I can see this is going to be a long one. :-) ] "In a similar vein, why do you need 'File Bookmark For Link'? Why not click on the link and then File Bookmark?" Yeah, sorry, forget this comment. "One problem with "Change Text Direction" is that it doesn't tell you which way the text is rendered right now." When would you use "Change Text Direction"? When the text wasn't in the correct direction, which you could tell by inspection. As there are only two possibilities, and the current one is the wrong one, you only need one menu item. Say you have both. In that case, one of the two menu items will _always_ do nothing - and IIRC mpt doesn't like menu items which do nothing. "We (regular users) really need an "E-mail this page" for web pages." Anyone who emails random web pages to anyone else should be shot. Well, that's a bit strong, but it's context menu items like "Email this page" which lead to me having to take half an hour to download netscape.public.mozilla.reviewers on my 56k because half of the review requests have the entire bug web page attached needlessly. This is what _links_ are for. Why would you ever want to email anyone a web page when you could mail them a link? I doubt there's a significant number of people who have email access but not web access any more. "... bring up the {image|link} tab with the selected {image|link} shown." Yes, we could, but is it really worth an extra menu item? We could make it so that if there's an image link, both were selected when you first tabbed to that tab, if you see what I mean. If you go down this route, why not "Security Properties" on any https:// page and "Form Properties" on any form, and so on? Oh. You suggested that. But this is getting silly. We are trying to avoid multiple menu items, and having three or four which take you to different tabs of the same window seems like redundancy to me. Gerv

Responses to MPT's reponses: >> (previously called 'Bookmark this Link' - which I think is better wording) > > Unlike the `Bookmark this Link' of old, `File Bookmark {} ...' opens the File > Bookmark dialog. I think indicating the distinction is important. I knew about the change in how bookmarking links works, but I still prefer the old wording. I think it sounds better and it also takes advantage of the fact that 'bookmark' can be both a noun and a verb. If the item was 'Bookmark this Link...' (note the ellipsis), most users would realise that the command calls up a dialogue. (Those that don't would figure it out the first time they use the item!) I can see the advantages of "File Bookmark for Link..." though so I don't really mind one way or the other. > What accesskeys does MSIE for Windows have for Link Properties and Image > Properties in the same context menu? Surely not both `r'. Actually, IE only has one 'Properties' menu item. When on a blank bit of page it shows page properties; when on an image, image properties; when on a link, link properties; and when on an image that is also a link, image properties (there appears to be no way to access the link properties in this case).

> Windows text controls (which don't have `Undo' either). Actually, Windows 98 and Windows 2000 both have 'Undo' as the top item. I do agree w/the resoning in that paragraph, however (Redo isn't needed). >> Why not "Change Text Direction" instead of Left To Right and Right To Left > usability gain *is* greater than the usability loss Not for me. I have no use for Right-to-Left text so that item is something I'll aways be flying over (and if there's two of them, I'll be flying farther). >> You've forgotten "Copy Email Address". > No I hadn't. Does that mean it's there but not obvious (which is a problem) or you don't plan on including it. If it's that later, than hopefully your mind can be changed. That is the one context item I've fallen in love with. Sure, it's possible to copy the entire link, paste it into the box, go to the begining of the text you just pasted and hit delete 7 times, but that's a lot more work than selecting Copy e-mail address from the context menu and then pasting it (and I do that semi-frequently when cc'ing somebody on a bug or giving somebody credit in a check-in comment). >> Bookmarking a mailto link is a bit strange. > Firstly, it's present for all other browsers I've tried. I guess it is, but I personally agree that it really shouldn't be. Address books are for holding e-mail addresses, not bookmarks (but that is just IMHO). > `File Bookmark {} ...' opens the File Bookmark dialog. I agree with this wording because it's the one used in the Bookmarks menu. If a different wording is used here, it should be changed there also. > *sigh* ... I know. and in most of these menus, it is. However, I judged that > keeping it in a constant position in the other menus was more important than > making it the last item in those menus. I disagree here. I often right-click on something and fly to the last menu item, barely even paying attention to what I'm doing, when I want to see the properties of somthing. I think maintaining that consitancy is far more important than specifying what type of properties your going to. In the case where an image is a link, I think it should go to the Image properties with another tab for link properties. I'd also be in favor of not specifying the Properties type in the context menu. > What accesskeys does MSIE for Windows have for Link Properties and Image > Properties in the same context menu? Surely not both `r'. I don't think I've ever seen two different "Properties" items in the same context menu in IE. FWIW, IE 5.5 on Win2k has 'P' for the access key (and 'R' is "Refresh"). But other places in Windows, (such as the desktop) 'r' is the access key (maybe we shouldn't look to Microsoft for consistancy :). >> We (regular users) really need an "E-mail this page" for web pages. > Nope. It's neither contextual nor extremely common. I agree, for the most part. The one time I can think of this being useful is where you submit some information and get a page with what you submitted (and possibly a confirmation number on it) and don't either have a printer handy or want to print the information. It would then be useful to be able to send the page (as retrieved from cache) to yourself (possibly at another address than where your are) or somebody else. But really doesn't warrent a context menu, so I guess it's not applicable to this bug...

Not quite sure why you attached your comments, but anyway... There's still no way to bookmark a frameset (i.e. the equivalent of File Bookmark... when you right click somewhere in a frameset.) > it's more important that the > position of the items is consistent than that all of the items are enabled. How does your spec indicate when items are disabled? > > The current Properties window does all the relevant properties in the same > > window > > That's a bug. :-) Well, that's an argument for another bug, but until it gets fixed (or not) any patch that gets produced will have a single Properties menu item. > Because for an either/or toggle (such as text direction), rather than an > on/off toggle, radio items are much more understandable than checkmark items, Change Text Direction would not be a checkmark item. It would merely change the direction of the text in the textbox. When would a user want to change the text direction? When it looked wrong. So a menu item to change it to the right way (which it would) is what you want. Your scheme _always_ has one redudant menu item. Everyone wants Copy Email Address. It's very popular. Please leave it in. Gerv

Can you explain the difference between an "internal link" and an "outbound link"? I don't like having Reload at the bottom. It just looks out of place there. Muscle memory is only useful for the first few items on the context menu; after that it becomes "click the last item on the context menu" or "click the first item after the first separator". >`Save Page As ...' isn't really worth a context menu item; it's >included for consistency with `Save Frame As ...', not the other way around. Not many pages use frames. Do we really want to change the default context menu just so it's consistent with the frame context menu? >> Copy Link Address, Save Link, File Bookmark for Link and Link Properties >> should not be in this [image] menu, as you aren't clicking on a link. >Please re-read point 2 in my 2001-07-05 comment. Where the exact context (is >this image a link, or not?) is not obvious, it's more important that the >position of the items is consistent than that all of the items are enabled. It's obvious to me when an image is a link. The cursor becomes a hand, and the status bar text changes to the URL of the link. The current spec would have "save as" very far down on the context menu for a non-link image, which is going to annoy me a lot because I save images often. If a user right-clicks on an image, thinking it's a link, I think not including the items is just as informative as disabling them. I can even imagine users wondering why those items are disabled, still thinking the image is a link.

> Actually, Windows 98 and Windows 2000 both have 'Undo' as the top item. Sorry, typo. I meant that Windows native context menus don't include `Redo'. > Not for me. I have no use for Right-to-Left text so that item is something > I'll aways be flying over (and if there's two of them, I'll be flying > farther). The only case when you'd ever be flying over it would be if you were inserting a Unicode control character, for the first time in a given session (after which you'd probably leave the character palette window open). Eeeeeeeedge case. > Sure, it's possible to copy the entire link, paste it into the box, go to the > begining of the text you just pasted and hit delete 7 times, but that's a lot > more work than selecting Copy e-mail address from the context menu and then > pasting it That's bug 64036 and bug 83068. > (and I do that semi-frequently when cc'ing somebody on a bug or > giving somebody credit in a check-in comment). And of course, millions of people use Bugzilla and Bonsai every day. :-) > There's still no way to bookmark a frameset (i.e. the equivalent of File > Bookmark... when you right click somewhere in a frameset.) Yes there is. `Bookmarks' > `Add Bookmark'. > How does your spec indicate when items are disabled? Try using a CSS-compliant browser. (I hear Mozilla is quite good these days.:-) > Change Text Direction would not be a checkmark item. It would merely change > the direction of the text in the textbox. When would a user want to change > the text direction? When it looked wrong. So a menu item to change it to the > right way (which it would) is what you want. It's not as obvious as that. The first time I accidentally pressed the keyboard shortcut for this function, I really thought that it was a bug in Internet Explorer. My words were all jumbled, but it wasn't obviously related to text *direction* at all. It was the mention of `Right to Left' in the context menu which enlightened me. > Your scheme _always_ has one > redudant menu item. So does any group of two radio items, whether or not they're in a menu. > Everyone wants Copy Email Address. It's very popular. Please leave it in. I find it highly amusing that the people who are arguing for one `Properties' item rather than two, are the same people who are arguing for four `Copy' items rather than three. > Can you explain the difference between an "internal link" and an "outbound > link"? Filed bug 90131. > I don't like having Reload at the bottom. It just looks out of place there. I pondered not having it at all, but it is reasonably useful for windows without a menu bar. > Muscle memory is only useful for the first few items on the context menu; > after that it becomes "click the last item on the context menu" or "click the > first item after the first separator". As it is now, the first half dozen items *are* consistent in position. Putting `Reload' near the top would disrupt that. > > `Save Page As ...' isn't really worth a context menu item; it's included > > for consistency with `Save Frame As ...', not the other way around. > > Not many pages use frames. Do we really want to change the default context > menu just so it's consistent with the frame context menu? Firstly, we're not changing it, inasmuch as `Save As ...' is already in the default context menu. Secondly, including it isn't just consistent with the frame context menu; it's consistent with the frame context menu *and* the image context menu *and* the text link context menu *and* the image link context menu. > It's obvious to me when an image is a link. The cursor becomes a hand, Sure, for the 0.5 seconds during which you are over the image before clicking the mouse button. (And if you're on Mac OS and using Control key to invoke the context menu, the cursor is the special `context-menu' cursor and doesn't become a hand at all.) > and > the status bar text changes to the URL of the link. Which you don't notice, because you're looking at the area where the menu is about to appear, not at the status bar. (And if you have the status bar hidden, or the page is scripting its contents, then the URL doesn't display there at all.) > The current spec would > have "save as" very far down on the context menu for a non-link image, which > is going to annoy me a lot because I save images often. I'm sorry. I'd use `Block Image ...' a lot, and that's even further down. Sucks to be us.

Responses to mpt and others [about Copy Email Address] > That's bug 64036 and bug 83068. Mpt, this makes the unwarranted assumption that the user uses Mozilla as a mail client and therefor is pasting the email address into Mozilla's composer. By and large, I would say this assumption is false. > It's obvious to me when an image is a link. The cursor becomes a hand, The page author can change that in CSS with very little trouble. It's not something to depend on.

As for the Mail app context menus, I'd like to keep them as spec'ed here: http://www.mozilla.org/mailnews/specs/threepane/MailMenus.html#Context This spec has been available and evolving/improving for some time now. The items are very close to mpt's spec. nbaca spend a lot of time writing bugs based on this spec and James Green, as well as others, has put in a lot of time and effort getting them to match the spec linked above. If there are specific issues with any items in the spec above, let me know.

> > There's still no way to bookmark a frameset (i.e. the equivalent of File > > Bookmark... when you right click somewhere in a frameset.) > > Yes there is. `Bookmarks' > `Add Bookmark'. You are introducing a UI inconsistency here. If the document doesn't contain frames, you can bookmark the document from the context menu. However, if it does, you can't. Why, when adding a bookmark, should it matter whether the document contains frames or not? > I find it highly amusing that the people who are arguing for one `Properties' > item rather than two, are the same people who are arguing for four `Copy' > items rather than three. Three rather than two :-P. All I know is, as soon as I added it, loads of people said how useful it was. Gerv

Sorry if I missed it, but my most common use of the context menu is to do an open link in new window. Are these drafts not covering context menus on links?

Isn't: |* {Open | Submit} in New Window| what you want? (under Text in Link)

| > The current Properties window does all the relevant properties in the same | > window | | That's a bug. :-) It shouldn't be. If I have an image in a link in a <blockquote> w/ 'cite' in a <table> w/ 'summary', the UI should be able to let me access the properties of all four without generating four separate "Properties" menu items. The bug would be "improve design of Properties dialog". | > Why is reload after page properties? normally properties is the *last* item | > in a context menu. | | in most of these menus, it is. However, I judged that keeping it in a constant | position in the other menus was more important than making it the last item in | those menus. {Properties} should be at the bottom of _every_ Navigator content-area context menu. The 'title' attribute applies to almost every element in HTML, and there are other metadata handled by the Properties dialog for elements besides <a> and <link>. (Yes, that includes the <textarea> tag.)

> Mpt, this makes the unwarranted assumption that the user uses Mozilla as a > mail client and therefor is pasting the email address into Mozilla's composer. Not at all. What it does do is draw a line in the sand by saying that proper handling of clipboard URLs is the responsibility of the pasting app, not of the copying app. If I right click on <a href="mailto:bzbarsky@mit.edu?cc=gervase.markham@univ.ox.ac.uk&amp;subject=Context">this</a> in a Web page and choose `Copy Link Address', the right thing should happen whether I paste into Nautilus (creating an Internet shortcut), or into a message composition window (filling out the relevant header fields), or into a text editor (pasting the URL verbatim). If I chose `Copy E-mail Address' for that link, I'd get dataloss. For exactly the same reason, in the context menu for an image we don't have separate `Copy as BMP', `Copy as XPM', `Copy as PNG', etc items. It's up to the pasting app to do the relevant conversion; it is none of our business. This has been the case for images for the past 15 years or so; it's time it was the case for URLs as well. > Why, when adding a bookmark, should it matter whether the document contains > frames or not? It doesn't. If you want to bookmark the current page, whether or not it contains frames, you can *always* choose `File Bookmark ...' (or `Add Bookmark') from the `Bookmarks' menu. If you want to bookmark the focused frame, whether or not that frame is the only one in the page, you can *always* choose `File Bookmark {for Frame} ...' from the context menu. > If I have an image in a link in a <blockquote> w/ 'cite' in a <table> w/ > 'summary', the UI should be able to let me access the properties of all four > without generating four separate "Properties" menu items. No. As usual for a linked image, only `Link Properties' and `Image Properties' would be present. BLOCKQUOTE CITE would be much better presented as a linked icon at the end of the blockquote, than as a poorly discoverable item in a context menu. (Unfortunately we can't do the same for IMG LONGDESC, since that would often break page layouts.) And TABLE SUMMARY is irrelevant to graphical Web browsers, since it is far quicker to scan a table itself than to invoke, read, and get rid of, a summary of it. > {Properties} should be at the bottom of _every_ Navigator content-area context > menu. The 'title' attribute applies to almost every element in HTML, ... and is shown as a tooltip, without convoluting the context menu. (If the title is for a link or image, showing it in the relevant Properties window is just an added bonus.) > and there > are other metadata handled by the Properties dialog for elements besides <a> > and <link>. (Yes, that includes the <textarea> tag.) So file bugs for them. But please don't expect context menus (or ubiquitous `Properties' windows) to be used as a dumping ground for checkbox compliance with every W3C HTML edge case. That would be unfair on the people actually trying to use Mozilla as a Web browser. I think I'm nearly done here.

I just discovered Copy Email Address, and my reaction was "Mozilla rocks -- that's the coolest thing I've seen in a long time!" It's a big timesaver. It would be a real shame if we were to remove such a useful feature because of some determination to change the world and make every existing mail, shell window, and terminal client change their behavior to understand URL format when their job has nothing to do with URL handling.

Should every webmail site (hotmail, mailandnews, etc) also detect if the user pastes a mailto: link, using javascript? I don't think they can tell the difference between pasting and typing without a lot of ugly javascript, and the site won't even see the onchange event until the to: textbox loses focus. And how is a console app supposed to detect a paste of a mailto: link, if all it sees are the keystrokes 'm', 'a', 'i', etc? I agree with Akk. Let's leave "Copy E-mail Address" in the mailto context menu.

Re mailto: I use a console-based mailer and currently also do the mailto: shuffle, editing it out. That said, I think mpt is CORRECT. Adding a special case to mailto links ruins the consistancy, and causes data loss. Options such as the cc: and subject: are lost, which may be quite important, and the user isn't even aware. Mailto: is a standard, and the correct fix is for my mailer (mutt) to support it. For webmail (yelch), the correct fix is to support it. How? What about a special field, off to the side, that would accept mailto: URLs and fill in the other fields when you enter one there. ---- Menus look good mpt, nice work. Unblock Image, Load Image, Insert Character... very nice additions. Minor complaints: I'd prefer the bookmark entries just add a bookmark under main menu, rather then me having to file it, as I do a simple add much more often the file, and can always hit CTRL+B when I need it filed or renamed. I'm disapointed to see 'Hide Image' replaced with 'Reload Image'. 'Hide Image' would be quite useful for very annoying animated gifs and such (though I suppose if a way to stop them is added, it might be good enough). Also, I'd very much like to see View changed to Show. As Peter said, View sounds very passive, when Show is much more active...I'm giving the orders. "Show me!", not "Please let me View"

> Adding a special case to mailto links ruins the consistancy, and causes data > loss. Data loss? If I select "Copy Email Address", I would expect just the address the mailto: link would go to.... the rest of the stuff would obviously not be relevant to me. mailto: urls are not universally used by all things that do email. Arguing that they should be will not make it so. This is one of those cases where I feel that "we need to change the world" ideals should take second place to actual ease of use for the average user. At the moment, there is a dearth of Unix mailer programs (much less other places you would want to put email addresses, such as alias files) which would deal with a mailto: url being pasted in. In fact, I don't know of any that would deal... Having this menu option is a lot more useful than being able to copy the whole URL in the vast majority of cases. > For webmail (yelch), the correct fix is to support it. How? What about a > special field, off to the side, that would accept mailto: URLs and fill in the > other fields when you enter one there. Would this be provided by Mozilla? Or the webmail provider? If the latter, this seems pretty unlikely to get implemented....

mpt was asking about why the re-assign[ee] field was editable. as is it's the reason i don't care about copy email address, but in fact w/o that quirk of bugzilla (which he suggested removing) I'd be very upset because I'd have to manually remove mailto: to get a valid bugzilla account. There are many bugzilla installs out there and many other things which use email addresses as accounts but which are not email consumers (bugzilla is a producer not a consumer). I'm still holding out for a clipboard or right dragging but mpt seems opposed to both, so he made the stew it's his turn to sit in it. the fire's nice and warm.

The Editor team needs to approve the removal of the Edit Link in Composer item. Taking this bug.

There's a problem in many of these context menus, I believe -- they don't group items well enough. I'm not basing this on my staring at the menus or some UI spec, but on the simple fact that I just implemented the menu for links, browsed with it for about an hour, and found myself having to read through the items at the bottom of the link context menu over and over to find which one I wanted. I had an easier time finding the desired item in both our old menu and in IE's, because those items are spaced out more, and grouped somewhat more logically. I'm not looking forward to using the image context menu, which adds another item (now 6) to the list of miscellaneous items at the bottom

Adding Ben, he has to review these changes if/when they happen.

To see what blake meant, I took the spec and added a few examples for each menu in the top section. As a power user, I liked the proposed text field menu much better than the existing one. Both page content area menus feel poor, though. First, as a Windows user, I expect "Page Properties" to be at the bottom. Second, the copy/save items should, in my non-expert opinion, be separated more from the management items. I find that in the current menu I can tell at a glance where the items are, whereas in the new menu they seem randomly ordered. (I'm sure muscle memory might help a regular user to remember where the items are, but as I switch web applications frequently, my muscles can't remember that kind of detail.) The frame menu has the same problems as the page menu, but seems to add no new problems, so once made consistent the new one would be ok. It took me a few minutes, but I finally decided that I don't mind having to use the main menu to get to the frameset's source. The image menu is much better, the only problem being the unusual and confusing grouping (like Blake said). I found myself wondering why Copy Link Address and Copy Image were not with Copy Image Address. My mind seems to work by narrowing down on the item I want, in this case saying "copy, copy image, copy image location". But with the proposed menu, that fails. I think the decision as to which menu items to keep on the image menu was good, however. The link menus (once made consistent with the corrections made for the page and image menus) had only one flaw: The top two menu items in each should be switched. If I want to go to the link, I will click on it. If I want to go to the link in a new window (i.e., use the "secondary fire" option on the link) then I will right-click. And thus the "Open Link in New Window" option should IMHO be first. However, I noticed that WinIE doesn't do this, and WinIE's menu for links is fine too. So maybe this is not a requirement. (IE's menu uses a different grouping strategy: first, things to do with the remote page, and second, things to do with the remote page's link. So they have "Save Link As" in the top section instead of the bottom section). As a final comment, I would like to throw in my vote for keeping the "copy e-mail address" (without mailto:) feature. The number of times I have to cut off mailto: prefixes is just stupidly high. I hope these comments help.

I suggest changing "Save Link As..." to "Save Linked File As..." I remember being confused about this when I first started using a web browser; I'd waver between "Save As" and "Save Link As". I didn't want to save the link (the blue hyperlinked text)--I wanted to save the file on the other end. > The top two menu items in each [link menu] should be switched. The default action is the first item in the context menu so you don't open a new window by mistake, e.g. by holding the mouse button down a split-second too long. > I found myself wondering why Copy Link Address and Copy Image were not with > Copy Image Address. Same here. If we were to sort by function first, and then by object it would look something like this: * {Open Link | Submit Form} Action * {Open | Submit} in New Window * Copy {Image | Selection} Copy * Copy Link Address * Copy Image Address * Save Link As ... Save * Save Image (blarg_01.png) As ... * File Bookmark for Link ... * {Block | Unblock} Image ... Load * {Load | Reload} Image * View Only this Image View * Link Properties * Image Properties {and Description} So, is that better, or worse?

Ok. Firstly, I'd like to point out that if you're used to using the current context menus, any new ones -- no matter how good or bad their design -- are going to be *awful*. Absolutely horrible. Like waking up one morning to find that you now have to speak a different language with a completely different grammar. And the new menus will continue being horrible for about a month, until you get used to the new layout. What do I mean by grammar? Well, the current context menus are predominantly noun-verb-noun -- you mousedown on an object (noun), you choose the function you want (verb), and then you choose whether you want that function to apply to the link, e-mail address, image, or selection (noun). This approach is also followed, in general, by MSIE for Windows -- though it doesn't look quite as extreme there as it would here, because MSIE doesn't let you `Copy E-mail Address' or `Copy Image' (so there aren't four `Copy' items, only two). The approach I followed with my spec, though, is noun-noun-verb. Actions relating to the same object (link, image, etc) are grouped together. This approach is followed by 4.x for Mac <http://www.nadn.navy.mil/LangStudy/popmenu.gif> and MSIE 5.0 for Mac. The advantage of noun-verb-noun is that because similar actions are grouped together, it is easier to find stuff when first beginning to use the menu -- it is more learnable. The advantage of noun-noun-verb is that because the same item is always in the same place, it's quicker to get to an item once you've learned where it is -- it is more usable. I made the assumption that because context menu users tend to be power users, they'd be willing to put in some effort to learn the arrangement in order to make the menus quicker to use in the long run. I'll fiddle around with some noun-verb-noun arrangements once I get home, and see what I can come up with.

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

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

Some comments about attachment 43944 [details] about navigator. I propose another way to sort and categorize the context menu items. Sorry to be late in the arena and having filed duplicates! :o) General: I suggest to adopt an action-driven categorization of the items (with separator) instead of an object-driven categorization. The reason is: - that's way we speak. Verb then complement: Watch a dog. Dog comes later (see examples to see the alphabetical effect) - this is how our brain works. I won't give you a lesson, but brain has separated parts that do separated things. It has no part dedicated to the specifical object it is dealing with. - that's the way task menus in applications work. context menu items should be split in four categories (except Text field): ------------------------------------------- Navigation (forward/backwards/open frame,link,image) ------------------------------------------- Manipulating: Editing and Viewing (copy, block, view element,block/unblock) ------------------------------------------- Saving (bookmarks, save as) ------------------------------------------- Properties (single item) ------------------------------------------- 1) Page content area proposal: +------------------------+ |Back | | |Forward | |Navigation |------------------------| |Select All |----------+ | |Forms... >|Prefill | | |View Page Source |Save Data | |Editing/viewing |View Page Background |View Data | | |------------------------|Help | |Bookmark this Page as...|----------+ | |Save this page as... | |Saving |------------------------| |Show Page Properties | |Properties +------------------------+ - the reload item is totally useless, since: o for the unexperienced user: one-click accessible buttons exist. o for the experienced user: ESC and CTRL-R exist. the same for other context menu, even for the image reload. - Form options of the current implementation are not frequently used. Thus they should be hidden but not removed, this is a netscape new feature that should be promoted. If you don't put them in the context menu, I wonder if any people will use them. A help should be nice, since it is a new feature. - Copy button should at least only appear when selected text is hightlighted (4xp). Imho, this button could be completely removed: selecting a text with the mouse should copy it (Select All too). But I think many people won't like to change this (one-click useless) behavior. (If many people get confused, it is a valid reason to keep it) Copy button, if retained, should appear before Select All. - Copy page location is useless: doubleclicking on the location bar (or dragging the URL) does the trick. - Bookmark this page instead of File Bookmark (same action, however) 2) Text field proposal: +-----------+ |Cut | |Copy | |Paste | |Delete | +-----------| |Undo | |Select All | |-----------| |Insert char|----------+ |Forms... >|Prefill | +-----------|Save Data | |View Data | |Help | +----------+ - what about not to copy MSIE? Undo is less frequently used so it should come after the cut/paste/copy. Nevertheless, people could be confused. - I don't think delete is useful in a little form editor, but I don't want to reactivate the debate. - add form droplist. - left-right will confuse end-user from Europe and America. First he/she will think that's funny, then he will be bored. Because it is 100% useless for them. Moreover, I think and hope that a toggling short-cut will (is) iplemented. In this case, 1% from 0.01% of the end-user will still use the right click because they will use the shortcut: this feature is vital for them. I think a short-cut or an Icon (active or inactive) in the status bar would do the job. 3) Frame context-menu: WORKSFORM! (imho) - end-users don't care if the web site uses frames or not. - suppose you visite a site with frame. You will only see the Frame context menu. and you WON'T be able to bookmark the page, but only the frame!!! I would do what ns 4.x do. (adding view frame, and view frame in new window and frame properties only to the context menu page items) And THEN the user will be able do whatever he/she wants with the frame, using the page context-menu. 4) Image context menu: - I would get rid of the 4 greyed menus. And follow a partition of the menu according to my proposal 1. Editing/Viewing, Saving, Properties. Same partition logic could be to the other context menus: For an Image in internal link, the menu would be +-------------------------------+ | Open the Link in a New Window | |-------------------------------| | Copy the Image | | Copy the Link Address | | Block the image | | View only the image | |-------------------------------| | Bookmark the Link as... | | Save the Image as... | | Save the Link as... | |-------------------------------| | Show the Image Properties | | Show the Link Properties | +-------------------------------+ Notes: - Open the Link is useless: left-click on the image - File Bookmark on link is of poor interest. Not sure if it should be save. I can give all the spec in an attachment, if you are interested. Thanks for the attention, and sorry again for the spam.

> that's way we speak. Verb then complement: Watch a dog. Dog comes later That's not how we speak in Latin or German -- in both the verb is the last word in the sentence. That's not how we speak in Russian, in which the word order typically does not matter. In general, languages that have cases for nouns do not depend on ordering to convey meaning; the case of the noun determines what it means. In such languages sentences can, and often are, rearranged to achieve a specific aesthetic or stylistic effect. > selecting a text with the mouse should copy it On Unix it does. On Windows/Mac it would go counter to the platform standard for copying and lead to incredible user confusion > Copy page location is useless: doubleclicking on the location bar (or > dragging the URL) does the trick. Not in kiosk mode or any other situation in which the navigation toolbar is invisible/minimized it does not! > Bookmark this page instead of File Bookmark see bug 77400 > And THEN the user will be able do whatever he/she wants with the > frame, using the page context-menu. Except about 60% of frames out there have JS that prevents them from being viewed as standalone documents.... > Open the Link is useless: left-click on the image If you're familiar with the way context menus work on Mac (click-hold to get the menu), it should be obvious the the click-action and the default context menu option should be the same action. Otherwise much user confusion will occur. Other than that, sounds like good ideas worth discussing.... One question. There are tons of pages out there that are basically one big image map. On those, how would one access the page context menu options? Your proposal would only show the link/image options on such pages...

This just goes to show how suboptimal our current context menu building system is...I plan to rewrite it after 0.9.4.

Boris, I agree with all your comments, sorry for the ethnocentrism. Nevertheless, the valid reason stands why so many people are confused with the current proposal: it is designed against our brain. This one is divided into parts that do specific job: moving, seeing, memorizing... BTW, I repeat, for a page containing frames, the proposal in attachment 43944 [details] is not able to bookmark, nor save, nor copy the Page! I can have missed sth, but I would like to be explained. I will attach a more complete proposal with the Boris' comments and the mpt's comments for using the/this.

Very important note on this proposal: ===================================== - I forgot to mention that it is based on the same idea as the Fantasia's one. - If issues such that 'File bookmark for this Link' instead of 'Bookmark this Link as...' have already been closed and are not matched by my proposal, just tell me, I will follow the decision that has been taken. Important notes: ================ - CM stands for context menu - (Thanks to Boris Zbarsky's comment) all the items in page content area CM are copied into the image CM, because of large images. - 'Follow-up the Discussion' instead of 'Open discussion' to be complient with the GNKSA terminology (see related bug 17796 and bug 95623) - 'Copy this E-mail Address' instead of 'Copy Link' - ability to bookmark an image (*NEW!*), a link and a page but not a frame, a mailto:bla and news:blablabla (the last two would confuse the user). Less important notes: ===================== - rule the/this for object acted on: 'this' for noun, 'the' for noun+noun - I added 'Open Page in a new window' but It could be dropped - I maintain View Page Source for 4xp. It would be nice if the source could be viewed in the Page/Frames properties. In this case, it could be dropped, but this feature is not yet implemented. - item forms... should be greyed instead of being dropped when there is no form in page (as it it currently) to promote this new feature.

mpt, are we missing another milestone? I don't know how much longer I can take the current sorry excuse for a UI we have. Any updates to your last proposal? Today is it's two month birthday...

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

I made a revision of MPT's 5th draft that focuses heaviliy on making the link context menus consistent with each other and by removing redundant items. Please take a look at it and let me know what you think. I think this version is a significant improvement over the 5th draft. However, it is just a suggestion (I am not the UI design owner). I am eager to here what others think about it. These are the changes I made: 1) The image link context menus are the text link context menus with the image context menu appended to them. 2) Back and Forward are gone as these are redundant and not context-specific. 3) Copy is gone because in the current UI it is always disabled and I can't figure out what "Copy" on a link is supposed to copy anyway. 4) All link context menus are the exact same size (this is just a side-effect of other changes) 5) I changed the frame context menu so that it has the page context menu appended to it (see previous comments in this bug by others). 6) I changed the defaults on some of the messenger link context menus from "Open [xxx]" to "Open [xxx] in New Window" since that is what messenger actually does. My HTML page is a based on MPT's. I significantly edited it by factoring out the context menus that are identical between messenger and navigator into a third section. Also, I added a Javascript-based form to show/hide the image-specific items for links so as to make the specification page much smaller (half as wide, approximately). In addition there is a radio button on the form that can be used to choose between displaying the Messenger or Navigator version of the shared context menus (changes which items are disabled and which items are the default). TODO: If the image context menu is going to be appended to the link context menu (for image links) then the access keys for the images context menu will have to be changed. I didn't do this yet so there are clashes between the image items and the link items. Similarly for Page/Frame items. I don't know how to go about deciding which access keys to use. TODO: For form items there are probably more form-specific items that should be added.

> 3) Copy is gone because in the current UI it is always disabled and I can't > figure out what "Copy" on a link is supposed to copy anyway. It's enabled when you highlight something (so that there is something to copy). Copy on anything, including a link, should copy the currently highlighted text. Also: Should "save link as" be disabled for news:? It seems that one could save news posts... There is now a "Open in New Tab" that should be considered for inclusion. And I still want a "Copy email address". That's a much more useful feature than "Copy link address" for mailto: links. In fact, if we only want to do one of the two, I would suggest "Copy email address" (yes, old argument).

This latest spec augments the problem introduced in mpt's by grouping even more items together. For example, your image context menu has 8 items which you purport to be part of the same group; I don't believe that's the case.

"Copy" on a link should copy the entire link, even if the link text isn't selected, as it does in Composer. It should copy as HTML, e.g.: <a href="foo">link text</a> This is helpful to users to paste that link into Composer. I believe this code for this is already in global/browser, since Composer's "cmd_copy" is just using the global command and its implementation of it. Thus the "Copy" command should be present and enabled if event object is a link.

Adding 'Open' to link context menus was wontfixed in bug 64749 (much to MPT's displeasure) so it really shouldn't be appearing in menu specs now.

> Adding 'Open' to link context menus was wontfixed in bug 64749 (much to MPT's > displeasure) so it really shouldn't be appearing in menu specs now. Of course, 24 minutes after I posted that comment bug 64749 was reopened...

If the "Copy" Item is supposed to copy the link label, then it should be labeled something such as "Copy Link Label". If it is supposed to copy the HTML for the link (<a href....</a>) then that is what "Copy Link Location" does. What does "Copy" on a page or a frame do? Copy only applies when there is a selection, and a selection (e.g. selected text) should have its own, much abbreviated context menu. I can come up with a design for that.

I agree that my description of what 'Copy' does in Composer is really what should happen with 'Copy link location'; I'm just described current behavior. The current 'Copy link location' is not as smart -- it only copies the href, not text. What I described copies both and thus pastes the complete link text + <a> node into Composer. It seems the implementation should be shifted to Copy Link Location? Or use 'Copy Link' as menutext when there's no selection?

Everybody: please look at the new revision I believe it is significantly better than my previous one. Alex, please see my comments in bug 64749. * For an image link, the single "properties" item should open a (tabbed?) dialog with information about both the image and the the link. Having seperate items makes the context menu too cluttered. * For frame properties, the single "properties" item should open a dialog that shows information about the whole frameset with the active frame's properties somehow highlighted. Having seperate "page" and "frame" properties items is messy. * I changed "Copy Link Location" to "Copy Link" with the expectation that "Copy Link" will copy the whole <A> tag like Composer and MSIE do. Thus, there is no need for seperate "Copy" and "Copy Link Address" items. * I didn't enable "Save Link As..." for news: but that can be decided by someone else. You would have to parse the news: link to see if it is pointing to a specific message or if it is pointing to a newsgroup. * I added "Open in New Tab" for links, but not for pages, images, or frames as it would be such an infrequent operation for the latter item types. * I won't address "Copy email address" vs. "Copy Link". * I made the "Other Links" context menu even more consistent with Internal and Form links. * access keys still need to be addressed in my proposal, but I did make some effort on this front as well.

> Alex, please see my comments in bug 64749. Yes, read them. I don't disagree with you about having 'Open' on link context menus, I was just saying that we should abide by final decisions (and it was final when I made my comment... it just isn't any more). Comments on the latest menu spec (not all of them applicable to just the latest revision): * Not too sure if we want to have 'greyed-out' items * Why can we 'View Background Image' but not 'Save Background Image As...'? * I prefer 'Show Only This Frame' to 'View Only this Frame' * 'Copy Page Address', 'Copy Frame Address' etc. should be 'Copy Page Location' and 'Copy Frame Location' because we use 'Location' everywhere else * 'Send E-mail' should be 'Send Email' because we use 'Email' everywhere else * 'Open Discussion' should be 'Open Newsgroup' and all references to 'Group' should be 'Newsgroup' (more consistency goodness) * Bug 15176 has been fixed - have to fit that in somewhere * That's all for now

> ------- Additional Comments From alexbishopuk@yahoo.com > * Not too sure if we want to have 'greyed-out' items > * I prefer 'Show Only This Frame' to 'View Only this Frame' > * 'Send E-mail' should be 'Send Email' because we use 'Email' > everywhere else> > * all references to 'Group' should be 'Newsgroup' (more consistency goodness) > * Why can we 'View Background Image' but not 'Save Background > Image As...'? I "fixed" all of these. > * 'Copy Page Address', 'Copy Frame Address' etc. should be > 'Copy Page Location' and 'Copy Frame Location' because we > use 'Location' everywhere else I want to change thse to "Copy Link to this Page" and "Copy Link to this Frame" (or possibly something shorter). Then they will match my proposed semantics for "Copy Link". > * 'Open Discussion' should be 'Open Newsgroup' and I believe it is "Open Discussion" because the news: url might point to a particular message/thread in a newsgroup. I just left it the way it was. > * Bug 15176 has been fixed - have to fit that in somewhere No context menu changes are needed for 15176. If the highlighted text is URI, then one of the link context menus should be shown. Otherwise, the context menu for selected text should be shown. This is what makes the most sense anyway.

On Selected Uneditable Text context menu, I would add "Select All".

> On Selected Uneditable Text context menu, I would add "Select All". No, let's not. Who ever uses that? I select text often, but never had I wanted everything on a page... if I did I would have Save as'd. For the few times you need it, it's already in the edit menu WITH a hotkey. More then it deserves. > * Not too sure if we want to have 'greyed-out' items We do. Makes the menus place items in the same spot each time. > * Why can we 'View Background Image' but not 'Save Background Image As...'? Because you can view, then save. But you can't save, then view through the UI. It's not common enough to have two options for it. > * I prefer 'Show Only This Frame' to 'View Only this Frame' Yes it's 4 votes for show vs. 0 for view, I believe. > * 'Send E-mail' should be 'Send Email' because we use 'Email' everywhere else Actually it should be left and E-mail should be set everywhere else as well, since that's the correct spelling. Small e and no hyphen are just lazy ways to type it. Or did you make a Uturn on your way to work? Do you remember Dday? Is your house build with Ibeams? Xrays pass right through Tshirts, you know. Anyone eaten a Cration? mpt, what's this waiting on? No word from you in two and a half months. If nothing else can we get a branch with the new menus, so we can get some usability testing done with them?

>> * Not too sure if we want to have 'greyed-out' items >We do. Makes the menus place items in the same spot each time. Not on Mac OS. Never have greyed out items (not going to argue whether this is good or bad). I think the Mac classic skin handles this already. >> * Why can we 'View Background Image' but not 'Save Background Image As...'? I wouldn't include either. If I really want this, I can use View -> Page Info. Unfortunately I doubt we have usage data on whether I'm wrong because lots of people do this all the time. My feeling is they don't, but I'm just me. >Actually it should be left and E-mail should be set everywhere else as well, Generally only in the US. And besides, the language evolves. People used to write soft-ware at one time, should we do that also? Email (and email) is long since established as a word. Lets just be consistent with the rest of Moz.

For "other" links: "Open in New Window" should be replaced with "Open With..." if we don't know what program to launch for the given protocol. If we do know which application to launch then it should be "Open with [application name]". For the frame context menu, the "reload page" item should be immediately above the frame-specific items to make it consistent with the page context menu. "Email" isn't in the dictionary at www.m-w.com (which only has "e-mail") but it is so commonly used that I expect it to be added officially to the language soon. For background images: I agree, it is not very common to mess with background images. However, my current idea for the page context menu does leave space for it. If it is agreed that it is so uncommon, perhaps we should change the background image items to "Get Background Image..." which will ask you if you want to (1) save the image, (2) view the image, or (3) copy the image. I think that having the background image accessible only via the "Page Info" dialog box. Plus, the last time I checked the "Page Info" dialog box didn't give me the option to save or copy the image. For selected uneditable text, the Windows standard is to provide "Cut/Copy/Paste/[seperator]/Select All" on the context menu, with "Cut" and "Paste" grayed out. What is the Mac standard? The "right to left" and "left to right" items seen unnecessary to me. Are they really necessary on the context menu? I would think that for BI-DI languages, the user would have an easier way to toggle this (e.g. a keyboard shortcut or toolbar buttons) or maybe they even use a seperate IME like Chinese/Japanese.

'Email' is in the Oxford English Dictionary (http://dictionary.oed.com/cgi/entry/00073477?query_type=word&queryword=email&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=onyw-vGGvVE-7827). As I said earlier, it's already used in the UI ('Copy Email Address' in the mailto: context menus) so it's probably best to stick with that. Don't we have someone who's responsible for deciding on wording in situations like this? I think the context menu for selected uneditable text should contain all the items that are in the page content area context menu (in fact, the regular page context menu could contain a 'greyed-out'* 'Copy' item). The reason for this is that I don't consider selected text to be a different type of element to unselected text and I think (okay, hope) most users will agree with me. * I know I said that context menus shouldn't contain 'greyed-out' items before but I meant context menus for different elements. I consider selected and unselected text to be the same element in different states. Anyway, when did I ever say I was going to be consistent? ;-)

When you select text and then right-click on it, it is very unlikely that you are going to be doing any of the things in the Page context menu. It would also be nice to add other things to the context menu for selected text such as "Search for this Word" (badly worded), "View Partial Source", etc. Furthermore by keeping the number of items in that context menu to its functional minimum will allow the context menu for selected _editable_ text to be a superset of selected _editable_ text (including form controls, the URL bar, Messenger composition windows, Composer content, and even AIM, etc.). Put another way, if you highlight some text and select it, you should get approximately the same context menu no matter what you are doing. As for graying-out I think we should go with the convention of the platform we are on. For Windows that would be the behavior I described about ("Cut/Copy/Paste/Select All" with "Cut" and "Paste" deselected). For Mac, I guess it would just be "Copy" and "Select All". Could someone point me to a description of the Macintosh "Cut/Copy/Paste/Select All". Also, should there be a "Help" item in any of the context menus? lordpixel said in bug 64749 that Macintosh always has "Help" as the first item of every context menu. If so, then I would suggest that this only be done on Macintosh as it is not done on Windows.

[Sorry] I meant "Keeping the number of items in that context menu to its functional minimum will allow the context menu for selected _editable_ text to be a superset of selected _uneditable_ text". Also, previously, I meant to type "Having the background image accessible only via the "Page Info" dialog box is not discoverable enough".

> Don't we have > someone who's responsible for deciding on wording in situations like this? In general, you should follow precedent in the rest of the app. If you think it should be changed globally, file a bug, post to the newsgroup and we'll discuss it. But in the mean time, email it is. Gerv

Response to Brian Smith: > When you select text and then right-click on it, it is very unlikely that you > are going to be doing any of the things in the Page context menu. I'm still not convinced. But you're doing a very good job of trying. :-) A question: what would happen if the user selected some text and then right-clicked* somewhere else on the page? Currently, the context menu displayed is the same as the one shown if the user had right-clicked on the selected text (i.e. the 'Copy' item is enabled). I think this makes sense as it's unreasonable to expect a user who has selected a single letter to have to right-click exactly on the selection. But what about in your spec? A user may select some text, change their mind, right-click somewhere else on the page and get confused when just 'Copy' appears. > It would also be nice to add other things to the context menu for selected > text such as "Search for this Word" (badly worded), "View Partial Source", > etc. I believe that 'Search for this Word' functionality been implemented by bug 15176. It's a cool feature that geeks will love to show off to their friends. > I meant "Keeping the number of items in that context menu to its functional > minimum will allow the context menu for selected _editable_ text to be a > superset of selected _uneditable_ text. That's how it is currently. It's just got all the other page-related stuff in there as well. :-) > Also, should there be a "Help" item in any of the context menus? lordpixel > said in bug 64749 that Macintosh always has "Help" as the first item of every > context menu. If so, then I would suggest that this only be done on Macintosh > as it is not done on Windows. I don't think Netscape Communicator 4.x (or 3.x or 2.x for that matter) had the 'Help' item so I don't think it's too urgent that this is implemented in Mozilla (not that the mistakes of the past should be an excuse for perpetuating non-standard UI in the present). * Or platform-dependent equivalent Response to Gerv: >> Don't we have >> someone who's responsible for deciding on wording in situations like this? > In general, you should follow precedent in the rest of the app. If you think > it should be changed globally, file a bug, post to the newsgroup and we'll > discuss it. But in the mean time, email it is. Thanks. I won't be filing a bug because I much prefer 'email' to 'e-mail'. One less character to type.

I knew you were going to ask; this is my understanding of how context menus generally work in Windows applications and Windows itself. Somebody should chime in about how it works on other platforms: The selection context menu would only be applicable to the right-click inside the selection. If you right-click outside the selection, that actually deselects whatever you had highlighted and selects whatever you clicked on. So, right-clicking outside the selection actually brings up the context menu of whatever the new selection is. If there is no selection, then the page/frame context menu is shown. As for it being difficult to right-click on a single letter, I think it is even harder to select that single letter in the first place. Besides, most people have a "context menu" key on their keyboards. Also, the point I failed to make about having the Page context items in the selection context menu is as follows: eventually there will be more items in the context menu for selected text (such as search) which are very useful. Adding page context items makes these useful features harder to find in the context menu. Especially consider the case where the selected text is inside a frame; then you would have to add the (already numerous) frame context items to the selected text context menu and it would become the longest context menu in the system.

> The selection context menu would only be applicable to the right-click inside > the selection. If you right-click outside the selection, that actually > deselects whatever you had highlighted and selects whatever you clicked on. Not right now it doesn't. Some Windows apps (e.g. Word) do act as you described but others (e.g. WordPad) don't. But that's the sort of consistency we expect from Microsoft. ;-)

Context menu click should NOT deselect. That's how I thought most Windows apps worked; I'm surprised Word doesn't follow that (maybe it's a pref in Word?)

> Context menu click should NOT deselect Um, why not? I think the behavior "the context menu applies to whatever you right-click on" (or platform equivelent) is the only rule that makes sense. In mozilla, if you right-click on anything (image, link, form control), the context menu you get is the thing that you right-clicked on, which basically means that the right-click changed the focus to that item. Thus it is almost already doing what I am suggesting it do. What is odd is that mozilla distinguishes between focus and selection w.r.t links. That is, some text could be highlighted and the focus could be on a link, at the same time (see below). So if you select some text, then right-click on a link you get the link context menu, but if you select some text and then click on some "normal" unselected text, the context menu applies to the selected text (inconsistent). I think that is confusing and I think that the IE behavior of "selection and focus are equivilent in the content area" is more intuitive. If we follow that behavior then right-click must deselect, IMO. Here is a test: In this bug report, select some text. Then right click in the "Additional Comments" form control. Focus will be shifted to the "Additional Comments" control and the context menu you get will be the one for "Additional Comments". Are you saying that the text you selected should still be selected at this point? I think the current mozilla behavior is confusing. For example, do this: * Select some text. * Right-click on a link outside the selection The text will stay selected, but the link is also highlighted. So now there are two selections at once. What does "copy" on the context menu do: Does it copy the selected link, copy the selected text, or copy both? Answer: The context menu applies to the link you right-clicked on. Not so intuitive, IMO. Try this: * Go to http://www.mozilla.org/ * Use the tab key a few times to highlight one of the links on the left-hand side such as "Feedback". * Right-click on a different link, e.g. "Developer Docs" The "Feedback" link will be un-highlighted and the "Developer Docs" link will be highlighted. The context menu applies to the "Feedback" link. Try this: * Select an icon on the Windows desktop. * Right-click on the icon. You will get the context menu for that icon. * Right-click on the Windows Desktop. You will get the context menu for the desktop. What I am suggesting is to be consistent with the Windows desktop behavior, at least on Windows.

>> Context menu click should NOT deselect >Um, why not? Because the user might have spent a while selecting just the right thing, and we shouldn't destroy that selection unless the user explicitly asks for it. (Especially on Unix where most users don't do an explicit copy, so any selection is presumed to be waiting to be pasted somewhere.) > And I still want a "Copy email address". I SO miss "copy email address". I used it all the time, and it was one of the major nicities of Mozilla over other browsers. Copy link vs. copy link contents: Currently, I use copy link contents to get the url inside the link, so that I can paste it into some window somewhere that's expecting plaintext. That's what it does now, that's what it's done for many years, and all of the proposals mentioned in the last day make it sound like they'd break that, but maybe I've misunderstood, or someone knows something about the plaintext serializer that I don't. Anyway, whatever you call the various link-copy options, please don't break the ability to paste only the url into plaintext.

Akkana, my idea for the "Copy Link" feature is basically the same as MSIE. If you have IE, right click on a link and do "Copy Shortcut" and then paste it into Notepad. You will get the URL. Everybody wants "Copy Email Address" because they want to copy the email address in plain text to another application that won't string the "mailto:". How about this: Even now when mozilla copies a "MAILTO:" link it supplies the link in two formats on the clipboard: text/plain and text/html. The problem, IMO, is that the text/plain format is "mailto:user@domain". Instead, why don't we just supply the text/plain version as "user@domain". Further, I think that mozilla should be able to recognize "user@domain" as an email address everywhere it accepts URL's (especially the URL bar). So, what is wrong with this idea?

> So, what is wrong with this idea? "mailto:foo@bar.com?cc=baz@bar.com&subject=Dinner+tomorrow" What would be copied into the clipboard in the various flavors? What would be pasted into the mozilla url bar if I copy and then paste? Note that I'm just being devil's advocate here. That last proposal of Brian's would actually make me fairly happy. Do we have the back end to put things in the clipboard with various mime types using JS?

> Do we have the back end to put things in the clipboard with various mime types > using JS? Currently, we put html on our private clipboard; if the system clipboard asks for plaintext, the html is converted into plaintext at that time. I think the clipboard actually has the mechanism to let us add multiple flavors, with different content, at once. We should probably open another bug for that, though, and not clutter this one. Note that this proposal would make the link not work right if pasted back into mozilla's urlbar or content area. But it's not clear why anyone would want to do that, since they could just click on the link to get the same effect. I suppose they might want to copy it then paste into a different browser, but it's certainly not a common case.

I agree with Brian's description of how "Copy Link" should work. When pasting into Composer, it should past full HTML: <a> tag with attributes and the text that displays the link. But when pasting in plain text or in browser URL bar, it should paste the URL as text. Unfortunately, using the "Copy" command on Composer context menu does *not* do that correctly -- it pastes the link text, not the URL. But as I mentioned above, that code resides in browser, not Composer.

It would work right because I am proposing to change the URL bar to treat "user@domain" as "mailto:user@domain". I am not sure why it wouldn't work in the context area because mozilla will paste it in as text/html which will be the full <A> tag. For example, on your comment I would right click on "Akkana" and choose "Copy Link". Then if I paste it into the URL bar the URL bar will contain "akkana@netscape.com". The URL bar would recognize this as an email address and open up your email client. Currently the URL bar interprets "akkana@netscape.com" as "http://akkana@netscape.com" but it is much more reasonable to interpret it as "mailto:akkana@netscape.com" and we should file a bug on this. Furthermore, if Mozilla treats <a href="akkana@netscape.com">Akkana</a> as an HTTP:// link then that should be filed as a bug as well. Now, lets say that I paste the URL into a HTML-formatted email message. Then mozilla would insert the link into the message using an HTML <A> tag with mailto:akkana@netscape.com">Akkana</a> . Similarly if you were using Composer to create a web page.

A few comments: > mozilla will paste it in as text/html which will be the full <A> tag.] That will not work. url-paste treats the pasted string as a literal url. > Currently the URL bar interprets "akkana@netscape.com" as > "http://akkana@netscape.com" Yup. That's a perfectly valid HTTP URL. Simple auth login with username "akkana" at the server "netscape.com". Sucks, huh? :)

Well, "user@domain" is valid MAILTO URI as much as it is a valid HTTP URI. Which one is more useful? I believe that there was a comment on n.p.m.browser or n.p.m.ui about MSN Explorer making this change because so many of its users typed email addresses into its URL bar. I think it is a common sense change. As for URL-paste, please expand on why it won't work.

> Well, "user@domain" is valid MAILTO URI as much as it is a valid HTTP URI. > Which one is more useful? I believe that there was a comment on n.p.m.browser > or n.p.m.ui about MSN Explorer making this change because so many of its users > typed email addresses into its URL bar. I think it is a common sense change. When you type something in the location bar, you are indicating that you want to go to a website, FTP server, gopher location or whatever. Therefore the browser should interpret user@domain.com as http://user@domain.com/ i.e. try access http://domain.com/ using the login 'user'. Interpreting it as a mailto: is incorrect because Navigator's function is to, er, navigate, not send emails. If the user@domain.com was recognised as the mailto: protocol, how would someone access http://user@domain.com/? Forcing them to type the http:// is just cruel. These sorts of logins aren't uncommon, especially on FTP servers. MSN Explorer has this feature because Microsoft's UE noticed that new users often tried typing email addresses into IE's Address Bar. I think this is probably because IE mislabels it 'Address:' when 'Location:' is clearly superior and because of the poor integration between IE and Outlook Express. But that's just me.

Interpreting e-mail addresses typed into the location bar as e-mail addresses is bug 51206.

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

This bug appears to have been accidentally stomped on 2001-10-17 11:48:17 by lordpixel. I find it hard to believe it is dependent on bug 889, which was not touched since long before this bug existed.

Best unstomp it then.

A number of bugs were removed at the same time, see bug activity.

> * Copy Link to Image It took me a while to figure out what I this was, even though I already know what's supposed to be on the context menu. Am I copying a link (what link?) or an image or what? I should be able to know what a context menu item does just by glancing at it--and here I have to peruse the label. I'm not sure I like all this link-copy automagic. It's rather unpredictable. I paste into a text editor, I get one thing. I paste into Composer, I get another. I paste into a text field and get a URI, yet when I paste into <pre>, I get a link with full text--even if I don't want that text. What happens when I paste into MS Word?

I don't understand the point of "copy link". Most of the time, you just want the link address, and having two copy items for the link would be confusing. If you want to copy the link as an html fragment, select the link (Mozilla has a neat shortcut for this: drag the link 10 pixels away from itself and let go), and select Copy. There's no need for an extra context menu item or inconsistent behavior depending on which app you paste into.

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

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

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

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

After reading the comments made since 2001-08-07, I have made the following changes. 1. Moved `Page Properties' to the bottom of the relevant menus, to better follow Windows convention. 2. Moved `Message Properties' to the bottom of the relevant menus, to better follow Windows convention. 3. Added `Copy E-mail Address' to the menus for mailto: links, in place of the disabled `Save Link As...' item (so as not to disturb muscle memory for the other items). 4. Changed the access key for `File Bookmark...' from F to M, to resolve the clash with `_Forward' in the menu for the page content area. 5. Changed the access key for `Send E-mail...' from M to E, to resolve the newly-introduced clash with `File Book_mark...' in the menus for a mailto: link. 6. Changed the access key for `Image Properties' from E to R, to resolve the newly-introduced clash with `Send _E-mail...' in the menu for an image in a mailto: link (and to make Timeless happy). 7. Changed the access key for `View Background Image' from V to W, to resolve the clash between that items and `Pre_vious Message' in the menu for the content frame of the mail/news message pane. 8. Changed the access key for `View Only this Image' from V to W, to be consistent with `Vie_w Background Image'. 9. Changed the access key for `View Only this Frame' from W to V, to resolve the newly-introduced clash with `Vie_w Background Image' in the menu for a frame body. 10. Slightly rearranged the image-related items to more accurately follow the link items above them. Many thanks to fantasai for finding the access key clashes. The finished version is at <http://mozilla.org/projects/ui/menus/shortcut/>. Separate bugs should be filed on making reality match the spec.

To whom it may concern, i.e. the implementor of the folder pane context menu, the "Open Folder" is currently redundant because the outliner insists on selecting the contextual item :-( Bug 106687 has been filed.

Re: MPT's latest spec I thought we decided on 'email' rather than 'e-mail' (see my comment on 2001-10-17 16:08 and Gerv's comment on 2001-10-17 17:16).

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

Re: Latest spec. Matthew, the preference for people here seems to be with 'Show' rather than 'View' in the context menus. Luckily, the keyboard shortcut changes you have made support the use of Sho_w as the shortcut key. However, I still think that shortcutting on a generic verb like view is a bad idea. You also seem to be varying which keyboard shortcut to use for the same item between context menus (in particular, Page content area _View Background Image has a different shortcut). How about using 'Show Back_ground Image' as the keyboard short cut, to match 'File as Book_mark'. And perhaps 'Show On_ly this Image/Frame' (Or another letter in Only as these two items are mutually exclusive)? Also, there are too many Copy items in each menu, but this is much harder to resolve. It is especially frustrating with the element labelled simply 'Copy'. Would this be better labelled Copy Selection in all circumstances, and to grey it out when no selection is made? Give some thought to renaming Copy Image Address and Copy Link/Frame Address to Copy Image Location and Copy Link/Frame Location. This suggests that these can be pasted into the Location field at the top of the browser. It also helps distinguish these from Email Addresses.

> the preference for people here seems to be with 'Show' rather than 'View' in > the context menus Sorry. `View {x}' is for things which replace the contents of the current window or open a new window, e.g. `View Source' or `View Only this Image'. `Show {x}' is for things which do not, e.g. `Show Images' or `Show/Hide'. > Page content area _View Background Image has a different shortcut Thanks for spotting that. I've fixed it. (The updated version should appear on mozilla.org in an hour or two.) > there are too many Copy items in each menu La la la, don't say I didn't warn you. But yes, the vanilla `Copy' item should be disabled in the usual case where nothing is selected. > Give some thought to renaming Copy Image Address and Copy Link/Frame Address > to Copy Image Location and Copy Link/Frame Location. I have, over the past couple of years. Deciding factors included (a) the fact that `Copy {whatever} Location' sounds like it would copy the text `182 pixels from the left, and 60 pixels from the top', (b) the fact that I have *never* heard anyone (whether using Netscape or not) speak of a Web address as a `location', and (c) the fact that even Netscape Navigator's online help has to repeatedly explain that by `location' they really mean `address'.

You haven't answered my query about 'email' vs 'e-mail'. :-(

Regarding "e-mail", a supervising copy chief at the Washington Post devotes 3 pages to "E-mail vs email" in his book (ISBN 0-8092-2535-2), which is very interesting and at times humorous, and I definatly recommend. My previous comment (#80), copied a few examples from his reasoning. Another quote: "No initial-based term in the history of the English language has ever evolved to form a solid word". Also mentioned somewhere (maybe it was his web site), all long running, professionally produced computer magazines use the hyphenated spelling. Just checked infoworld and PC magazine which I had laying around, both I found "e-mail" throughout. Besides all of that, it's just plain easier to read and nicer looking. A seperate bug should be filed to have it changed globally.

> Another quote: "No initial-based term in the history of the English language > has ever evolved to form a solid word". Well, this one has. :-) It seems like the natural evolution of words to get shorter and more abbreviated over time, so that makes 'email' the more evolved form of the two. Then again, 'Wired' magazine did switch from 'email' to 'e- mail'. Personally, I use and prefer 'email' but I'm not about to try and enforce my personal preference on everyone else. However, the term used throughout the UI currrently is 'email' so we should stick with that until a decision is made to change it globally (if this decision is taken at all).

Changing bug url from http://mozilla.org/projects/ui/communicator/framework/contextmenus/ (outdated) to http://mozilla.org/projects/ui/menus/shortcut/.

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

I still persist thinking that the new spec for context menus are not user friendly. There are many points in my comment 55 and updated comment 61. But if there were only one thing to discuss, it would be the foolowing. Mpt's current specs can not bookmark nor save a page made of frames. The FAQ in http://mozilla.org/projects/ui/menus/shortcut/ answers: "Those shortcut menu items are for saving or bookmarking the current frame, not the page — they just happen to save or bookmark the whole page if you’re on a page which only has one frame. If you want to save or bookmark the whole page consistently, use the File or Bookmarks menu" Do you really think that the average user know what is a frame? In the majority of the cases, he/she will just want to bookmark the whole page. With the current spec, the user will think: context menus work in some sites, not in others. Can anybody argue that he/she will not be disappointed when trying to bookmark a page with frames if the current specs are implemented? This is imho a severe usability failure.

Just an fyi in regards to the frames issue. There will be a new frames model in XHTML 2.0 that will assist in solving the navigational issue and bookmark issue. A new scheme for the frameset/frame URI is being recommended. The new URI scheme will contain a unique sequence of values that will in turn point to the current state of the frame contents. Until then, resolving that issue is probably not realistic.

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

> Mpt's current specs can not bookmark nor save a page made of frames. > This is imho a severe usability failure. I disagree. Bookmarking a page from the menus or the toolbar is both easier and more discoverable. Your average user will bookmark pages from there. Context menus, as stated in the spec, provide functions which are impractical to implement in a non-contextual fashion. Page bookmarking is easily provided in the menus and toolbar. It does not need a context menu item. Bookmarking individual frames, however, would be poorly presented in the menus. Page bookmarking is only provided on non-frames pages for consistency with frames: I bring up the context menu on a page and bookmark that page--the one I'm clicking on--whether or not it's part of a frameset.

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

Document inspector is now part of the default builds, and before it was switched on, it had an entry in the context menu. This inspected the very object you were just 'contexting'. I'd like to suggest adding that context menu back, or at least have it as pref. (If that's at all possible, I didn't care about overlays too much yet). This is a cute alternative to bug 28809, as well. Knowing what Mozilla thinks it has at a particular element is a great thing for QA, though I'm not sure how much regular users like it. That's why I suggest a pref.

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

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

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

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

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

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

Hello, posting a revision to German's original CM spec. Any feedback would be appreciated at this point - you have until Jan 1, 2002 to do so. After Jan 1, after all feedback and issues are gathered, a second/final draft will be posted. This spec covers nav and chrome only. Please remember, this is a first draft/worksheet document, and does not yet cover all of of the details in this bug, or its dependencies. thanks for your help. http://www.mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2.html

Marlon, I haven't had a chance to examine what you've posted, but I assume that it takes into account all of the discussions and revisions that have taken place in this bug, right?

2 quick points after reading the draft: - in the news context, I didn't see any 'open news in New tab' (cf bug 110065, which should perhaps bve added to the dependency list). - for images: what does 'view image' means? Could we have view image in a new tab, like we have in the image as link section I found the coloring '[less | highy] expendable' disturbing, i.e. not well ordered. E.g. in 'Selected Content Menu', where I would have add: Copy and Search more expendable than the rest. And many more. But that's perhaps related to my specific usage of the browser. I use perhaps different features than the usual user. Last but not least, I was wondering if would be possible to open the context menu so that the mouse would be centered on the menu (if it is possible). This should be an option (not by default) but I see it as a possible way of accessing menu faster thus make menus a little bit longer. There is probably a known bug on that, but I didn't find it. Any feedback?

Marlon! Yes! current context menus must die! Some suggestions: 1) Inconsistency between To and to: s/To/to 2) Inconsistency between Properties and Info for Page and Frame: s/Info/Properties (even if it differs from 4.x) 3) Do not remove item 'Block images from this Server' for Mozilla. 4) Add 'Send Email' in 'mailto:' context menus. Because some users will prefer to have a 'branded' confirmation that they can send Email instead of lclicking on a link without being sure what will happen. rclick, click outside context menu then lclick is a bit long. 5) News:Link and Mailto:Link need rewording for clarity sake. The following suggestion will hurt: 6) Follow Opera wording: s/Tab/Page. It is a coherent wording, it is much clearer and simpler and finally, it avoid confusion between sidebar and browser tabs. But no need for s/<tabbrowser>/<pagebrowser>, please! ('Tabbed browsing' could be sth like 'Multi-page browsing' i.e. sth that does what it says) Btw, since the question will be raised, I prefer the proposed simple 'Add to Bookmarks' instead of the technical 'File ... bookmarks'. There are too many ways to bookmark a page. (I filed bug 116003, btw)

pierre: please don't rename tab to page. This is confusing imho... a display doesn't contain "pages" And I also prefer File Bookmark to Add to Bookmarks, because the former indicates that I can choose the folder where I want the bookmark to be in.

I have to confess that when I saw Page instead of Tab in the Opera context menus, it confused me. That's because I was used to this wording. I realized that I could not find something that would differenciate a tab and a page. If a display does not contain any page, so why in the menus, there are items like 'Save Page As', 'Page Info', 'Send Page', 'View Page source', 'Edit page in composer', etc...? Furthermore, in tabbed browsing, these items apply to tabs: there is an obvious wording inconsistency. File/Add: simpler is better. Add bookmark should always give the possibility to select the folder (*AND* position inside the folder). The current 'Add bookmark' should be drop and replaced with the 'File bookmark' widget or suggestion in bug 116003 (that may not be optimal, that's not the point here) And 'File Bookmark' renamed to 'Add bookmark'

pierre: Sure, a page is displayed... but a tab contains a page (as does a window). These items do not really apply to the tabs, but to the currently displayed page (which sometimes happen to be inside a tab). With your argumentation, you could also rename "Open in new Window" to "Open in new page", because a new page is also opened. As for dropping Add Bookmark in favor of File Bookmark: I like being able to add a bookmark _without_ going through a dialog, ie. simply clicking Bookmarks/Add.

I'm confused. Is this dueling UI specs? The one Marlon posted seems to have little in common with MPT's. In general, I find MPT's much cleaner and clearer. The context menus are more specific to the context. I appreciated the comparison with the other browsers in Marlon's. Some specific concerns: I found carrying around the Add Page To Bookmarks, Send Page, Save Page As, and Print Page items on basically every context menu in Marlon's to be unnecessary and confusing. Context menus should not have submenus, and the Frame submenu is especially problematic. It moves the Open Frame in New Window from being quickly accessable to quite hidden, and eliminates the View Only this Frame item. The mailto: context menu needs a way to Send email and make it too easy to add to address book. In both specs, Page Source should be View Source, as that's what it's been called forever (Nav 4 and IE use this term). I keep reading page as a verb and get confused. I'd suggest that Page Properties could be simply Properties. I don't mind being specific in other contexts (Frame, Image, etc.), but find it unnecessary and confusing here. Where is the appropriate place for this feedback?

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

Why is mpt's spec being ignored? It's had over five months of commenting and revisions. Now you give less then two weeks for comments on a completely new spec, which suffers from problems mpt had already eliminated? Also, as there is very little rational for some of the changes and differances from mpt's version (other then the vague "Menu Design Principles"), the answers to some of my comments call for an explanation. I'm posting this here, as I don't have news access. > Content Area Menu Are Reload and Stop really necessary in the context menus? IE5.5 gets by without them. Stop is fairly useless in a context menu anyway, since context menu rendering is generally blocked while a page is trying to render. Send Page and Add Page To Bookmarks are NOT often used items, and are NOT context sensitive. The file menu is fine for these Save Page As and Print Page are NOT context sensitive, and for many users, print is NEVER used, and for most others, it is rarely used. I'd like to see Page Info made more functional, which would eliminate the need for View Background Image. Create Desktop Shortcut is Alias in Finder for mac. What about Linux, Solaris, etc? Is the menu item removed entirely? I don't see KDE, GNOME, and CDE integration being added, so I think it should be removed on those platforms. > Selected Content Menu I like having this a separate menu, a lot. Cut? Paste? This isn't an input field. What are these for? Size parity with input menus? Having 33% of the menu permanently disabled is a bit too much in the way. Copy is useless for X. If the text is highlighted, it's already copied. It's quite annoying currently having all these useless CCP menu items on Linux Mozilla. Let's fix it. "Send selection as quoted...". This might be useful, but I haven't the slightest clue what it does. Who or what am I sending the selection to? Looking it up as a URL? Searching on it? E-Mail? (which I just thought of, after a long period of puzzlement.) If that's the case, it needs to be reworded to say E-Mail. Selection Source would be very nice, but is the code in place to do that by 1.0? We don't want useless UI in for the big release. This is also poorly worded, wasn't sure what it did at first, and second, glance. There's no print here. I hate print in the context menus, but if you have it for the normal page area, you need it here too. You can't expect users to go looking for it in the context menu only some of the time. Expose "Print Selection", or, preferably, remove Print from the Content Area menu. > Text as Link Menu The default action, 'Open', isn't listed. Similar to your Design Principle #6, menus are used to figure out what something is and what it can do. Windows users (and perhaps GNOME, KDE, and Mac as well) are used to seeing the default action at the top, in bold. This is very useful. It lets you find out what will happen if you right click something, and it also is there in case you were first going to open in a new window, but changed your mind. You don't have to click away, and then back on the link. I think we have way too much Global context here. Does this menu apply to form submission as well? There is a dependent bug that wants this. mpt's menus implement this nicely are used to seeing the default action at the top, in bold. This is very useful. It lets you find out what will happen if you right click something, and it also is there in case you were first going to open in a new window, but changed your mind. You don't have to click away, and then back on the link. I think we have way too much Global context here. Additionally, Send Page, Save Page and Print page could easily be confused with operations on the LINK. I'd like to see it all ditched. If the menu is small enough, the Link Properties on the bottom will stand out more and the user will clearly see they're in the link menu, and they can quickly click another spot. Does this menu apply to form submission as well? There is a dependent bug that wants this. mpt's menus implement this nicely. It doesn't seem to me Copy Link Location and Select All should be grouped together (if Select All must stay). Copy Link Location pulls /data/ from the page source. Select all deals with copying the normal content you see. I understand they're both CCP, but they function very different, and I think users, novice and advanced, are only confused and slowed by having them grouped. Was 'copy' consciously removed from the link menu? I'm pretty indifferent on it, especially since I think it's function was/is vague. > Image Menu If "Copy Image" isn't going to work on X, can the item be removed? "Set as Wallpaper" should be removed as well, unless CDE, GNOME, and KDE integration are added. In your comments, you have " ? why have [select all] here? (removed)", yet it's still in the above Link menu. "Create Desktop Shortcut" should also be removed on platforms it's not integrated. What happened to image blocking? There's no other easy access, so this should be in the image context menus. I'd also like to see stop animation on images menus, since it isn't exposed anywhere else. > Image as Link Menu Again, no "Open". Why are we calling the bottom entries link properties and image properties, but then page /info/? Yes, the dialogs look different, but a page is a more complex object, so its properties dialog is more complex. It would be more consistent to call the bottom item $object properties always, info throws it off. > Text as mailto: Link Menu / Text as news: Link Menu No default action again for these. Is "Add to Address Book" / "Subscribe to Newsgroup" removed if mailnews isn't installed? Until third party mail/news/address apps are supported, it shouldn't show up. Select All is back. > Form/Input Field Menu (rough draft) I don't know how great an idea /auto/ spell check is. Either way, this doesn't apply to Moz as we have no spell check (yet). > Frame Content Area Menu No 'Show only this Frame' function. Only 'Open frame in new window', which I hate, for more reasons then new window perf being a joke, but that doesn't help. The other menus are just combinations of the above, so suffer from the same problems. Also, the 60+ dependencies need to be sorted through, and eaither WONTFIXd, or fixed them in this spec.

I have to say that "this is a first draft/worksheet document, and does not yet cover all of of the details in this bug, or its dependencies" (from marlon's post) basically sums up the problem. As things stand, we are going to spend all the time until Jan 1 simply reiterating what has already been said in this bug and its dependencies. Could we just skip this pointless waste of everyone's time and have Marlon create a draft that _does_ take into account all the discussion that has happened thus far, _then_ talk about it? I've got some comments on the spec and on replies to it, as do we all. But I feel that I would simply be cluttering up this bug if I were to launch into an item-by-item restatement of what has already been said so many times.

One other thing (this applies to both specs). "Open in new tab" is missing from both specs. While I do not mourn its loss, many others will, so I wanted to check that this was a conscious decision on the part of the spec designers and not an oversight.

Let's take this discussion to the UI newsgroup. Having dual specs is a bad situation, but that started with MPT (and everyone else, not his fault) not being able to find the original to modify, and innocently posting an unrelated alternate instead. We must get back to having one spec that is a natural progression in the evolution of our menus. Marlon has been incorporating solutions to the main issues raised since the original context menu spec was published, including the key points of MPT's spec. In fact, I thought (hoped!) they were already collaborating on the next version.

I tend to agree with Jeremy; mpt's spec had a clear concensus and it has already had the "evolutionary progress" it needs to be able to use it. It's silly to ignore that spec, when it has been done and agreed upon for months. I don't see a good reason in this bug for why we should *not* use it... It's unfortunate to see Marlon reinvent the wheel with this new first draft.

It was MPT's spec that ignored evolution, through no fault of his own. The spec Marlon posted is not a first draft of a new spec, it is a revision of the current approved spec that attempts to address the most important issues that have come up, while respecting the evolution of the product. In fact, they both agreed to this plan, and promised to work together to make it happen. They are both responsible for the end result, so I'm confident that the next version will be a descendant of both previous specs, one that we can build consensus around and implement.

Matthew told me last week that they forgot to call him in to the meeting about this spec. As far as I know, he haven't contributed to this spec... but I'll let him speak for himself.

See also an entry about this, from mpt's weblog: http://mpt.phrasewise.com/2001/11/13

There have been several meetings about this spec, and as far as I know, no decisions were made on any part of it unless MPT was present. At the meetings I've attended, we've always tried to call him. The weblog entry you cite is from 5 weeks ago. I spoke with him this week, and he agreed that the merged spec already addressed his most important concerns. It has an approach that is less object-oriented, more in line with past versions and the current regular menus, which we agreed was different, but a valid approach. There is still plenty of time for them to get this spec right, as implementation is not as high priority as other work that needs designing.

Thanks to fantasai for pointing me back to this bug when I really thought I'd finished with it. :-] Though it was very early in the morning, I'm pretty sure I didn't tell Peter that `the merged spec already addressed [my] most important concerns'. Marlon's document is not a `merged spec', and nor is it a revision of the old Netscape spec; it bears very little resemblance either to the old spec or to the new Mozilla spec which all of us (except Marlon) have worked out over the past five months. And in my opinion, Marlon's design is considerably less usable than *either* of those two specs, given its internal inconsistency, external inconsistency, complete lack of access keys, and use of submenus. (A simple example of inconsistency is that the shortcut menu for text fields in every other Windows app -- including both 4.x and Seamonkey -- teaches you to find `Copy' as the third item down, but Marlon's design has `Cut' there instead.) A Pixeljockeys meeting discussed Marlon's document about eight hours after it was published on mozilla.org. I was not dialled in for that meeting, though I'm prepared to apply Hanlon's Razor there; nevertheless, I regret to say I see nothing useful in the document which gives me cause to change the current spec.

like to add info on 'cleanup' (as in needs to be fixed) see bug 109856 for a fix for dual seperators present in many recently nightly builds for the browser, which most likely work for message pane.

Matthew: the term 'merged spec' was mine, but you most certainly did agree that it addressed your most important concerns, I have notes on that. You also promised weeks ago, in front of several witnesses, to work with Marlon on the spec, but you have instead continued to conduct a campaign against it in the newsgroups and bugs. You share responsibility for the end result, especially if you refuse to contribute to it. As to dialing in to the meeting, we call you as a courtesy, to save you the cost of dialing in to the toll-free number we provide for everyone else. You could have called in for a minute, to remind us, if you'd wanted. I apologize for not being able to get through to you that morning, but no changes or decisions were made due to lack of quorum.

Can I ask for a point of clarification? This is mpt's spec: http://mozilla.org/projects/ui/menus/shortcut/ Marlon recently linked this: http://www.mozilla.org/projects/ui/communicator/framework/contextmenus/ cmrev2.html But Matthew's November post links to this Netscape originated spec: http://mozilla.org/projects/ui/communicator/framework/contextmenus/ The impression I get from reading these comments is that Matthew is talking in the context of all 3 of these specs, whereas Peter, you seem to be aware of only two of them. Of course, I could be wrong. While I'm not in position to know what anybody said or though - the impression I have is MPT could live with (and was sometimes speaking about) the older netscape spec, whereas Peter, you seemed to assume (perfectly reasonably) that he was talking about Marlon's much more recent spec. This might explain some of the contention, if I'm correct in my guess. Thanks...

... bugzilla wrapped the URL to Marlon's spec. Be careful, it looks like I linked to the same thing twice but I didn't...

Hrm, let me explain what just happened so you don't think I've gone mad and decided to spam you all to death: It seems Navigator 4 has a bad habit of trashing the blockers and dependencies when the lists get too long. Should have been simple to fix, but unfortunately it seems Bugzilla has been upgraded to spot circular dependencies (ie, bugs depending on each other in a loop). So to get the bugs back in I had to paste them in almost one at a time :( Also that means I can't add these two back in, as Bugzilla will not let me: bug 114552 and bug 103064 Sorry for all of the junk email, but trust me, I didn't enjoy spending half an hour fixing this. The UI for dependencies sucks...

For those of you who (like me) are finding this confusing, the story so far: 2001-04-09 20:36: Blake files a bug asking me to come up with a spec for Mozilla's shortcut menus. 2001-04-20 20:38: lordpixel files a bug asking me to come up with a spec for Mozilla's shortcut menus. (All right! All right! I'll do it!) 2001-07-05 10:08: After a considerable delay (for which I am sorry), I post a draft spec and ask for comments. 2001-07-08 09:25: I post to n.p.m.ui, asking anyone interested (including Netscape UE) to contribute feedback on the draft spec. 2001-07-08~2001-11-06: The spec is revised numerous times in response to feedback from people both inside and outside Netscape, to the point where I think it's as good as it can be -- that is, I do not think it could change in any respect without the change annoying more people than it pleases. The spec is implementable from this point. 2001-10-03 22:59: Peter Trudelle files bug 103064 to make the shortcut menus even longer. Gerv (among others) realizes that bug and this one are on a collision course, and either he or Sarah (I don't remember which) arranges for it to be discussed at a Pixeljockeys meeting. 2001-11-something (sorry, my e-mail archive doesn't go back that far): Marlon posts a critique of my spec to the Pixeljockeys list, along with a list of principles he would use if he was designing the shortcut menus. 2001-11-15: I am dialled in to a PixelJockeys meeting which discusses Marlon's principles vs. my principles. 2001-11-19 14:28: Lori Kaplan posts minutes of the Pixeljockeys meeting to the Pixeljockeys list. The minutes include various perplexing claims, such as (1) `Context menus are not ranked as a P1 in the PRD' (see also bug 75371 comment 118 to 120), and (2) `it was agreed that ... it's o.k. when necessary to have one level of submenu' (I distinctly remember my response to that suggestion being `no, never'). It also says that `Marlon and mpt [will] define a spec and disseminate for review by pixeljockeys'. 2001-11-whenever-I-next-read-my-mail: I read Lori's minutes, particularly that last bit about ditching five months of work and creating yet another spec, and say `what the hell???'. Unfortunately I don't reply, because (1) I'm very busy and (2) the spec's finished anyway so I assume Lori's misunderstandings will get sorted out by themselves. 2001-12-02 16:49: After twice asking why this discussion needs to take place on a private forum instead of in n.p.m.ui, I post a detailed response to Marlon's critique of the spec. I hear nothing from Marlon after that, and assume (ah, assumption is the mother of screw-up!) that the matter is settled. 2001-12-10 19:33: ftang@netscape.com refers to Pixeljockeys as `Pixeljokes'. 2001-12-18 11:51: Out of the blue, Marlon posts a proposal which is completely different from either the old Netscape spec or the new Mozilla spec, and (as he states) does not take into account any of the discussion or dependencies in this bug. A Pixeljockeys meeting is held on this proposal a few hours later; I still don't know what happened at that meeting. 2001-12-19~2001-12-20: A lively discussion breaks out in bug 88918, during which Lori claims both that Marlon's proposal is both `the currently agreed upon context menu spec' and that it is `based on mpt's spec', both of which are obviously untrue. During the development of the new spec, in addition to the comments in this bug, Fantasai, Ian Hickson, and Brian Smith (among others) e-mailed me useful comments and proposals, all of which I responded to, and some of which I used to revise the spec. Marlon sent me a critique much later, which I responded to as well. Later he posted his proposal, but (as I said) I see nothing in it which would be useful to incorporate into the spec. I'm not singling out Marlon here: the same thing happened with Pierre Chanial's proposal as happened with Marlon's. I certainly did not `conduct a campaign against it in the newsgroups and bugs' (a whole `campaign' in three days? gimme a break!), and I resent the suggestion that I `share responsibility' for whatever his proposal contained.

So what now?

I vote that we implement mpt's spec.

> I vote that we implement mpt's spec. I vote *Mozilla* implements mpt's spec, as was agreed apon here and the newsgroups over 5 months, and Netscape implements whatever the hell spec they want, as was agreed apon in a closed meeting in one day. Then we see which way the users flock.

I think it's important that Mozilla and Netscape have the same spec because a UI fork (which is essentially what this would lead to) would just cause more problems and fragment development.

What concerns me is what appears in Netscape's distribution (and other end user releases like RedHat's and OEOne's), not what appears in Mozilla test builds. I believe that we (the Mozilla developers, including those working for Netscape) should implement mpt's spec because it is the better spec for all users. Please let's not make this a Mozilla vs Netscape thing. The proposed specs should be compared based on their merits, not who wrote them.

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

Mailnews context menus need to be compared to the mail menu specs at http://www.mozilla.org/mailnews/specs/threepane/MailMenus.html jglick currently owns that and all changes have to go through her. Some comments on mpt's mail specs. I think you're giving the ability to set message priority to much priority by not making it a submenu. It should be like the labels submenu (of course we have to implement the ability to set a priority first). I also think filing is pretty common and therefore copy and move menus should be included.

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

I have a suggestion. Put a "Load Background Image" menu item in there. It would be used when image loading is off and you want to load the background image, in the same way that "Load Image" is used when image loading is off and you want to load a regular image. I can't count the number of times I've wanted something like this (well, for Mozilla, #84654 needs to be fixed first). Lots of pages have text colored in such a way that makes the text hard to see if the background image isn't loaded.

arfromdee: every single element can have a background -- most actual "page" backgrounds are on the <body> element but some pages put it on the <html> element, and many pages put backgrounds on a <table> or <td> background, some even on a big <div> wrapping the whole page. How would you handle this? And then, how about the backgrounds put on things like <h1> and so on?

I'd think that defining "Background" for the purposes of "Load Background Image" shouldn't be any harder than defining it for the purposes of "View Background Image", which is already in the spec. I'm not sure how that handles backgrounds in tables, <div>, etc. but it obviously has to do something.

Fair point; mpt? comments?

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

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

Concerning the e-mail vs. email discussion: The following applies for the German (and I believe French) language: "Email" is (and has been for decades) a technique to apply metal pulver on a surface and fix it by melting it in an oven. There are "Email-pots", "Email-tubs", and so on. That is why I oppose rather strongly to the term "email", it would be a double-defined term.

To support the last comment #174: http://www.beyars.com/lexikon/lexikon_367.html

Gentlemen, we are talking about the English (US) localisation of Mozilla, so I fail to see how this is relevant. Gerv

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

Ian, arromdee: The readability issue can probably largely be solved by ignoring foreground color when both the background image is not loaded and a background color is not specified at the same scope. Nevertheless, I'd be happy to add `Load Background Image' to every browser menu (and it would have to be every menu, including those for links and text fields, given <a|input style= "background-image: ...;">). However, first you would need to nominate one of the existing items to get rid of, to make room for the new item. The specced menus are too long already; and just as shortcut menus shouldn't be the dumping ground for every minutia of HTML metadata, they also shouldn't be the dumping ground for every minutia of CSS (or presentational HTML) styling.

Ignoring the foreground color under those circumstances would work, but it seems like an awful special-case kludge. I do think that the ability to load a background image in the context menu is important. It's inherently contextual and it just doesn't make any sense to do anywhere else than in a context menu. I'm not sure what item to remove from the context menu, because I don't know which of the three specs in comment 156 is the spec I need to worry about. But if I had to guess, I'd say that an easy place to put "Load Background Image" is simply to have it replace "View Background Image". If the background image is loaded, you get "View"; if it's not, you get "Load". No need for an extra menu slot. (Of course, this means that "Load Background Image" would not be available if you right click on an area of the screen with a foreground image, but I don't think that's a real problem.)

nsbeta1+ per ADT triage team (this work was scheduled for MachV). Blake, is this on the landing page?

I've updated <http://mozilla.org/projects/ui/menus/shortcut/> to recognize windowed browsing vs. tabbed browsing, better explain internal vs. external links, and fix the last remaining XHTML errors. As Putterman suggested, I removed the items for changing the priority of a message. I couldn't add items for changing the label, because the number of items would make the menu unreasonably long. And I couldn't use a submenu, because it would be much less predictable in position -- and therefore slower to access -- than the equivalent submenu in the menu bar, thereby Missing The Point Entirely. (The same applies to Copy Message and Move Message.)

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

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

Adding dependency from duplicated bug 110041 - bug 101794.

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

removing myself from the cc list

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

Hello! Please dont forget that if Tabbed Browsing is activated, the context menus need to reflect it and have the option of (for example) open a frame or link or whatever in a new tab. thx alot! cu Martin

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

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

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

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

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

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 i've made some responses to some of the points of view presented in this bug and it's dependecies which may be at odds with the spec i have produced. A careful look at the design principles at the top of the spec will provide the insight for many of the decisions made, as well taking note of the supplementary 'yellow boxes' which now accompany each menu. I will post many of the responses in their respective bugs, but you can also view a 'digest' of all responses at: http://www.mozilla.org/projects/ui/communicator/framework/contextmenus/digest.html

That looks pretty good overall (though the "open context menu, open submenu, open dialog, hunt for button, click button, get new dialog, close old dialog which you didn't really need" route for getting to "Frame Source" is a little circuitous).

I'm finding it very hard to read this latest spec. What is the different between "the menu" and the "core set"? What does an 'expendable' context menu option mean (although thats more relevent to the previous versions of teh spec than this one, which doesn't really use that) I'm also a bit confused with some of teh items on the menus, for example, the selected text menu: Why does the menu whch comes up when text is higlighted have an option to higlight text? "Search dictionary for 'foo'" - do we have that functionailty in teh backend? Where did that suggestion come from? I'm also not sure that we have the backend to 'view selection source' - what does that even mean? Show part of view source? Send quoted selection seems to me to be an obscure edge case, even more so than send page, which I agree with mpt that it shouldn't be on the context menu at all. I presume those options aren't shown if mailnews isn't installed, and teh search option (which again, I think is really an edge case - how often do you select something for teh sole purposes or searching for it?) isn't shown if there is no default search engine.

Search dictionary for "foo" should be at least as easy as searching for "foo" in the selected search engine. It isn't too hard to set up a personal internet keyword that uses dictionary.com to look up "foo" when you type "lookup foo" in the URL bar. "how often do you select something for the sole purposes or searching for it?" All the time. This is one of the top 10 best features of mozilla.

marlon: any chance we could have a condensed version of your spec in the same form as http://mozilla.org/projects/ui/menus/shortcut/ ? That would aid reviewers and QA. Thanks!

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