Open Bug 109844 Opened 23 years ago Updated 2 years ago

Menus should remain highlighted while commands are being processed on Mac OS

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect

Tracking

()

People

(Reporter: mozilla7, Unassigned)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5+) Gecko/20011109
BuildID:    2001110908

When a command is selected from a menu (either with the mouse or with a keyboard
shortcut), it is customary for the name of the menu to remain highlighted until
the command has been completed.

Reproducible: Always
Steps to Reproduce:
1. Select Preferences from the Edit menu


Actual Results:  The menu disappears immediately (Bug 66120) and Edit is no
longer highlighted.  After a moment, the Preferences window is displayed.

Expected Results:  Edit should remain highlighted after the menu disappears,
until the Preferences window is displayed.

Selecting Find from the Search menu is another example.

In some Mac apps, when a dialog box is displayed that requires input before the
app can continue (are those modal or modeless?  I forget) the menu will remain
highlighted until the dialog is dismissed.  Save As and Print are that kind of
dialog; Preferences and Find are the other kind.

Curiously, when I select Print from the File menu, the File menu remains
highlighted until the dialog appears, just as it should.

This bug strikes me as being a large pain in the butt to implement at this
stage, with little gained.  Still, I figured it was worth mentioning.
-> pinkerton

Are you sure these haven't already been filed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not at all, but I didn't find a dup.  Of course, I've submitted bugs before that
turned out to be dups, after I thought I searched for dups....
From bug 50590:

------- Additional Comments From Matthew Thomas (mpt) 2000-09-12 17:21 -------
But whatever, that's a minimum interval; if the operation itself takes longer 
than 8/60 of a second (e.g. pasting a large quantity of text), the menu should 
stay lit for the whole operation. We already do this for opening dialogs, so 
presumably it's possible for other operations.

Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Mac OS 9.2.2 English-North American
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020830
Build ID 2002083017

I confirm this bug.

I do not consider it as a trivial bug :

1. When attempting to capture highlit text strings, using the Command + C
keyboard shortcut, Mozilla is still rather iffy a lot of the time. So the
expected blink of the title of the Edit menu is helpful as it indicates that the
command actually worked, and so saves me the bother of opening the Clipboard to
see if the selected text has been actually captured.

2. Mozilla should behave as expected on Mac systems---after all we are trying to
gain users.

3. Mozilla should always be at least as good to use as IE---which is false in
this instance.
Since we don't do development for Mac OS 9 or earlier anymore (let alone System
7 where this is filed in !), and this behaviour is still valid in Mac OS X (for
instance, the Finder still does it), shouldn't we move this to Mac OSX ?
Updating OS
OS: Mac System 7 → MacOS X
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: hyatt → nobody
Component: XUL → Widget: Cocoa
QA Contact: xptoolkit.widgets → cocoa
Target Milestone: mozilla1.1alpha → ---
Status: ASSIGNED → NEW
Hardware: PowerPC → All
Severity: trivial → S4
You need to log in before you can comment on or make changes to this bug.