List menus do not open at current selection

NEW
Unassigned

Status

Camino Graveyard
HTML Form Controls
16 years ago
6 years ago

People

(Reporter: Steve Miller, Unassigned)

Tracking

unspecified
Future
PowerPC
Mac OS X
Bug Flags:
camino0.9 -

Details

(URL)

Attachments

(1 attachment)

1.64 KB, patch
David Haas (gone, not reading mail)
: review+
S Woodside
: review+
Mike Pinkerton (not reading bugmail)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021214 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021214 Chimera/0.6+

When you click on them, they seem to choose a random position to open, where as
they should start from your current position. For example, in these forums, if I
click on the list menu at the bottom of the Third-party Software page, it starts
on Other Topics. Why? It should select Third-party Software first, since that is
currently what is selected in the list menu.

Reproducible: Sometimes

Steps to Reproduce:
1.It seems to only happen when the entire menu won't fit on the monitor...
2.
3.

Comment 1

16 years ago
OS bug?
(Reporter)

Comment 2

16 years ago
Don't think so... Omniweb, Mozilla, and IE all get it right...

Comment 3

16 years ago
Confirmed using 1217, IE shows it correctly.
Reducing the window's height and drag it at the top of the screen, it reduces
the problem but a huge empty area is at the end of the menu.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

16 years ago
I think this is a duplicate of bug 184995.
(Reporter)

Comment 5

16 years ago
This is NOT a duplicate of 184995. If you see the screenshot, it shows that the
menu appears to the left of the menu widget. This is not the case with this bug. 

Comment 6

16 years ago
Created attachment 117379 [details] [diff] [review]
attempted patch

This fixes the problem by using an hidden NSPopUpButtonCell to show the menu so
that the toolkit treats it as a popup menu instead of a context menu. We also
get the added bonus of having the small system font in the menu to match the
new small form controls.

The main thing I'm worried about with this patch is whether we incur a
substantial performance penalty by creating a NSPopUpButtonCell. I can't tell
by testing with a debug build on my slow machine.

Updated

16 years ago
Attachment #117379 - Flags: review?(bryner)
If we switch the popup menu to use the small system font we should also change
the widget to draw at the small size.  I'll do an optimized build with the patch
and see if I can tell any difference in speed.  I'd seriously doubt there's
going to be a problem though.

Also, where did you get "point.y - yDelta - 3" from as the y position of the cell?
Reporter please test with a newwer build. Seems worksform for me with build
2003082402

Comment 9

15 years ago
On the given URL there is only one list menu that doesn't work correctly if you
ask me. Which is the forum jumpe list menu. When you click on it your mouse
isn't over the software item but the Gui customisation item.

Could somebody retest?

Comment 10

15 years ago
Comment on attachment 117379 [details] [diff] [review]
attempted patch

We have a new Camino request flag which can be set multiple times for a patch.
Moving old review requests to the new flag. Sorry for the spam.
Attachment #117379 - Flags: review?(bryner) → review?
Comment on attachment 117379 [details] [diff] [review]
attempted patch

patch works in my build.
Attachment #117379 - Flags: review? → review+
Target Milestone: --- → Camino0.8
Summary: list menus do not open at current selection → [patch]list menus do not open at current selection

Comment 12

15 years ago
Mike this patch seems to work correctly. Isn't it time to check in?

Comment 13

15 years ago
Ari - could you please explain your arithmetic to bryner per comment #7 so we
can get this patch in? Thanks.

Comment 14

15 years ago
Comment on attachment 117379 [details] [diff] [review]
attempted patch

It's a good patch. This line:

+    [cell trackMouse: event inRect: bounds ofView: [[event window]
contentView] untilMouseUp: YES];


seems to be the magic that makes the popup appear in the right place. I don't
think that the -3 is importnat, it's just 3 pixels.
Attachment #117379 - Flags: review?
Attachment #117379 - Flags: superreview?(pinkerton)
i landed this patch, it's much better than it was, but i can still break it if i
position things very carefully. if you view this bug's page and click the "OS"
popup button, depending on where the top of the window is, I can still get it to
select "OS 9" instead of "OS X" sometimes. Move the window a tiny bit and it works.

Gonna leave this open but move it off the 0.8 plate. it's still not completely
fixed.
Assignee: bryner → pinkerton
Target Milestone: Camino0.8 → Camino1.0
Attachment #117379 - Flags: superreview?(pinkerton) → superreview+

Comment 16

15 years ago
This seems to have corrected bug 184995, wiht the same restricion of comment 15.

Updated

13 years ago
Flags: camino0.9?

Comment 17

13 years ago
I'm not clear on what the remaining problem is, and without more information I
can't decide whether or not to approve 0.9 blocker status. Since I haven't
noticed any major issues with popups, I'm tempted to not have this block 0.9.

Can someone clarify?
i'm gonna minus this. 
Flags: camino0.9? → camino0.9-
Ping.

Mike, what's going on with this bug? A patch was landed but it didn't work? Or
wasn't complete? What more needs to be done?
Mike, can you still reproduce this? I can't see it at all, no matter how the
window is positioned.
i can repro this with the "Hardware" menu in this bug. if i move the window down
near the bottom of the screen (about an inch above my dock) and click it, i can
get "PC" to be selected instead of "Macintosh".

not all that important tho.
Target Milestone: Camino1.0 → Camino1.2
Summary: [patch]list menus do not open at current selection → List menus do not open at current selection
I still can't reproduce this, no matter where the window is place in relation to the dock. Since the bulk of this bug is fixed and the rest is "not all that important", I'm retargeting for Future.
QA Contact: winnie → form.controls
Target Milestone: Camino1.2 → Future
Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".
Assignee: mikepinkerton → nobody
You need to log in before you can comment on or make changes to this bug.