Closed Bug 23567 Opened 25 years ago Closed 24 years ago

[TRACKING] unimplemented context menu items to be added

Categories

(SeaMonkey :: UI Design, defect, P2)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: bugzilla, Assigned: german)

References

Details

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

Attachments

(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 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
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 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.
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
M18.
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 mozilla.org's ui page asap. I will update this bug with the url as soon as its there... Updating milestone to m19
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2-] → [nsbeta2-][not to self: need to post c'menu spec to moz.org]
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 moz.org] → [nsbeta3-][nsbeta2-][not to self: need to post c'menu spec to moz.org]
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 mozilla.org 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 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.
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...
Whiteboard: [nsbeta3-][nsbeta2-][not to self: need to post c'menu spec to moz.org] → [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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
hokay. vrfy.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: