Closed
Bug 154226
Opened 22 years ago
Closed 16 years ago
Pop-up menu widgets don't change to active state until menu dismissed
Categories
(Camino Graveyard :: HTML Form Controls, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 294882
People
(Reporter: bugmail, Unassigned)
References
()
Details
Attachments
(1 file)
2.21 KB,
text/html
|
Details |
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.
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...
Updated•22 years ago
|
Component: General → HTML Form Controls
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.
Comment 6•21 years ago
|
||
Still true with 2003082402
Comment 7•19 years ago
|
||
Still true with 2005040108. ;)
Comment 8•19 years ago
|
||
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
Comment 9•18 years ago
|
||
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.
Comment 11•17 years ago
|
||
This just provides a minimal testcase for the behavior in comment 10.
Comment 12•17 years ago
|
||
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.
Comment 13•16 years ago
|
||
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
Closed: 16 years ago
Keywords: polish
Priority: P5 → --
Resolution: --- → DUPLICATE
Target Milestone: Camino2.0 → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•