270981 - Drop-down select boxes are not supposed to be children of nsIWidget

Status: RESOLVED WONTFIX

(Core Graveyard :: Widget: OS/2, defect)

Description

[Peter Weilbacher]

Per comment 20 and comment 39 of bug 268090 the drop-downs of select boxes on
HTML pages are not supposed to be children of any nsIWidget (any more). This
seems to be an OS/2 only problem.

Comment 1

[Mike Kaply [:mkaply]]

conversation with roc:

mkaply	rocWork: So we have this new OS/2 bug
	mkaply	Drop-down select boxes are not supposed to be children of nsIWidget
	mkaply	What does this mean in practice? What do I need to change in widget?
	rocWork	It means that when we enumerate the child widgets of a window, we find
popups
	rocWork	we shouldn't, because we're creating them with null nsIWidget parent
	rocWork	but we *are* specifying a native widget for a parent
	mkaply	OK, so somewhere in the OS/2 code We're ignoring the null nsIWidget parent?
	mkaply	This is supposedly platform sepcific
	rocWork	yeah
	rocWork	I don't know how the OS/2 code keeps track of the child widgets but
somehow it's picking up the popup as a child
	mkaply	rocWork: any idea how we would be asked?
	mkaply	rocWork: are those popups the same as menu bar popups (eWindowType_popup)
	rocWork	it's the code in nsViewManager::UpdateWidgetArea
	rocWork	yes
	rocWork	combobox popups and menu popups drive the widget layer in essentialy
the same way
	mkaply	rocWork: I see the code on Windows for this:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#1463
	mkaply	But on OS/2, we can't have a NULL parent at the operating system level -
we make the parent the desktop
	mkaply	Is there an actual problem this is causing that I can see? So I can
attempt a fix?
	rocWork	mkaply: I don't know if there's a problem you can see. It'll bite us
eventually

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that just backing out the bug 268090 patch will cause problems you can
definitely see...

Comment 3

[Peter Weilbacher]

Is there any way to change the definition of children, to exclude the ones that
are inherited from the desktop besides the ones with a null parent? (I don't
even find the code that does the null check, although some of the GetChildAt
methods use "if (!aParent)" or similar...)

Comment 4

[Rich Walsh]

Given the huge number of changes in the architecture since this bug was opened, I consider it to be obsolete and am closing it as Resolved/Won'tFix.

In the current-day trunk (v1.9.3), making a popup the child of another nsIWidget or leaving it parentless appears to have no effect.  However, at least some widget code relies on the absence of a parent to differentiate between a toplevel (nsFrameWindow) widget & a child (nsWindow) widget.  Until that's changed and/or some compelling reason arises, popups need to have a parent widget.