Closed Bug 26939 Opened 25 years ago Closed 24 years ago

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

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.0

People

(Reporter: tshanno, Assigned: bugs)

References

Details

Attachments

(3 files)

patch
1.84 KB, patch
Details | Diff | Splinter Review
patch without the quirky whitespace
1.91 KB, patch
Details | Diff | Splinter Review
Draft spec: Context menu arrangements for Navigator content area
4.08 KB, text/html
Details
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.
Changing component
Assignee: troy → don
Component: Layout → XPApps
QA Contact: petersen → paulmac
setting sairuh as qa contact, cc:ing lisa in case she cares about send page
QA Contact: paulmac → sairuh
Reassigning as per Don
Assignee: don → law
Target Milestone: --- → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
okay..do we want to do this?
Assignee: law → blakeross
I say yes.
ditto.
Component: XP Apps → XP Apps: GUI Features
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Target Milestone: M21 → mozilla0.9
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)
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.
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?
yes, for pages with frames, there should be both Send Page and Send Frame in the context menu.
Attached patch patch — — Splinter Review
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.
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.
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...
Priority: P3 → P2
Priority: P2 → P3
Target Milestone: mozilla0.9 → mozilla1.0
*** Bug 61003 has been marked as a duplicate of this bug. ***
*** Bug 61645 has been marked as a duplicate of this bug. ***
Is `Send Page' really one of the top 12 or so commands that the user needs in his context menu?
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.
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.
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.
cc'ing additional mailnews folx who might be interested in this...
> 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?
I don't think I'm going to do this, because I don't think this item belongs in the context menu. Reassigning...
Assignee: blakeross → ben
Status: ASSIGNED → NEW
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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
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.
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)?
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.
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
Depends on: 75338
I don't think this item belongs in the context menu. Marking WONTFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Keywords: 4xp
The new home of mpt's context menu spec is bug 75338.
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.
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.
Blocks: 103064
it's been implemented, per bug 103064.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: