Closed Bug 75338 Opened 23 years ago Closed 22 years ago

Clean up context menus for Navigator/Messenger content area

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: bugzilla, Assigned: bugzilla)

References

(Depends on 1 open bug, Blocks 3 open bugs,
URL
)

Details

(Whiteboard: [adt3] landing monday, april 1)

Attachments

(13 files)

3rd draft of proposed context menus
13.50 KB, text/html
Details
3rd draft of context menu overview
13.50 KB, text/html
Details
4th draft, with accesskeys -- please report any clashes or inconsistencies
16.01 KB, text/plain
Details
4th draft, with accesskeys (with correct MIME type, this time)
16.01 KB, text/html
Details
Responses to comments from Gerv, Alex, Warner, Timeless, and Peter
5.51 KB, text/plain
Details
5th draft: fixes errors noted by Gerv, and adds `View Background Image' and `Show Menu Bar' which I had forgotten
16.83 KB, text/html
Details
Same spec, but made valid and with tests for the first part
17.90 KB, text/xml
Details
let the cleanup commence
15.72 KB, patch
Details | Diff | Splinter Review
Alternative action-driven proposal for Navigator
6.79 KB, text/plain
Details
Draft 5 edited so that the menu structures are extremely consistent
14.17 KB, text/html
Details
Response to comments on my revised version of MPT's 5th Draft
13.59 KB, text/xhtml
Details
TEXT/HTML version of new revision
13.53 KB, text/html
Details
Another Revision
13.97 KB, text/html
Details 
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. :-)
Assignee: blakeross → mpt
Blocks: 10723, 24107, 25071, 26939, 27338, 28605, 32353, 32358, 35130, 36866, 47475, 47743, 48789, 54149, 54300, 62155, 62315, 63054, 63823, 64749, 67239, 67544, 67547, 67571, 68928, 70990, 72611, 74019
Component: XP Apps: GUI Features → User Interface Design
OS: Windows 2000 → All
QA Contact: sairuh → zach
Hardware: PC → All
Summary: Clean up context menus → Clean up context menus for Navigator/Messenger content area
adding bug 73322 -- "[rfe] Image resize" to depends list.
Blocks: autoresize
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
Depends on: 73847
ping pong.  Any hope for this soon?
Blocks: 85411
An old version of mpt's spec is attached to bug 26939 as attachment 20873 [details].
Blocks: 85556
We really need to tidy up the contextmenus some before 1.0

Mpt, what's the status on the spec?
Blocks: 41526
<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 :).
Blocks: 72008
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>.
Status: NEW → ASSIGNED
Blocks: 64563
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.
Assignee: mpt → blake
Status: ASSIGNED → NEW
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.
Blocks: 92902
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...
Depends on: 15176
No longer depends on: 15176
Depends on: 15176
No longer depends on: 15176

    
    

    
  
*** 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.

    
  
Target Milestone: --- → mozilla0.9.6

    
    

    
  
"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.

Blocks: 889
No longer blocks: 88950, 92902, 99710, 102629, 102634, 102636, 102639, 103064

    
    

    
  
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.


    
  
Blocks: 105580

    
    

    
  
>> 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.
No longer blocks: 889

    
    

    
  
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.

    
  
Whiteboard: [Aufbau-P4]

    
  
Whiteboard: [Aufbau-P4]

    
  
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
    

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

    
  
No longer blocks: 27338

    
  
Depends on: 27338

    
    

    
  
*** 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).

    
  
Blocks: 88950, 99710, 102629, 102634, 102636, 102639, 103064

    
    

    
  
*** 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.


    
  
Blocks: 105407

    
    

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

    
  
Blocks: 93390
No longer blocks: 70830

    
    

    
  
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. ***

    
  
Target Milestone: mozilla0.9.7 → mozilla0.9.8

    
    

    
  
*** 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...

Blocks: 855
No longer blocks: 85556, 88918, 88950, 92901, 92902, 93390, 99710, 102629, 102634, 102636, 102639, 103064, 104380, 105407, 105580, 109171, 113890, 114552

    
    

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


    
  
No longer blocks: 855
Depends on: 85556, 88918, 88950

    
  
Depends on: 92901, 92902, 93390, 99710, 102629, 102634

    
  
Depends on: 102636, 102639

    
  
Depends on: 104380

    
  
Depends on: 105407

    
  
Depends on: 105580

    
  
