Closed Bug 458297 Opened 16 years ago Closed 16 years ago

Form widgets and scrollbar should not be grayed when clicking on menus or dock stacks

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.1b3

People

(Reporter: mattsmeltz, Assigned: mstange)

References

Details

(Keywords: verified1.9.1)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre

Follow-up to bug 54488.

When clicking on the help menu, or menus on the right side of the menu bar (non-Firefox menus) or clicking on stacks in the dock, the Firefox window remains in focus as expected but the window scrollbar and form widgets on the page are grayed until the help menu or stack is closed.

Reproducible: Always

Steps to Reproduce:
1. Click on the help menu, or a menu on the right-hand side of the menu bar, or expand a stack on the dock
2. Observe the scrollbar and form widgets on the page
3. Close the help menu or stack
Actual Results:  
Form widgets and scrollbar become grayed until the menu or stack is closed.

Expected Results:  
Form widgets and scrollbar do not become grayed since the window is still in focus.


I don't know if there is any other way to cause this but the bottom line of course is that the widgets should stay active as long as the window is in focus.

This happens also on widgets in the preferences window and other dialogs.

I am testing on 10.5. I am unable to confirm whether this happens on 10.4.
Blocks: 54488
The help menu doesn't exhibit this behavior on 10.4, but everything else you list does (the apple menu doesn't exhibit it either, for a data point).
Assignee: joshmoz → mstange
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Version: unspecified → Trunk
Flags: wanted1.9.1?
Attached patch patch v1Splinter Review
The window's key state is apparently not the right criterion for its control tint. Now I'm checking for the window's main state instead, but still set the clear tint when a sheet is open.

There are two things that could be done better here:
 - Popup windows (e.g. the toolbar customization panel) should only get the
   active look when their parent top level window is main. Steven, is there a
   way of getting to the top level window?
 - Opening the Dock menu while a sheet is open breaks everything, but that's
   a known fundamental problem (see also bug 428071).
Attachment #341608 - Flags: review?(smichaud)
Markus, I'm starting to review your patch (and will probably do some
testing).  But I've already noticed something odd:

This bug *doesn't* happen in Firefox 3.0.3, even on OS X 10.5.5.  Do
you know why?
(In reply to comment #2)

> Steven, is there a way of getting to the top level window?

The following should work (with a PopupWindow object that's visible):

Keep calling [PopupWindow parentWindow] until you get something that
isn't a PopupWindow object (and that is ToolbarWindow object or
perhaps a BorderlessWindow object).

You'll need to confirm this by trial and error, though.

The reason this works (if it does work) is that nsCocoaWindow::Show()
makes a popup window a child of its (native) parent window (by calling
[NSWindow addChildWindow:]) when it "shows" the corresponding
nsCocoaWindow.

Note that nsCocoaWindow::Show() calls [NSWindow removeChildWindow:]
when it "hides" a popup window.
Comment on attachment 341608 [details] [diff] [review]
patch v1

I've tested this patch (on OS X 10.5.5) and found that it fixes this
bug.  And the patch makes sense ... as far as it goes.  But you
probably want to try out my suggestion from comment #4.
Attachment #341608 - Flags: review?(smichaud) → review+
(In reply to comment #4)
Thanks, that works.
But now I have a different problem: the panel isn't redrawn when its parent window's focus changes, so getting the check right wouldn't have any effect.
But I don't think controls in panels are used very often (apart from the toolbar customization palette), so they're probably not worth the effort.

I think we should just take this patch as-is and think about panels in a new bug if we really want it.
Attachment #341608 - Flags: superreview?(roc)
Attachment #341608 - Flags: superreview?(roc) → superreview+
Attachment #341608 - Flags: approval1.9.1?
Attachment #341608 - Flags: approval1.9.1? → approval1.9.1+
http://hg.mozilla.org/mozilla-central/rev/5be5521bce2b
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b3
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Shiretoko/3.1b3pre ID:20081204020603

Would even be great to have a test in Litmus.
Status: RESOLVED → VERIFIED
Flags: wanted1.9.1? → in-litmus?
Keywords: fixed1.9.1
It has been already verified on Dec, 06th last year. Setting flag.
Added to Litmus: https://litmus.mozilla.org/show_test.cgi?id=7465
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: