noautohide panel stays above other applications and its own modal children

RESOLVED FIXED

Status

()

Core
XUL
P2
major
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: philor, Assigned: Neil Deakin (away until Feb 4))

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:Rp])

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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?
(Reporter)

Comment 1

11 years ago
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
(Assignee)

Updated

11 years ago
Depends on: 395670
Flags: blocking1.9? → blocking1.9+
Whiteboard: [dbaron-1.9:Rp]
(Assignee)

Updated

10 years ago
Assignee: nobody → enndeakin
(Assignee)

Comment 2

10 years ago
Created attachment 287006 [details] [diff] [review]
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.
Attachment #287006 - Flags: superreview?(roc)
Attachment #287006 - Flags: review?(roc)
(Assignee)

Updated

10 years ago
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.
(Assignee)

Comment 4

10 years ago
> 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 6

10 years ago
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-
(Assignee)

Comment 7

10 years ago
(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.

(Reporter)

Updated

10 years ago
Blocks: 403942
(Reporter)

Updated

10 years ago
Summary: noautohide panel stays above other applications → noautohide panel stays above other applications and its own modal children
(Reporter)

Updated

10 years ago
Duplicate of this bug: 404882
Does nsContentUtils::GetTopLevelWidget work for you?
(Assignee)

Comment 10

10 years ago
(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.
(Assignee)

Comment 12

10 years ago
(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?
(Assignee)

Comment 14

10 years ago
(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+
(Assignee)

Comment 16

10 years ago
Created attachment 290553 [details] [diff] [review]
updated patch
Attachment #290553 - Flags: review?(joshmoz)

Updated

10 years ago
Attachment #290553 - Flags: review?(joshmoz) → review+
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 17

10 years ago
this causes bug 405899 ?

Updated

10 years ago
Depends on: 405899
(Reporter)

Updated

10 years ago
Depends on: 406342

Updated

10 years ago
Depends on: 406304

Updated

10 years ago
Duplicate of this bug: 403942
You need to log in before you can comment on or make changes to this bug.