Depends on: 109171, 113890

    
    

    
  
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.
Blocks: 855
No longer depends on: 85556, 88918, 88950, 92901, 92902, 93390, 99710, 102629, 102634, 102636, 102639, 104380, 105407, 105580, 109171, 113890

    
    

    
  
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. ***
Blocks: 85556, 99710, 103064
No longer blocks: 855

    
    

    
  
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. ***

    
  
Target Milestone: mozilla0.9.8 → mozilla0.9.9

    
  
Status: NEW → ASSIGNED
Blocks: 120936

    
    

    
  
*** 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.

    
    

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

Gerv

    
  
Keywords: nsbeta1

    
    

    
  
*** Bug 24221 has been marked as a duplicate of this bug. ***
No longer blocks: 70990

    
  
Target Milestone: mozilla0.9.9 → mozilla1.0

    
    

    
  
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?
Keywords: nsbeta1 → nsbeta1+

    
    

    
  
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.
Blocks: 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. ***

    
  
Whiteboard: [adt3]

    
  
Blocks: 114972

    
    

    
  
*** 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. ***

    
    

    
  
boris:  noted circuitousness of view frame source - perhaps the frame 
subset could bring back the [frame source] item  to get you there quicker.  
as with any space cutting measure, some things are going lose 
convenience.  frames is one i think can and should.

bradley:  what are you finding hard to read about this spec?  the "menu" vs 
"the core set"?  this is simply a way to prioritize menu items for nested 
contexts.. you needn't really worry about what "core" items are, unless you 
care to investigate how i arrived at the other menus... please read the 
design principles section which explain this method a bit more in detail


>Bradley Baetz wrote:
>Why does the menu whch comes up when text is higlighted have an 
>option to higlight text? 

an idea from bug 105580, which would be useful for some research 
oriented situations when viewing long text documents.  If it comes at little 
or no expense it would definitely be a 'nice to have'


>"Search dictionary for 'foo'" - do we have that functionailty in teh backend? 
>Where did that suggestion come from?

also from bug 105580, and i think it's a great idea.. I don't think we have 
support for it in the backend, but i included it because the spec is about 
organizing bugzilla feature requests in some useful fashion.  So if a 
contributer comes along and decides to do it someday, he/she would 
know where it belongs.  it's okay if something can't realistically get 
implemented,  it doesn't break the design of the menus take an item out.  
actually, it *helps*.

>I'm also not sure that we have the backend to 'view selection source' - 
>what does that even mean? Show part of view source?

yes that's what it means.  - bug 105580


>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.

actually i don't think it's an edge case, i think people generally copy and 
paste things from webpages into emails quite frequently.  this feature 
would allow users to do it in good form.

>I presume those options aren't shown if mailnews isn't installed,

that would be a safe presumption

>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.

even if all of these _were_ edge cases, the Selection Context Menu is one 
of the only menus which could afford such luxuries..   These are features 
that bugzilla users have been muttering about throughout bugzilla, i don't 
myself believe they are edge cases, and if we can afford them in this 
menu i think it adds richness and value to the product .

Hixie: Sorry, if the layout is a bit overwhelming, i don't have time to do 
another one right now. perhaps i will try to add better navigation to the 
current one. 


    
    

    
  
> bradley:  what are you finding hard to read about this spec? 

Hmm. When I looked there wer eno colors on the core set. Maybe that was me.

Re selected text, maybe I'm just confused. If I have some higlighted text, and
then right click on the higlighted text, what is a menu item saying "highlight
text" meant to do? Its already highlighted.

The associated note says:
"* RFE [Highlight Selection >] Would produce a color picker which allow user to
highlight content on a page."

a) a color picker off a context menu seems a bit confusing for a web brower, but
b) Even after having read that, I'm still not sure what it does? Highlights all
the places the selected text appears on teh same page? the same frame? Other
frames in the same window?

It just seems like a confusing option. Is this something which is wanted enough
to make it present in a context menu, as opposed to the tools/tasks/whatever its
called menu?

Similarly for 'view partial source' - is that really a common option?
(especially since the functionality is only really used by web developers, and I
suspect that dom inspector is the more powerful option for this, basically as an
inverse of the "selecting a node puts a red box arrund the content")

OTOH, the features aren't there to have the context menu hooked up, so for
mozilla1.0 it doesn't make a difference.

    
    

    
  
> >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.

