23567 - [TRACKING] unimplemented context menu items to be added

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[sairuh (rarely reading bugmail)]

exchanged email with german, who said that [ideally] the various context menus
listed on the UI spec page should be implemented for the release of 5.0 (but not
beta1).

http://gooey/client/5.0/specs/contextmenus/

here are the context menu items which aren't implemented yet --this bug (unless
otherwise noted) will track 'em:

View Image in New Window
Add Link to Bookmarks (refer to bug 17524)
Add Page to Bookmarks (only have "Bookmark this page" --again bug 17524)
Save Background As...
Print Page...
Create Desktop Shortcut
Send Page...
Link Properties
Image Properties

Comment 1

[sairuh (rarely reading bugmail)]

adjusted target date and priority...

Comment 2

[saari (gone)]

I'm not the right person to have this bug.

Comment 3

[Sean Richardson]

Bug 24108, "When right-clicking on a link the following text should be
corrected", advocates Initial Capitalization of *all* words on the context
menu items, which would be [4.xP] (currently, only the first word of each item
is capitalized).

It probably makes sense to use the same sort of capitalization as is decided
for that bug when the strings for the new items are added, so it won't get
reopened, or push its target milestone out further than this bug's, so all the
items will be in when it gets attention.

Comment 4

[leger]

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.

Comment 5

[sairuh (rarely reading bugmail)]

added bugs dependent on this umbrella/tracking bug.

Comment 6

[sairuh (rarely reading bugmail)]

another item (related to 17524) that should be added is "Add Frame to Bookmarks"
(or, to rephrase using current wording, "Bookmark this frame").

Comment 7

[Colin Slater]

I got a fix for adding print, #24221. Do you want it checked in or what should 
I do with it. THe patch is atached to 24221.

Comment 8

[Richard Zach]

Can we have "Open Frame in Window"?  (Right now there's only Open Frame in New
Window.  4.x has both).

Comment 9

[bht237]

Could we have the "View Info" frame context menu item as in Navigator 4? 
Essential in windows having no menu and tool bars. Such a feature is needed 
badly especially where no location field is available. I prefer to use 
Netsacape 4 as HTML/JavaScript development tool over IE4 just because of this 
feature and the editable location field in the "Create Internet Shortcut" 
dialog box. They are generic tools that can replace many other context menu 
items.
A frame URL is what ALL potential context menu actions DO need, even if they 
have to translate from URL notation to platform specific file names.

In other words: If I have "View Info" for the top level frame under all 
conditions (e.g. no browser menu), then I can copy URLs from the "View Info" 
page and do an "Open Frame in Window" myself with the clipboard.
Many thanks.

Comment 10

[don]

Move to M16 for now ...

Comment 11

[nathan]

The "Reload Frame" option is one of features that made netscape users netscape
fans.  I hope it doesn't get left out of the final release.

Comment 12

[Sean Richardson]

Adding bug 31578, "Unable to reload a single frame" to dependencies

Comment 13

[leger]

Putting on [nsbeta2-] radar.  This is a "meta' tracking bug.

Comment 14

[don]

M18.

Comment 15

[don]

Move to M20 target milestone.

Comment 16

[sairuh (rarely reading bugmail)]

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.

Comment 17

[don]

John, can you co-ordinate getting the list of these suckers so we can have a
spec for how screwed we are on all the context menus?  I'd like to make sure we
have our ducks in a row on this for beta 3, but frankly I have no idea which
menu items/commands might be missing.  It's not like all of this has ever been
finalized. :-)

Just re-assign back to me when we have some data.

Comment 18

[johng]

re-assign to german to get some help in creating full list of context menus
still needed, and when.

Comment 19

[german]

I will post what we currently have as a spec to mozilla.org's ui page asap. I 
will update this bug with the url as soon as its there...
Updating milestone to m19

Comment 20

[Daniel Veditz [:dveditz]]

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up

Comment 21

[hangas]

Marking tracking bug nsbeta3-

Comment 22

[sairuh (rarely reading bugmail)]

well, this is back in xp apps, so back to me. ;)

Comment 23

[sairuh (rarely reading bugmail)]

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

Comment 24

[timeless]

what a mess.

Comment 25

[german]

Attachment: Somehat dated but still pretty uptodate context menu spec for NS6

Comment 26

[german]

sorry to have kept the spec internal for so long. I finally had a chance to
breathe and dust it off and post it to this bug as an interim measure. This like
most other specs will also be posted to mozilla shortly, but they need some
fixing to be up to date with the NS6.5 timeframe

Comment 27

[sairuh (rarely reading bugmail)]

german, feel free to email any UI spec updates --i'll happily check 'em into the
mozilla.org doc tree.

Comment 28

[Matthew T (active 1999-2002)]

The following, at least, are not in a user's most common half-dozen actions in 
the contexts for which they are included in the context menu, so they shouldn't 
be there:
* Reload
* Stop
* Save
* Print
* Add to Bookmarks
* Send Page
* Redo
* New Bookmark
* New Subfolder
* New Separation Line
* Rename (should be part of bookmark/folder properties anyway)
* Search Bookmarks
* the entire `View List' submenu (in both Bookmarks and History)
* Search Previously Visited Sites [sic]
* the Open Attachment submenu (quicker just to use the attachments menu)
* the entire context menus for selected addresses.

If you're not careful, Mozilla's context menu will end up like IE's -- so long 
that it becomes a coin toss whether it will appear above or below the cursor, so 
that items aren't in a consistent position relative to the cursor and it becomes 
quicker to use the main menus or the toolbar instead.

Finally, context menus should never contain keyboard shortcuts. That's the job of 
main menus.

Comment 29

[timeless]

We have a few problems
Reload is often for reload frame. Unless the view menu gets reload frame in 
addition to reload this get's very messy.

Bah, that comment applies to a bunch of things mpt mentioned.

Rename should be on the context menu for windows because that's part of the 
standard windows ui; if possible it should be an inplace rename [the start menu 
does a dialog rename, most likely because an inplace rename was not practical].

Windows tradition has new as a cascading menu. BeOS does too, even mozilla does 
that. 

If I ever get time i'll write an alternative spec that uses cascading menus. I 
know mpt doesn't like it but I think that's a better way to go, it's more 
flexible and prevents the appearance of clutter at the expense of needing two 
levels for most actions.

Comment 30

[sairuh (rarely reading bugmail)]

finally checked in the spec to doctree. might take awhile for it to be
available, but the url will be:
http://mozilla.org/projects/ui/netscape/context_menus/

i've tentatively set the milestone to mozilla1.0 --pls change if needed...

Comment 31

[Blake Ross]

This isn't really useful anymore...the only bug it's still tracking isn't even 
a non-implemented context menu item.  marking fixed.

Comment 32

[sairuh (rarely reading bugmail)]

hokay. vrfy.