Closed Bug 23567 Opened 25 years ago Closed 24 years ago

[TRACKING] unimplemented context menu items to be added


(SeaMonkey :: UI Design, defect, P2)


(Not tracked)



(Reporter: bugzilla, Assigned: german)



(Keywords: meta, Whiteboard: [nsbeta3-][nsbeta2-])


(1 file)

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


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
Priority: P3 → P2
Target Milestone: M15
adjusted target date and priority...
Assignee: saari → don
I'm not the right person to have this bug.
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.
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
added bugs dependent on this umbrella/tracking bug.
Blocks: 17524, 21515, 24108, 24221
another item (related to 17524) that should be added is "Add Frame to Bookmarks"
(or, to rephrase using current wording, "Bookmark this frame").
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.
Can we have "Open Frame in Window"?  (Right now there's only Open Frame in New
Window.  4.x has both).
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 
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.
Move to M16 for now ...
Target Milestone: M15 → M16
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.
Adding bug 31578, "Unable to reload a single frame" to dependencies
Blocks: 31578
Keywords: nsbeta2
Putting on [nsbeta2-] radar.  This is a "meta' tracking bug.
Whiteboard: [nsbeta2-]
Keywords: meta
Target Milestone: M16 → M18
Move to M20 target milestone.
Target Milestone: M18 → M20
*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.
QA Contact: sairuh → jrgm
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.
Assignee: don → johng
Component: XP Toolkit/Widgets: Menus → XP Apps
Keywords: nsbeta2nsbeta3
Target Milestone: M20 → ---
re-assign to german to get some help in creating full list of context menus
still needed, and when.
Assignee: johng → german
I will post what we currently have as a spec to's ui page asap. I 
will update this bug with the url as soon as its there...
Updating milestone to m19
Whiteboard: [nsbeta2-] → [nsbeta2-][not to self: need to post c'menu spec to]
Target Milestone: --- → M19
Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up
Keywords: nsbeta2
Marking tracking bug nsbeta3-
Whiteboard: [nsbeta2-][not to self: need to post c'menu spec to] → [nsbeta3-][nsbeta2-][not to self: need to post c'menu spec to]
well, this is back in xp apps, so back to me. ;)
QA Contact: jrgm → sairuh
*** Bug 58742 has been marked as a duplicate of this bug. ***
what a mess.
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
german, feel free to email any UI spec updates --i'll happily check 'em into the doc tree.
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.
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 

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.
finally checked in the spec to doctree. might take awhile for it to be
available, but the url will be:

i've tentatively set the milestone to mozilla1.0 --pls change if needed...
Whiteboard: [nsbeta3-][nsbeta2-][not to self: need to post c'menu spec to] → [nsbeta3-][nsbeta2-]
Target Milestone: M19 → mozilla1.0
This isn't really useful anymore...the only bug it's still tracking isn't even 
a non-implemented context menu item.  marking fixed.
Closed: 24 years ago
Resolution: --- → FIXED
hokay. vrfy.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.