> actually i don't think it's an edge case, i think people generally copy and 
> paste things from webpages into emails quite frequently.  this feature 
> would allow users to do it in good form.

What's wrong with copying and pasting the text into an email?  If it doesn't
format nicely, that's a problem with the copy and/or paste function. 
Nonetheless, this is something that could go on the menubar, not in the context
menu.

> even if all of these _were_ edge cases, the Selection Context Menu is one 
> of the only menus which could afford such luxuries..   These are features 
> that bugzilla users have been muttering about throughout bugzilla, i don't 
> myself believe they are edge cases, and if we can afford them in this 
> menu i think it adds richness and value to the product .

The functions may add value, which can be open to debate, but I think placing
them in the context menu removes value.  They should go on the menu bar, if they
appear anywhere at all.

    
    

    
  
"Highlight" is available in IE (with the powertools installed) and does exactly
what it says: Highlight the text as if the user had taken a highlighter pen
and... highlighted it. For lack of a better desciption. 

"View Partial Source" is similarly also available in IE with powertools, and it
shows the source for that range. I'm not sure if it shows the original source or
the post-DOM-changes source, but I hope it's the latter otherwise it would be
rather hard to implement.

marlon: Since you are considering feature requests for this spec, you might be
interested in bug 131542.

    
    

    
  
I would think that if you're one of those users who needs easy access to the
source of a page, you'll need equally easy access to the source of a frame, the
latter being much more useful (generally) on a frameset page than the actual
page source (which would be the outermost frameset).

    
    

    
  
Marlon, I count only 48 obvious usability problems in this second proposal, 
which is an improvement over your previous attempt. (I'm not counting typos, 
poor item wording, or the 130 items missing access keys.) But at the same time, 
there are several major new mistakes -- a couple of obvious examples being the 
position of the `Show All Toolbars' item (making the position of *every other 
item* inconsistent when any toolbar is hidden), and hiding frame items in a 
submenu (as Jag said, half the point of using the shortcut menu here is that 
the frame-specific items aren't accessible in the main menus). As it is, even 
when access keys are added, it seems to me that your latest design would still 
be (on average) be about 50 to 100 percent slower to use than the current spec.

    
    

    
  
just a little user feedback..

"Copy Link to Image" *blink*

"File Bookmark for Link ..." File bookmarks? I don't file them, I _Add_ them /me
nods knowingly

"Copy Link to _this_ Page" *blink blink* /me looks oddly at the urlbar

Messenger - > Thread Pane. Labels purty /me nods twice. Erm, where did
properties go!?

    
    

    
  
mpt: It would be a lot more help to everyone if you could politely and clearly
list the mistakes you see instead of casually dismissing it.

    
    

    
  
>Matthew Thomas (mpt) wrote:
>a couple of obvious examples being the position of the `Show All 
>Toolbars' item (making the position of *every other item* inconsistent 
>when any toolbar is hidden), and hiding frame items in a submenu 

This item belongs at the top of the Content Area Menu under the 
circumstance of the file menu bar being hidden.  all other missing 
toolbars can be turned back on once you get that back.  so i should 
probably made the term actually, "Show Menu Bar" instead of "Show All 
Toolbars"

I also should have made the following caveats - the spec has no access 
keys yet (obviously) and the exact menu item terms are not final until we 
get Sean Cotter (from pubs) to give it a look.

Hixie: thanks for pointing out bug 131542, tabbed browser isn't fully spec'd 
yet, so there might be a some changes to that area of the cm spec.


    
    

    
  
> This item belongs at the top of the Content Area Menu under the 
> circumstance of the file menu bar being hidden.

You make this statement without any supporting rationale. Why could it not be in
the middle? Or at the bottom?

Gerv

    
    

    
  
gerv. sorry for not supplying rationale for that one. btw, if i supplied rationale for every menu item in the bug, it would get rather 
unweildy.  so that is why most of it i've tried to explain in the spec.  

the sheer futilty a user experiences while trying to interact with a chromless browser window i think establishes this postion more than 
anything else.  the goal is to get back the familiar browser UI, what a user understands, if he/she has needs to bookmark, send, save, print, 
etc.,  the only clear choice is to place emphaisis on getting back the hidden contols they are familiar with..  not in expecting users to grasp 
some sort of new submerged user experience which now takes place deep within an entire feature set replicated in context menus.

