[cocoa] Sheets are offscreen if opened when all windows closed (attached to hiddenwindow)

RESOLVED FIXED in mozilla12

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
11 years ago
6 years ago

People

(Reporter: stefanh, Assigned: Karsten Düsterloh)

Tracking

({regression})

Trunk
mozilla12
All
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
SeaMonkey recent trunk, mac os x.

SeaMonkey Open Web Location dialog is a sheet. If you close all windows and open the dialog it will pop out at the upper left corner with only the bottom visible. 

This wasn't the case when we where using mac widget code. If you opened the dialog when all your windows where closed, the dialog opened in form of a standard non-sheet dialog box in the upper left corner just below the menubar.
(Reporter)

Comment 1

11 years ago
Created attachment 242330 [details]
Screenshot of misplaced Open Web Location sheet

To reproduce this:

1) Open SeaMonkey
2) Close the Seamonkey window
3) Hit Cmd+Shift+L

I managed to get the dialog completely visible one time. It looked like a sheet to me. So maybe the cocoa code doesn't handle cases like this (sheets opened when only hiddenwindow is open)?
(Reporter)

Comment 2

11 years ago
If you make a js alert (sheet) open when no windows are open you'll see the same issue. Could it be that the sheet draws from the hidden windows titlebar - somewhere "above" your screen?
Component: XP Apps: GUI Features → Widget: Cocoa
Product: Mozilla Application Suite → Core
Summary: [cocoa] Open Web Location sheet offscreen if opened when all windows closed → [cocoa] Sheets are offscreen if opened when all windows closed
Version: unspecified → Trunk
(Reporter)

Updated

11 years ago
Assignee: guifeatures → joshmoz
QA Contact: cocoa
(Reporter)

Updated

11 years ago
Keywords: regression

Comment 3

9 years ago
This might be the same as bug 424266.
(Reporter)

Comment 4

9 years ago
This seems to works for me now (Leopard, recent trunk). Karsten, does it works for you with Tiger?

Updated

8 years ago
Assignee: joshmoz → nobody
(Reporter)

Comment 5

8 years ago
This have gotten worse on Leopard, so it's not fixed. What probably happens is that the sheet opens somewhere outside the screen.
(Reporter)

Comment 6

7 years ago
Since the sheet is attached to the hiddenwindow it will open way offscreen. In order to get out of the situation you can hit Esc which will close the non-visible sheet.
Presumably there's code somewhere to check and see if there are any windows, and if not to display an app-modal dialogue instead; can that code check just be modified to exclude the hidden window?
Summary: [cocoa] Sheets are offscreen if opened when all windows closed → [cocoa] Sheets are offscreen if opened when all windows closed (attached to hiddenwindow)
(Assignee)

Comment 8

6 years ago
Created attachment 559281 [details] [diff] [review]
deny hidden window as parent
Attachment #559281 - Flags: review?(joshmoz)
(Assignee)

Comment 9

6 years ago
Lost comment:
The patch just kills the parent reference to the hidden window when creating a new window. All other parameters like modal, centerscreen, etc. are left intact (but are probably converted just like they are now: modal sheets without a parent become a normal dialog, etc.).
Assignee: nobody → mnyromyr
(Assignee)

Updated

6 years ago
Hardware: PowerPC → All

Updated

6 years ago
Attachment #559281 - Flags: review?(joshmoz) → review?(smichaud)
Comment on attachment 559281 [details] [diff] [review]
deny hidden window as parent

I'll need to test this patch -- I won't be able to understand all its
implications without doing that.

So please give me ways (hopefully several ways) to reproduce this bug
in Seamonkey and (if possible) also Firefox.

Testing in Seamonkey 2.4 on OS X 10.6.8, I currently just get a beep
when I follow the STR from comment #0.
(Reporter)

Comment 11

6 years ago
I dunno about Firefox, but if it helps, it's easy to reproduce the issue in Thunderbird:

1) Launch a Thunderbird nightly
2) Close the window
3) From the File menu, choose New --> Address Book Contact…
4) Watch the contacts sheet open partially off-screen in the top left corner
That does help.  Thanks.
(Assignee)

Comment 13

6 years ago
Created attachment 563886 [details]
XPI showing the problem in FF (use Cmd-Q to exit)

This pseudo addon for FF just opens a dialog before any real windows are up.
The dialog will be centered upon the upper left corner of the screen.
Comment on attachment 559281 [details] [diff] [review]
deny hidden window as parent

mnyromyr, thanks very much for your testcase (from comment #13).  But in my tests, your patch doesn't fix the problem that it demonstrates :-(

I tested (with a fresh profile) in a build made from current trunk code (and patched by your patch from comment #8) on OS X 10.6.8.

I haven't had a chance to do any digging, to figure out why your patch fails.  Hopefully I'll have time for that next week.
Attachment #559281 - Flags: review?(smichaud) → review-
(Assignee)

Comment 15

6 years ago
FWIW, it doesn't work for me anymore either with current trunk (the comparison for the hidden window fails now).
I'll try to get a new patch up.
(Assignee)

Comment 16

6 years ago
Created attachment 570095 [details] [diff] [review]
do ConstrainPosition

It took some time until I realized that window->ConstrainPosition didn't work, because it … is not implemented?!
This patch does not do any ambitious calculations, it just makes sure that the upper left corner of a window is not moved offscreen.
Attachment #559281 - Attachment is obsolete: true
Attachment #570095 - Flags: review?(smichaud)
Created attachment 578385 [details] [diff] [review]
Alternate implementation of ConstrainPosition

> It took some time until I realized that window->ConstrainPosition
> didn't work, because it … is not implemented?!

Amazing.

This seems to go back to the very earliest days of Cocoa widgets:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/cocoa/nsCocoaWindow.mm&rev=1.1
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/cocoa/nsCocoaWindow.mm&rev=1.30

I can't figure out why/how it stayed unimplemented for so long.  All
other platforms implement it except for something called "gonk"
(whatever that is).  Mac widgets (Cocoa widgets' predecessor) also
implemented it.

So it's high time we added support for this to Cocoa widgets :-)

But since our biggest platforms (Windows and GTK) also implement it,
and in the same way, I figure it's best to copy their implementations.
That's what my patch does.

In very brief testing it fixes this bug (as demonstrated by your
testcase).  Let me know if you can anticipate any problems using my
(more complex) patch instead of your (simpler) patch.
Attachment #578385 - Flags: review?(mnyromyr)
(Assignee)

Comment 18

6 years ago
Comment on attachment 578385 [details] [diff] [review]
Alternate implementation of ConstrainPosition

Looks good; works as expected for me in both FF and SM. 
Sorry for the long delay.
Attachment #578385 - Flags: review?(mnyromyr) → review+
(Assignee)

Updated

6 years ago
Attachment #570095 - Flags: review?(smichaud)
Comment on attachment 578385 [details] [diff] [review]
Alternate implementation of ConstrainPosition

Landed on mozilla-inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/163c2800f87f

Thanks, Mnyromyr, for testing this and noticing the underlying bug (our lack of an implementation for nsCocoaWindow::ConstrainPosition())!
Whiteboard: [inbound]
https://hg.mozilla.org/mozilla-central/rev/163c2800f87f
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
You need to log in before you can comment on or make changes to this bug.