6871 - [PP][Mac][BLOCKER]gfx rendered drop-down lists don't get placed 'on top'

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Alistair Vining]

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.

Comment 1

[Peter Trudelle]

reassigning to evaughan for triage

Comment 2

[Eric Vaughan]

this is Kevin's widget.

Comment 3

[Kevin McCluskey (gone)]

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

Comment 4

[Alistair Vining]

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.

Comment 5

[Kevin McCluskey (gone)]

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.

Comment 6

[phillip]

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.

Comment 7

[phillip]

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

Comment 8

[phillip]

updating url

Comment 9

[Kevin McCluskey (gone)]

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.

Comment 10

[Patrick C. Beard]

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

Comment 11

[Mike Pinkerton (not reading bugmail)]

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

Comment 12

[Mike Pinkerton (not reading bugmail)]

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.

Comment 13

[dcone (gone)]

Using real Mac windows for popups, no longer clips.

Comment 14

[Paul MacQuiddy]

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

Comment 15

[leger]

Putting on [PDT]+ radar.

Comment 16

[Claudius Gayle]

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