Blocks: 889
No longer blocks: 88918, 88950, 92901, 92902, 93390, 99710, 101794, 102629, 102634, 102636, 102639, 102875, 103064, 104380, 105407, 105580, 109171, 110041, 113890, 114552, 114972, 120936, 122524, 132626, 133350

    
    

    
  
Marlon, your last comment on this bug seems to have
also somewhat mysteriously clobbered the end
of the deps list:

marlon@netscape.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|88918, 88950, 92901, 92902, |889
              nThis|93390, 99710, 101794,       |
                   |102629, 102634, 102636,     |
                   |102639, 102875, 103064,     |
                   |104380, 105407, 105580,     |
                   |109171, 110041, 113890,     |
                   |114552, 114972, 120936,     |
                   |122524, 132626, 133350      |

    
    

    
  
Attempting to restore dependencies (iirc NS4 doesn't deal with long 
blocks/depends on lists and clobbers them....)
Blocks: 88918, 88950, 92901, 92902, 93390, 99710, 101794, 102629, 102634, 102636, 102639, 102875, 103064, 104380, 105407, 105580, 109171, 110041, 113890, 114552, 114972, 120936, 122524, 132626, 133350
No longer blocks: 889

    
    

    
  
oh really sorry about that...  i'll try to remember not to use 4.x

    
    

    
  
An update: it would be foolish to minus this now; the work is done and pending
review.  It will be in the tree by the end of the day today (Monday).
Whiteboard: [adt3] → [adt3] landing monday, april 1

    
    

    
  
The tree was closed for 3 days last week by patches that were "ready" to land. 
We're no longer at the point where we can take things just because they are coded.

I don't see a patch in this bug, so I can't tell how much has changed.  Assuming
that there are a number of changes, have you been able to give anyone a test
build to try out?

    
    

    
  
If it's pending review it should be attached here. 

Also, AIUI from recent email from lori, this change is only going into the
commercial tree. Has this changed?

Gerv

    
    

    
  
At one point last week, the agreement was that menus were going into commercial
only. Then the browser team met and discussed the implementation required. AIUI
they believe the maintenance issues are challenging and recommend not pursuing
this approach. In the email thread on the menus there was further discussion of
the acceptability of implmenting for Mozilla as well. I'm not quite sure where
we stand at this point. I believe we are waiting for review of Blake's patch and
approval from drivers. 

    
    

    
  
These changes were designed, discussed and approved for Mozilla. The possibility
of their going only into the commercial tree was a response to some apparent
objections that now appear to have only been about some related proposals for
changing accel-N, which were not part of any menu spec.  

    
    

    
  
I have to agree with putterman on one thing.  All other concerns aside, could
the patch that is supposed to land today (!) be attached to this bug or
something?

    
    

    
  
note- draft 3 of the spec, upon which this patch is based: (addition of 
access keys) 

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

    
    

    
  
From a very brief look at Marlon's draft, I'm hoping that's for NSCP only.

I don't think there's much point in putting Stop in the context menus, since the
context menu won't render until the page is done anyhow. The normal toolbar stop
doesn't work, so I can't image trying to aim in a popup menu for stop.

For inline image menus:
  Set as wallpaper will not exsist on Linux/UNIX, I assume?
  Can Copy Image and similar clipboard operations be disableable under UNIX?
    They are, as far as I can tell, useless. Maybe if you use Composer, but I,
    and most people, don't. I'd rather set a (hidden?) pref and keep my menus
    leaner.
  Where is load/reload image?
  Where is block/unblock image?

What the heck is "Image as URL Menu"? It's not explained anywhere in the spec or
here, and the menu shown is extremely odd. Back, but no forward, etc.

    
    

    
  
adt1.0.0+ approval for checkin, pending detailed unit testing on all platforms
and r/sr=.

    
    

    
  
> Where is load/reload image?
> Where is block/unblock image?

This is the MachV spec, no?  Will that even do blocking?  "Load image" can still
be useful for cases when the user is accepting images from originating server, I
guess...

> What the heck is "Image as URL Menu"?

This is the menu you get when loading a url like http://foo.org/bar.gif.  In
that context, it could be argued that "forward" is a relatively rare operation,
since there are no links off the page and hence things will usually not get
loaded after the image.  I'm not sure I buy that argument myself; Marlon, is
there another line of reasoning for not having "forward" in the menu?


    
    

    
  
- this spec doesn't consider image blocking features, since netscape commercial
took that out for some reason.

- image as url - is the menu which is produced when the url is an image.
originally i did not see a need for forward in this menu, since result of
arriving at an image URL supposes there could not be further forward navigation.
however, one could enter a new url from which back, and then forward would be
feasible.  I will make an update to reflect this. 


    
    

    
  
> "Load image" can still be useful for cases when

And reload image is very useful, for large pages with dynamic images. It's quite
nice to be able to reload only the one piece of the document you need.

> In that context, it could be argued that "forward" is a relatively rare
> operation

Forward always has been a much more rare operation, in ANY context. It seems
incredibly disorienting to see back without forward though. Consistency would be
ideal for UI.

    
    

    
  
Marking fixed.  File specific bugs about specific issues at this point.  FYI,
the patch for this is in bug 108099.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
QA Contact: zach → sairuh

    
  
No longer blocks: 28605

    
    

    
  
VERIFIED that our menus have changed a lot. (I and others have filed bugs on
issues arising.)
Status: RESOLVED → VERIFIED

    
    

    
  
There are some old bugs on specific issues regarding context menus in 3pane
window. Queried bugzilla for "3pane context menu" phrase and 15 bugs came up.
Since this one is VERIFIED FIXED, maybe those should be reviewed and resolved too?

    
    

    
  
Quoting A previous message:

"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 do have to take exception to this being a Java developer.  How many
of you have browsed any JavaDocs online?  I don't want to print out all
the frames, just the one that has the meat in it.  I want to be able to
*at least* print a frame from the context menu.  It is rediculous and
unintuitive to select the frame and then select print.  I also don't want
all the **** in the navigation panes printed.

Please, Enable the "Print Frame" on the context menu--Java developers
everywhere will thank you.  It makes printing out online JavaDocs much
easier.  It is a valid need, and *quite* common for Java developers.


    
  
Component: User Interface Design → Browser-General

    
    

    
  
disable context menu dose not work

    
    

    
  
> "Save Page As and Print Page are NOT context sensitive, 

Sure they are. The context is "this page."  They make as much sense in the
context menu as "reload" or "bookmark" which also have a "context" of "this page."


> and for many users,
> print is NEVER used, and for most others, it is rarely used."

Stated as an undisupted fact, but with no evidence in support... Could someone
back this assertion up with some sort of evidence, or provide some evidence to
conclusively disprove it?

IMHO, continuing to leave "Print" out of the context menu is absolutely
brain-dead.  

    
    

    
  
More to the point, context menus have to be kept short for usability reasons.
Which items would you remove, in order to add those?

    
    

    
  
