235850 - Drop down list (select, popup) displays at the wrong location when at bottom of screen

Status: RESOLVED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Stuart Morgan]

User-Agent:       
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040225 Camino/0.7+

If a select list is very near the bottom of the screen, and the first item in
the list is currently selected, the option pop up is mysteriously floating at
the top of the screen, disconnected from the pop-up itself.

Reproducible: Always
Steps to Reproduce:
1. Go to the test page http://vorlon.cwru.edu/~sbm5/selecttest.html or use any
page with a select list with the first item selected.
2. By scrolling and/or dragging the window, position the select box very near
the bottom of the screen.
3. Try to change the list selection

Actual Results:  
Popup list appears floating near the top of the window, completely disconnected
from the popup

Expected Results:  
List should appear anchored to the top of the listbox--ideally extending up to
the top of the window if the list is very long (cf. Safari 1.2)

I originally suspected that it was an OS issue, since the select items are (I
believe) now native widgets, but since it's handled correctly in Safari I'm not
so sure.

Comment 1

[Mike Pinkerton (not reading bugmail)]

wow, you're right.

Comment 2

[Mike Pinkerton (not reading bugmail)]

*** Bug 239335 has been marked as a duplicate of this bug. ***

Comment 3

[Mike Pinkerton (not reading bugmail)]

this is an OS bug on 10.3 (at least), i can reproduce it with a test app.
attached after this. I'll report this to apple.

Comment 4

[Mike Pinkerton (not reading bugmail)]

Attachment: test app demonstrating OS bug

Comment 5

[Mike Pinkerton (not reading bugmail)]

reported to apple as radar://3648059

yay!

Comment 6

[Stuart Morgan]

*** Bug 245364 has been marked as a duplicate of this bug. ***

Comment 7

[stefano g]

i don't know if it is the same bug but  drop down lists are broken on some sites
- macupdate.com dpreview.com -
but not every list.

some list get spit in 2 and one part instead shows up totally disconnectet in
the top ledt part of the monitor - i will include a screenshot

Comment 8

[stefano g]

Attachment: screenshot of broken drop down list

Comment 9

[Wevah (Nate Weaver)]

*** Bug 260954 has been marked as a duplicate of this bug. ***

Comment 10

[Jasper]

*** Bug 267489 has been marked as a duplicate of this bug. ***

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I've found a case where the select is not near the bottom of the screen (and
doesn't seem to be bug 239335 either):

http://livepad.klogms.org/demo/

Is the above case a different bug?

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 288588 has been marked as a duplicate of this bug. ***

Comment 13

[Mike Pinkerton (not reading bugmail)]

we've done a little more research and it appears that this is not *quite* an os
bug, but really just poor documentation. 

The problem is that the view we're passing to the popup menu call is the content
area. When the popup code determines that the menu can't fit below the view
because of the bottom of the screen, it tries to flip it above the given view.
In the normal case, the view is small so this is ok. In our case, the view is
(mostly) the whole window, so it appears near the top of the screen.

the workaround i think is to create a temporary NSView that's the size and
location of the select that we're popping up from and pass that to the popup
menu call. When we're done tracking, remove the view. Not sure how easy this is.

Comment 14

[Simon Fraser [no longer active]]

Attachment: Patch

This patch fixes this bug, and bug 239335, by using GetPrimaryFrameFor() to get
to a frame, and nsIFrame::GetScreenRectExternal() to get the correct rect for
the frame. I make a view of the correct size and location now to host the
popup, which prevents the popup from showiong at the top of the window when
it's near the bottom of the screen.

Comment 15

[Mike Pinkerton (not reading bugmail)]

i don't follow why you're getting the screen coordinates and then working back
to window coordinates. The last version computed the window coordinates. Seems
like going to screen coords adds an extra step.

Comment 16

[Simon Fraser [no longer active]]

(In reply to comment #15)
> i don't follow why you're getting the screen coordinates and then working back
> to window coordinates. The last version computed the window coordinates. Seems
> like going to screen coords adds an extra step.

Because that's a whole lot easier than walking from frame to nsIView, then
messing with view/widget hierarchies. We have to go via the nsIFrame for the
select element to get the correct coordinates, so it just seemed easiest to go
via screen coords from there.

Comment 17

[Simon Fraser [no longer active]]

Fixed, trunk and branch.

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 198655 [details] [diff] [review]
Patch

Clearing obsolete request on fixed bug.