Closed Bug 6871 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: alistair.vining, Assigned: dcone)

References

()

Details

(Whiteboard: [PDT+])

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.
Assignee: trudelle → evaughan
reassigning to evaughan for triage
Assignee: evaughan → kmcclusk
this is Kevin's widget.
Status: NEW → ASSIGNED
Target Milestone: M8
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Whiteboard: [07.15.99]waiting for mac to stabilize (different gfx issue)
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.
Status: RESOLVED → REOPENED
OS: Windows 95 → All
Hardware: PC → All
Whiteboard: [07.15.99]waiting for mac to stabilize (different gfx issue)
Resolution: FIXED → ---
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
Assignee: kmcclusk → dcone
Severity: normal → blocker
Status: REOPENED → NEW
Summary: gfx rendered drop-down lists don't get placed 'on top' → [PP][Mac][BLOCKER]gfx rendered drop-down lists don't get placed 'on top'
Target Milestone: M8 → M9
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.
Status: NEW → ASSIGNED
*** Bug 4780 has been marked as a duplicate of this bug. ***
Target Milestone: M9 → M10
Blocks: 11346
*** 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.
Blocks: 12902
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
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
Whiteboard: [PDT+]
Putting on [PDT]+ radar.
Status: RESOLVED → VERIFIED
marking VERIFIED based on comments and I cannot reproduce the problem anymore with any builds much less the 1999102909 builds
No longer blocks: 11346
You need to log in before you can comment on or make changes to this bug.