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)

PowerPC
macOS
defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 294882

People

(Reporter: bugmail, Unassigned)

References

()

Details

Attachments

(1 file)

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.
polish, ->pinkerton
Assignee: saari → pinkerton
Keywords: polish
->bryner
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...
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.
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.
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
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.

Attachment

General

Created:
Updated:
Size: