395334 - noautohide panel stays above other applications and its own modal children

Status: RESOLVED FIXED

(Core :: XUL, defect, P2)

Description

[Phil Ringnalda (:philor)]

STR:
1. In a Mac build after bug 395122 landed, open the toolbar customization sheet, or on any platform, open attachment 276008 [details] and click the "panel" button.
2. Switch to another application (cmd+tab, click Dock icon, click other app's window)

Actual:
The panel or toolbar customization sheet stays above the other application's window.

Expected:
Stay above the window that spawned it, but below other apps that the OS has placed over it.

Comment 1

[Phil Ringnalda (:philor)]

Among the things it stays above is the dialog to name a new toolbar:

1. Right-click toolbar, Customize
2. "Add New Toolbar"

Actual: you better not make a typo, because you're typing in an invisible textbox behind the panel.

Comment 2

[Neil Deakin]

Attachment: patch

This patch is part of bug 395670 but doesn't adjust the focus behaviour. This patch also fixes bugs 124313 and 395123 and possibly bug 390197.

This makes a panel popup with noautohide have the containing window as a parent. The allows the panel to appear just above the parent instead of floating above all windows. On Cocoa, setting a parent-child has the side-effect of having the child move with the parent. This behaviour is emulated on other platforms by adjusting the popup during a move/resize event, which also fixes bug 395123.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why can't we use aNative in nsIView::CreateWidget to pass the parent?

Alternatively, can we add a boolean flag to nsWidgetInitData to indicate whether a popup should be parented or not; if the flag says "parented", then the view system can find the right widget.

Comment 4

[Neil Deakin]

> Why can't we use aNative in nsIView::CreateWidget to pass the parent?
> 

I couldn't figure out a way to convert an nsNativeWidget to an nsIWidget, or vice versa or something like that. I agree that it would be better to not have to change this view code too much.

> Alternatively, can we add a boolean flag to nsWidgetInitData to indicate
> whether a popup should be parented or not; if the flag says "parented", then
> the view system can find the right widget.
> 

Eseentially, I need the main widget for the nsIBaseWindow the popup is in.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We can chase the widget parent chain up to the root in various ways, one of those ways should work here.

Comment 6

[Josh Aas]

Comment on attachment 287006 [details] [diff] [review]
patch

I don't think this will apply on Mac because that code changed recently.

+        [nativeParentWindow addChildWindow: mWindow
+                            ordered: NSWindowAbove];

Also, we don't put a space between the ":" for an argument and the argument itself in our objective-c code.

Comment 7

[Neil Deakin]

(In reply to comment #5)
> We can chase the widget parent chain up to the root in various ways, one of
> those ways should work here.
> 

Can you be more specific here? The only widget available is from the parent view (also a root view) of the popup. There are no parents of either.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Does nsContentUtils::GetTopLevelWidget work for you?

Comment 10

[Neil Deakin]

(In reply to comment #9)
> Does nsContentUtils::GetTopLevelWidget work for you?
> 

No, I want the nsIBaseWindow widget. It has no parent and no children, so no amount of widget tree navigation is going to find it.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

nsIWidget::GetParent actually walks the native widget tree so that might still work.

Comment 12

[Neil Deakin]

(In reply to comment #11)
> nsIWidget::GetParent actually walks the native widget tree so that might still
> work.
> 

Nope.

I use view->GetNearestWidget() and that widget has one parent (which is a child widget). That parent has no parent itself.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK then. How about using nsIWidget::GetNativeData(NS_NATIVE_WINDOW) to get from your desired parent nsIWidget to an aNativeData?

Comment 14

[Neil Deakin]

(In reply to comment #13)
> OK then. How about using nsIWidget::GetNativeData(NS_NATIVE_WINDOW) to get from
> your desired parent nsIWidget to an aNativeData?
> 

I don't want the native data, I want the nsIWidget, so I can call, for instance, nsCocoaWindow::Create(nsIWidget *aParent, ...) The nsCocoaWindow::Create(nsNativeWidget aNativeWindow, ...) form doesn't do the same thing.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 287006 [details] [diff] [review]
patch

okay then. I guess this is the best we can do. This will go away/be changed when we remove views anyway.

Comment 16

[Neil Deakin]

Attachment: updated patch

Comment 17

[pal-moz]

this causes bug 405899 ?