Closed Bug 395334 Opened 17 years ago Closed 17 years ago

noautohide panel stays above other applications and its own modal children

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: philor, Assigned: enndeakin)

References

Details

(Whiteboard: [dbaron-1.9:Rp])

Attachments

(2 files)

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.
Flags: blocking1.9?
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.
Severity: normal → major
Depends on: 395670
Flags: blocking1.9? → blocking1.9+
Assignee: nobody → enndeakin
Attached patch patchSplinter Review
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.
Attachment #287006 - Flags: superreview?(roc)
Attachment #287006 - Flags: review?(roc)
Attachment #287006 - Flags: review?(joshmoz)
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.
> 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.
We can chase the widget parent chain up to the root in various ways, one of those ways should work here.
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.
Attachment #287006 - Flags: review?(joshmoz) → review-
(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.

Blocks: 403942
Summary: noautohide panel stays above other applications → noautohide panel stays above other applications and its own modal children
Does nsContentUtils::GetTopLevelWidget work for you?
(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.
nsIWidget::GetParent actually walks the native widget tree so that might still work.
(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.


OK then. How about using nsIWidget::GetNativeData(NS_NATIVE_WINDOW) to get from your desired parent nsIWidget to an aNativeData?
(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 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.
Attachment #287006 - Flags: superreview?(roc)
Attachment #287006 - Flags: superreview+
Attachment #287006 - Flags: review?(roc)
Attachment #287006 - Flags: review+
Attached patch updated patchSplinter Review
Attachment #290553 - Flags: review?(joshmoz)
Attachment #290553 - Flags: review?(joshmoz) → review+
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
this causes bug 405899 ?
Depends on: 405899
Depends on: 406342
Depends on: 406304
You need to log in before you can comment on or make changes to this bug.