Aqua pop-up menu widgets in Chimera don't display in the "active" state when clicked and held. Instead, when the menu is released, the blue arrow portion of the widget activates on click release. The entire widget should be put in the active state when clicked. For example, see the "Path" widget on a Finder toolbar.
Assignee: saari → pinkerton
Assignee: pinkerton → bryner
Able to reprouce this on a build from 2002112321, Mac OS X 10.2.2. I disagree that this is trivial. Its not serious by any means but really should be fixed soon. I'd give it a severity of normal. Its even more annoying now that this bug pointed it out to me...
This is trivial because it doesn't actually impact usability or functionality. That doesn't mean it isn't important to fix, however; it is. That's what Priority is for.
This is still a problem using Camino/2003-05-01-05.
Still true with 2003082402
Still true with 2005040108. ;)
This is still true but not necessary for a finished product. Targeting for 1.1, Priority 5.
Priority: -- → P5
Target Milestone: --- → Camino1.1
Assignee: bryner → nobody
QA Contact: winnie → form.controls
Target Milestone: Camino1.1 → Camino2.0
Is this bug asking for (a) the entire widget to be highlighted (which is what the Path widget in Finder toolbars does), or (b) the minor flash after deselect to go away? Or (c) something else entirely? If it's (a), the Path widget is a different sort of control entirely. This is not how popup menu lists (NSPopUpButton) work. If it's (b), I see the same problem in Safari, which leads me to believe that this may be an OS bug. If it's (c), please explain. :) cl
The real bug here (besides the visual one) is that we do the wrong thing when acting on the select is supposed to do something. E.g., go request a review on an attachment in Bugzilla (using the mouse). Notice that after selecting the ? you are "tabbed" into the requestee field--but then focus is immediately pulled away and sent back to the select, so that you can't type. Now try in Safari or Firefox and note that, regardless of when the focus ring is drawn, focus isn't stolen from the requestee field. This is probably the same as bug 294882, except this was filed against the visual bit and the other was filed against a specific side-effect of the underlying bug; see also bug 294882 comment 9 and 10.
Created attachment 260376 [details] Reduced testcase for comment 10 This just provides a minimal testcase for the behavior in comment 10.
Using this testcase I get the following warning: WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 924 I don't really understand the warning or the code it originates from, so I can't say whether this is a red herring or useful info.
Oops, we were tracking this in two bugs, and I only noticed the newer one when I fixed it, so we'll have to dupe this the other way.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Priority: P5 → --
Resolution: --- → DUPLICATE
Target Milestone: Camino2.0 → ---
Duplicate of bug: 294882
You need to log in before you can comment on or make changes to this bug.