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.
Don't think so... Omniweb, Mozilla, and IE all get it right...
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
I think this is a duplicate of bug 184995.
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.
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.
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
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 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+
Summary: list menus do not open at current selection → [patch]list menus do not open at current selection
Mike this patch seems to work correctly. Isn't it time to check in?
Ari - could you please explain your arithmetic to bryner per comment #7 so we can get this patch in? Thanks.
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: 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+
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?
read comment #15
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.