See e.g. resource:/res/mailnews/messenger/am-server.xul If the top frame isn't made tall enough, the drop-down list (<select>) goes under the other frame, rather than on top. Need to be above every (?) frameset etc.

reassigning to evaughan for triage

this is Kevin's widget.

Drop-down list now use popup child windows, so this should be fixed. Need to confirm it is still a problem.

Now resource:/chrome/messenger/content/default/am-server.xul Sort of fixed, but try resizing the frame up/down. Now, if the top frame is *larger* than the list, the text fails to display, and the frame is drawn the wrong size. Plus, a) there seems to be a slight flickering, b) losing the focus from the main window when selecting a drop-down list is unusual behaviour, at least for Windows. But perhaps unavoidable.

Fixed in June 21, 1999 4:13pm build. Added nsListControlFrame::GetViewOffset to calculate the absolute position of a view. This is used to calculate where the drop-down list should be placed. Added nsListControlFrame::SyncWithFrame to synchronize the view's position with the nsListControlFrame's position. Added nsListControlFrame::DidReflow to override nsScrollFrame::DidReflow to call SyncWithFrame. Added nsListControlFrame::GetScrollingParentView to override the nsScrollFrame::GetScrollingParentView to return the root view. Modified nsScrollFrame. Added a virtual method GetScrollingParentView which can be overriden to control the parenting of the ListControlFrame. (When the listcontrol frame is used as a drop-down it's parent is the root view instead of it's normalposition in the view hierarchy. (This is needed to prevent the view from being clipped when the drop-down list extends outside of the parent window.

this is cross platform. it works on RedHat 5.2 and WinNT4sp4 (the M8 candidates), but not MacOS 8.51. i will mark verified when mac gfx widgets start to behave better, or will reopen if need be.

i hate to do this, but even though this works on 1999-07-16-08 RedHat Linux 5.2 (GNOME/enlightenment) 1999-07-16-08 WinNT 4.0 sp4 it is still drawing beneath the lower frame on 1999-07-16-08 MacOS 8.51

updating url

This is a Mac specific problem with the implementation of borderless-top level windows. This is a blocker for frame-based comboboxes on the Mac. Don, I'm reassigning to you to investigate why it doesn't work on the Mac.

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

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

adding myself to cc list. just tried the url in the url field above and it crashes (8/16/99 build) we also need to make sure that new top-level windows that are created don't cause the front window to visibly lose focus. That would be bad if a combo-box popped up and deactivated the main window.

Using real Mac windows for popups, no longer clips.

Sorry for spam, re-assigning phillip's QA contact XPToolkit/XPWidget bugs to claudius due to restructure

Putting on [PDT]+ radar.

marking VERIFIED based on comments and I cannot reproduce the problem anymore with any builds much less the 1999102909 builds