Pop-up menu widgets don't change to active state until menu dismissed



Camino Graveyard
HTML Form Controls
16 years ago
10 years ago


(Reporter: Greg K., Unassigned)





(1 attachment)



16 years ago
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.

Comment 1

16 years ago
polish, ->pinkerton
Assignee: saari → pinkerton


16 years ago
Keywords: polish
Assignee: pinkerton → bryner

Comment 3

16 years ago
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...


15 years ago
Component: General → HTML Form Controls

Comment 4

15 years ago
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 5

15 years ago
This is still a problem using Camino/2003-05-01-05.
Still true with 2003082402

Comment 7

13 years ago
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

Comment 9

12 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. :)

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

11 years ago
Created attachment 260376 [details]
Reduced testcase for comment 10

This just provides a minimal testcase for the behavior in comment 10.

Comment 12

11 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

10 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.
Last Resolved: 10 years ago
Keywords: polish
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.