(In reply to comment #232)
> More to the point, context menus have to be kept short for usability reasons.

And this assertion is based on what, exactlY? Are there published usability
studies that demonstrate the superiority of shorter context menus?  If so, what
do they establish as the optimal and/or maximal number of context menu entries?

> Which items would you remove, in order to add those?

I wouldn't remove anything to add "Print", personally.  The Mozilla context menu
has already gotten considerably shorter in the past couple of years, but too the
point of sacrificing functionality, and IMO, making it LESS usable, not more.

IE has an incredibly long context menu, but I don't see any rash of complaints
floating about the 'Net saying "IE's context menu is WAY too big!" or anything.
 Now I'm not saying Mozilla needs to replicate everything in IE... but they have
"Print", it's obvious from the number of duplicate bug submissions and comments
that the Mozilla community wants "Print", and I personally think continuing to
leave it out is brain-dead.

Other people have pointed out many reasons why "Print" is a desirable feature,
but just to re-iterate some of the reasons why someone might want to print from
within the browser, and my own experience with how often the scenario comes up:

Programmers:

1. javadoc (I do this all the time)

2. online man pages ( I do this occassionally)

3. tutorials / articles / how-to's (print these quite frequently)

Joe Consumer

1. receipts from online payments (I print all of my online receipts)

2. map-quest / yahoo maps directions (I do this one quite often)

3. confirmations of hotel bookings / airline reservations / rental reservations
/ etc.  ( I don't travel much, but I always print this stuff when it comes up)

Joe Average User:

1. song lyrics

2. especially interesting blog entries

3. use your imagination

In short, I think printing from within the web browser is much, much more
commonplace than some within the Mozilla organization seem to believe.  And I
personally find that when I do want to print, using the context menu is the
fastest, most convenient way to do so.

 

    
    

    
  
>> More to the point, context menus have to be kept short for usability 
>> reasons.
> 
> And this assertion is based on what, exactly?

Ask any usability expert, or read platform UI guidelines.


> Are there published usability studies that demonstrate the superiority of 
> shorter context menus?

Yes, although I wouldn't be able to give you references. I am going on what
experts have taught me over several years.


> If so, what do they establish as the optimal and/or maximal number of context
> menu entries?

My understand is that up to 10 items, preferably no more than 7, is optimal.
(Seven is the number of items humans can, on average, keep in mind at any one
time, so going beyond that apparently dramatically reduces usability.)


>> Which items would you remove, in order to add those?
> 
> I wouldn't remove anything to add "Print", personally.

That's why you're not in charge of UI. :-)


> IE has an incredibly long context menu, but I don't see any rash of 
> complaints floating about the 'Net saying "IE's context menu is WAY too big!"
> or anything.

Usability studies would show that users find IE's menu more intimidating and
less friendly than Mozilla's.


> In short, I think printing from within the web browser is much, much more
> commonplace than some within the Mozilla organization seem to believe. And I
> personally find that when I do want to print, using the context menu is the
> fastest, most convenient way to do so.

Click the frame you want to print and choose File > Print. Or add a "Print"
button to your toolbar (in Firefox, using the customise toolbar dialog; in
Mozilla, using the preferences window). It's not hard...

    
    

    
  
>>If so, what do they establish as the optimal and/or maximal number of context
>> menu entries?

>My understand is that up to 10 items, preferably no more than 7, is optimal.
>(Seven is the number of items humans can, on average, keep in mind at any one
>time, so going beyond that apparently dramatically reduces usability.)

A general psychology rule is that people handle "chunked" information and they
can handle about "5 plus or minus 2" chunked items.  Some people refer to this
as the golden rule.  (In the United States, you'll notice that telephone numbers
are 3 chunks which each have 3-4 digits.)  

How I (and others) translate this to UI is that menus should have no more than 7
chunks in it.  You have to look at the specifics to determine what an item /
chunk is--a group of items such as Back/Forward/Reload/Stop in a browser can be
counted as 1 chunk.  Bookmark/Save/Send page items are NOT one chunk (certainly
not for me).  The other end of this theory is that you wouldn't want a menu with
only 2 items in it.

I don't want to continue this conversation in a bug that is verified as fixed so
I'm stopping now.  If this discussion continues in an open bug, please cc me so
I can participate.  Thanks!

    
    

    
  
> Click the frame you want to print and choose File > Print. Or add a "Print"
> button to your toolbar (in Firefox, using the customise toolbar dialog; in
> Mozilla, using the preferences window). It's not hard...

When it comes to evaluating usability, did you ever consider listening to the
feedback from the people who actually *use* the product??  There is a reason why
there are so many duplicates of the "add print to the context menu" bug, and why
there is so much discussion in the bugs related to the context menu.  People USE
Mozilla, and they find it less usable since the context menu is missing a
"Print" option.


The sad thing is, the natural solution to this debate is something else that has
(IIRC) been shot down by the Mozilla leaders... a UI for users to edit their own
context menu.  Hopefully some enterprising soul will develop an extension /
add-on to do that eventually.

    
    

    
  
> Click the frame you want to print and choose File > Print. Or add a "Print"
> button to your toolbar (in Firefox, using the customise toolbar dialog; in
> Mozilla, using the preferences window). It's not hard...

Also, if you take that assessment to it's logical conclusion, the context menu
should be eliminated altogether, since all of it's features can be accessed in
"not too hard" fashion via keystroke, menu item, or toolbar button.
 


    
    

    
  
I would have to agree with what others have said here about printing frames... 
it is *completely* unintuitive to select a frame and then choose Print. 
Especially since at least on Mac OS X, there is no visible indication on the
screen of what frame is currently selected, so you don't even know if you've
successfully selected something.  Having a "Print This Frame" option (inside the
"This Frame" submenu of course) is the only intuitive way to do this.

    
    

    
  
(In reply to comment #237)
> Also, if you take that assessment to it's logical conclusion, the context menu
> should be eliminated altogether, since all of it's features can be accessed in
> "not too hard" fashion via keystroke, menu item, or toolbar button.

that is wrong. for example, "copy link location" is only available in the
context menu.

Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: