26939 - No "send page" option in browser context-sensitive menu

Status: VERIFIED WONTFIX

(SeaMonkey :: UI Design, defect, P3)

Description

[[e-mail]]

In Netscape (and nearly all other browsers) the context-sensitive menu (i.e.
right-click) for all web pages had a "send page" option.  For some reason
Mozilla is missing it despite the fact that it is present in the "File" menu.
It should be trivial to add.

Comment 1

[troy]

Changing component

Comment 2

[Paul MacQuiddy]

setting sairuh as qa contact, cc:ing lisa in case she cares about send page

Comment 3

[verah (gone)]

Reassigning as per Don

Comment 4

[don]

Move to M21 target milestone.

Comment 5

[Blake Ross]

okay..do we want to do this?

Comment 6

[Bill Law]

I say yes.

Comment 7

[sairuh (rarely reading bugmail)]

ditto.

Comment 8

[Blake Ross]

ok, patch coming up.  How about if the user's in a frame?  Still just "Send 
Page" anyways? (should be a separate RFE for "Send Frame" if that's the case)

Comment 9

[sairuh (rarely reading bugmail)]

re: whether or not to have Send Frame: i think we should have Send Frame in the
context menu (seperate rfe). even 4.x does the wrong thing and have only Send
Page --mozilla and future releases of netscape should do the right thing. imho.

Comment 10

[Blake Ross]

right, but there should be both Send Page and Send Frame, right?  so the user 
can send either the entire frameset or just the context-sensitive frame?

Comment 11

[sairuh (rarely reading bugmail)]

yes, for pages with frames, there should be both Send Page and Send Frame in the
context menu.

Comment 12

[Blake Ross]

Attachment: patch

Comment 13

[Blake Ross]

Attachment: patch without the quirky whitespace

Comment 14

[Blake Ross]

Bill, could you review?  The patch observes cmd_sendpage because that's the 
broadcaster that the item which is overlayed into the browser (by 
mailNavigatorOverlay.xul) observes; the item can't be in the context menu if 
mail isn't installed.

Notes:
* I know that "s" is already used as an accesskey in the context menu.  Pretty 
much every item is.  I'm going to file a new bug shortly to work out the whole 
context menu accesskey mess (many are duplicated).
* I know that this may not be the best place in the menu for this item. (it's 
separator-delimited between the Bookmark/Misc. items and the Save items).  I'm 
going to file a new bug shortly about the arrangement of items in the context 
menu, also.
* QA: when verifying this bug, please ensure that this item isn't in the 
context menu with a nav-only install, and reopen if this bug it is.

Comment 15

[Bill Law]

Looks good except for the nav-only situation:

1. You'll end up with two separators in a row in that situation.  Can you make
the new separator also observes="cmd_sendpage" (I mean, would that work)?

2. I'm not sure the observes="cmd-sendpage" will have the desired affect if it
is nav-only.  In that case, I don't think there is a cmd_sendpage so nothing
would happen as a consequence of the observes=, right?

Would a better strategy be to add this context menu item to the mail overlay (so
it gets added to the context menu the same way it is added to the File menu?

I'm mostly brainstorming here; I don't really know how the "Send Page" is added
to the File menu or how these cmd/observes= things work.

Comment 16

[Blake Ross]

1. very good point, I missed that.
2. I guess you're right; I don't know how to simulate a nav-only install while 
building, so I was hoping this would work.  But what you said sounds right.

Re: putting the item in mailNavigatorOverlay.xul -- of course!  I'm 
stupid...that's the best solution, and I don't know why I didn't think of it.  
Making a new patch...

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Doron Rosenberg (IBM)]

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

Comment 19

[Blake Ross]

Is `Send Page' really one of the top 12 or so commands that the user needs in 
his context menu?

Comment 20

[[e-mail]]

I initially reported this bug.  As someone who is really only a programming
novice, I had no idea that adding this would be anymore than a half day's work
since it already exists in the File menu.  Nevertheless, I still say yes.  Like
it or not, Internet Explorer is the standard for most Windows users.  When they
fire up Mozilla, I truly believe they will expect to see this option available
and their opinion will be affected by its absence.

Comment 21

[Matthew T (active 1999-2002)]

Internet Explorer's context menu contains so many items that there is practically 
no consistency as to where the context menu appears on the screen relative to the 
cursor -- sometimes it appears southeast, sometimes northeast, sometimes even 
southwest or northwest (because it's quite wide, as well as being very tall).

Because of this inconsistency, it is quicker to use the main menus or the toolbar 
for just about everything in the context menu. This defeats the purpose of the 
context menu altogether. Mozilla should avoid this mistake.

`Send Page' is nowhere near being one of the top few commands for users in a Web 
page, so it shouldn't be in Mozilla's context menu. I'm about to attach a draft 
spec (without mnemonics yet) for context menus of the content area in Navigator; 
CCing Timeless.

Comment 22

[Matthew T (active 1999-2002)]

Attachment: Draft spec: Context menu arrangements for Navigator content area

Comment 23

[timeless]

Save Link ...
Save Image ({foo.png}) ...

Be consistent. I suggest that we not do () and instead promise to implement 
status line hints that include urls.

Second, I feel that a cascading menu (I'll work on the spec after my last exam 
today) is more useful than a sparse menu.

Third you didn't address Tables.

Fourth, your menu is a bit inconsistent near the end. My cascading spec should 
be more consistent.

Fifth: 'View Background Image' shouldn't that be 'View Only Background Image'.
Yes I am poking fun. View ... Only ... Image is silly.

<body><a href="javascript:die">...all content here</a></body>

How do I select all?

Add Bookmark is silly.

Bookmark <object>.

You don't have {Show,Hide}Frame. Yes I am poking fun. But who knows, maybe 
someone would want it. Your menu would be more consistent if you did.

You also don't cover selections.

Comment 24

[sairuh (rarely reading bugmail)]

cc'ing additional mailnews folx who might be interested in this...

Comment 25

[Blake Ross]

> I had no idea that adding this would be anymore than a half day's work
> since it already exists in the File menu.  

Yes, it's very easy.  Since when is being easy to program a reason to do 
something?

> Like it or not, Internet Explorer is the standard for most Windows users.  
> When they fire up Mozilla, I truly believe they will expect to see this 
> option available and their opinion will be affected by its absence.

Umm...aside from what Matthew said about IE's context menus (19 items in my 
current one, making it longer than every menu except my Favorites)...I sure 
don't see this option in my IE context menu for the page, on Windows.  Where do 
you see it?

Comment 26

[Blake Ross]

I don't think I'm going to do this, because I don't think this item belongs in 
the context menu.  Reassigning...

Comment 27

[Jesse Ruderman]

mpt: where are View Source and View Frame Source?  There will at least be a 
pref to turn it on, right?  I use it all the time, and afaik there's no other 
easy way to get the source of a frame with an evil "if (window!=top)" script.  
Also, I think Open Frame in New Window should be near the top of the frame 
context menu.

What do you think of making a pref for "show navigation commands on context 
menus"?  That would allow some users to make their context menus much shorter, 
and would keep the most useful options at the top of most menus for those users.

Comment 28

[Matthew T (active 1999-2002)]

> where are View Source and View Frame Source?

In the View menu (bug 47139).

> What do you think of making a pref ...

Prefs are for offering genuinely useful options to users, not for customizing 
absurd details.

Comment 29

[[e-mail]]

On the contrary, this is exactly what a Preferences menu is for.  In nearly all
well designed programs therre are multiple ways to do everything.  The Prefs
allow you to enable those things that you prefer.  Hence the name.

Look, this option is already available through the regular menus and I'm not
trying to make a big deal out of it.  Its just that when I teach a new person
how to use a program, I nearly always direct them to the context-sensitive menus
first because it immediately cuts down on the number of places they have to
look.  This is very common practice.  The most commonly used commands need to
be there.  Now I know this isn't a big thing to power users but when I taught my
mother how to use an internet browser, one of the first things she wanted to do
was E-mail the page we were at to a friend.  E-mail is what new users know.  Its
the very first thing they think of and, in my opinion, "Send page" needs to be
there up front.  You guys have had multiple end users tell you the same thing,
now.  Try looking at it from a beginner's point of view.

I think adding the ability to customize the context-sensitive menu is a nice
compromise.  One of the first things most experienced users do when they
download a new version is look at the preferences to see what's new.  They will
immediately figure out how to shorten the menus.  I'll tell you frankly that I
almost certainly cut out many commands (or command categories) given the
option.  Chances are people who don't know to do differently need the longer
menus anyway.

Comment 30

[Jesse Ruderman]

mpt: I noticed that you left out "block image" for image-links.  Since most 
banner ads are also links in addition to images, I think it's important to 
have "block image" on that menu.

>Prefs are for offering genuinely useful options to users, not for customizing 
>absurd details.

I think my suggestion (about back/forward) would be a genuinely useful option 
for people who like to be able to access "open link in new window" and "open 
frame in new window" quickly.  I guess you don't.

Comment 31

[Matthew T (active 1999-2002)]

> mpt: I noticed that you left out "block image" for image-links.

No, I didn't.

> I think my suggestion (about back/forward) would be a genuinely useful option
> for people who like to be able to access "open link in new window" and "open
> frame in new window" quickly.

Open a link in a new window quickly is Ctrl+click. And opening a frame in a new 
window wouldn't be made noticably faster by your proposed option anyway.

Comment 32

[Sebastian Späth]

Uhhm, we are getting slightly off-topic for this 'bug', but anyway:
mpt I think ctrl-click might be ok for some, but others prefer to browse 
mouse-only (and others again keyboard only). So providing a context menu entry 
"Open link in new Window" is crucial for me. 
I agree that Send page is not so often used that is justifies a context menu 
entry. 
People wanting to navigate back/forward mouse-only are advised to to so via the 
navigation toolbar.

Comment 33

[Peter Lairo]

every time someone sais that we don't need a context sensitive menu item because
there already is a keyboard shortcut, it makes me cringe. Many users (myself
included) have learned that almost every feature of an app can be accessed via
the context sensitive menu (right click). You just click the right mouse button
and you have an EXPLICT list of features to choose from. Nothing to memorize and
no accidentally activating a wrong command. Now keyboard shortcuts are
completely different. You have to MEMORIZE numerous combos (i emphasize
NUMEROUS, because there ARE many to get even close to the number of features
potentially available from the context menus). Also, clicking some combo might
activate a wrong freature if one had memorized that one wrong. 

The main point i am making is that the importance and VALUE of having features
accessible via the context menus shoud not be underestimated. Better to have 2
too many features than 1 to few. Please include the SEND PAGE feature.

Comment 34

[Matthew T (active 1999-2002)]

Sebastian: Please don't complain that I'm suggesting taking away "Open in New 
Window" from the context menu, when my spec clearly shows that I'm not.

Peter: Please read my 2000-12-18 comment. And destroy your Caps Lock key.

Comment 35

[Peter Lairo]

your 2000-12-18 comments: i disagree, we're very far from that point (about 5
more menu-items away). Anyhow, you could get rid of "view page source". What
normal user is going to use THAT? (got my caps back :) ). Clearly more people
are going to want to send their buddy or grandson some interesting page they
came accross than analyze a page's source.

Comment 36

[Sebastian Späth]

Could we please move the discussion about which context menus should be included 
into Newsgroups? It is really offtopic now, I started a thread 
"Context menu entries" in the n.p.m.ui group for this. Thanks

Comment 37

[Jesse Ruderman]

If View Source is removed from context menus, we need to make sure there's 
still a way to view the source for the sidebar.  View->Frame Source might work, 
although that would be pretty awkward.  See also bug 66933.

Comment 38

[Jesse Ruderman]

mpt: what do you think of removing Copy from the page/frame/link context menus, 
and only showing it on a special context menu for selections (bug 15176)?

Comment 39

[Matthew T (active 1999-2002)]

Yes, `Copy Selection' should replace `Copy {Page|Frame|Object|Link} Address' when 
there is a selection.

I've done a new draft of a context menu spec (quite different from the one I 
attached to this bug, but still with no `Send Page'), but haven't HTMLized it 
yet. I'll post it to n.p.m.ui in a couple of weeks when I get back online.

Comment 40

[Gervase Markham [:gerv]]

Matthew - just a note if you ever come back to this bug. I've been working in 
this area recently, and will implement your spec for you :-)

Gerv

Comment 41

[Blake Ross]

I don't think this item belongs in the context menu. Marking WONTFIX.

Comment 42

[Jesse Ruderman]

The new home of mpt's context menu spec is bug 75338.

Comment 43

[Peter Lairo]

Then this bug should *not* be marked as wontfix, because the context menu specs
haven't been decided on.

Please reset this bug to *NEW*.

I think some objective research should be done on how many users use the "view
source" menu item versus how many users use the "E-Mail this Page" menu item.

I understand that developers (especially whil Mozilla is in the development
phase) will frequently need to view the source. But there are hopefully *more
users than developers*, once Mozilla is generally available. 

I think it is a no-brainer that a normal surfer will more often want to *send a
page* to a buddy or family member, than to view a page's source.

Comment 44

[Ken Snider]

I have to agree that this doesn't belong in the context menu. The concept of a
contxt menu is that, inherently it is selecting something in the context of the
page, not the page itself. While this does not hold true for all items on the
menu, I think it is a valid consideration for any future additions that go there.

Comment 45

[sairuh (rarely reading bugmail)]

it's been implemented, per bug 103064.