RFE Change of Spec. Remove File>New AppDefItem. Leaving only File>New>{submenu}

VERIFIED WONTFIX

Status

--
enhancement
VERIFIED WONTFIX
18 years ago
10 years ago

People

(Reporter: timeless, Assigned: bugzilla)

Tracking

Trunk
Future

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
mpt and blake and others agree that having two New's is confusing.  mpt and I
agree that the AppDefItem is the menuitem that should be zapped.

Reproducible: Always
Steps to Reproduce:
Get a build of mozilla. Run Mozilla [Navigator]. Click File.

Actual Results:
File>
 New Navigator Window
 New>
  Navigator Window
  ...
 ...
Expected Results:
File>
 New>
  Navigator Window
  ...
 ...
(Assignee)

Comment 1

18 years ago
I don't agree.  It's extremely convenient to have, for example, File | New 
Navigator Window, and it provides much faster and easier access than having it 
in a submenu (like IE).  This speed gain is noticeable and worth it considering 
the user is often having to open new windows, e-mail messages, and composer 
forms, and add new bookmarks and address book cards when he/she is working in 
these windows.

Comment 2

18 years ago
There is no need to make `New {default item}' particularly quick to get to from 
the menus. If you want to make a new default item with the keyboard, Ctrl+N is 
quicker than using the menu. And if you want to make a new default item with the 
mouse, the relevant component bar item (in the case of main windows, once bug 
20306 is fixed) or toolbar button (in the case of things like Bookmarks and the 
Address Book) is quicker than the menu.

Meanwhile, not only is having two `New' items confusing, it also ruins your 
muscle memory for the position of the `Open' item.

Updated

18 years ago
Blocks: 37537
(Assignee)

Comment 3

18 years ago
I was under the impression that the task switching behavior of the component 
bar was intentional.  I also rarely have the taskbar open (although that won't 
be a problem when it moves to the statusbar, but I don't really see that 
happening soon, if ever).

I don't think we want a toolbar in the bookmarks window.
(Reporter)

Comment 4

18 years ago
<offtopic>
yes the taskbar behavior is intentional. However, mpt doesn't like it. His 
argument is that such behavior is for the window manager (macos doesn't have 
such a critter)
</offtopic>
I am working on a revised menu spec
http://timeless.student.umd.edu/mozilla/menu_framework.html
http://timeless.student.umd.edu/mozilla/menu_framework.html.diff

Please comment here.
Netscape nav triage team: per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-

Comment 6

17 years ago
reassigning.
Assignee: german → blakeross
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Assignee)

Comment 7

17 years ago
wontfix.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
v
Status: RESOLVED → VERIFIED

Comment 9

17 years ago
This bug seems to have been fixed. If we want to un-fix it, let's reopen or 
file a new bug on the issue. Otherwise, maybe we should reopen this and 
set the status over to FIXED.
Product: Core → Mozilla Application Suite
(Reporter)

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.