Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Reporter
	Description • 23 years ago

Build ID 2002012503

The Save and Print dialogs apply to one window. Hence, it would be good if they
were sheets as in TextEdit.

	Robert John Churchill
	Comment 1 • 23 years ago

Unlike how sheets were "wedgeed" into Mozilla's widget library, NavServices
dialogs (Open & Save) and Print dialogs are system dialogs which require usage
of different APIs.  Futuring & marking helpwanted.

	Jonathan Brecher
	Comment 2 • 23 years ago

Apple has some excellent doc/sample code for implementing sheet-based 
print/pagesetup dialogs, currently living at 
http://developer.apple.com/techpubs/macosx/Carbon/graphics/CarbonPrintingManager
/CPM_Concepts/cpm_chap3/index.html

	Bill McGonigle (not currently reading bugmail; please contact directly)
	Comment 3 • 22 years ago

Just to be formal, these would be "Document modal" dialogs, which should be
sheets.  Adding HIG URL.

	m_mozilla
	Comment 4 • 22 years ago

Just to be pick nits: with tabbed browsing, sheets aren't document-modal.

See bug 123908

-matt

	Bill McGonigle (not currently reading bugmail; please contact directly)
	Comment 5 • 22 years ago

That's a good point.  I suspect it's probably good-enough for most cases.  The
only problem case I can think of off the top of my head is a javascript timer
which fires off a Window.print() when the timer expires.  If the timer is long
enough, you might be in another tab.  The user could still dismiss the sheet.

	Frankie
	Comment 6 • 22 years ago

*** Bug 177788 has been marked as a duplicate of this bug. ***

	Dave Miller [:justdave]
	Comment 7 • 20 years ago

timeless got me interested in this somehow the other night, and I've been toying
with it a little.  I succeeded in getting the SaveAs dialog to attach itself to
the document being saved as a sheet, however, the app hangs immediately after
the sheet opens, and you have to force-quit.  Part of the problem is with the
dialog being app modal, running the dialog didn't return until the user
dismissed it.  Changing it to document modal makes the NavDialogRun call return
immediately, and you have to either poll the dialog or watch for the
user-dismissed event before getting the answer back from the user.  Since
donating time to the main event queue while I wait for the user to dismiss the
dialog doesn't seem to work, I think we may need app-wide API changes for
dealing with the dialogs in order to pull it off, but on the other hand, maybe
I'm just doing it wrong.

Work-in-progress will be attached shortly.

	Dave Miller [:justdave]
	Comment 8 • 20 years ago

There is an indentation change in here...  I made the patch with -w to make it
easier to see what was being added though.

	Jonathan Brecher
	Comment 9 • 20 years ago

For what it's worth, we dealt with this in our own cross-platform app by making the wrapper class (our 
equivalent of nsFilePicker) a suiciding object. That is, we always instantiate the class using operator 
new:

DoFileDialog()
{
   nsFilePicker *fp = new nsFilePicker;
   fp->Execute();
   // It looks like fp is about to leak right here!
}

Then the wrapper class calls "delete this;" itself in response to the completion of the dialog. On 
Windows, the dialog blocks and everything is equivalent to the way it was before. On the Mac, the 
dialog doesn't block, and events continue on in their merry way through the rest of the program, and 
then when the dialog finally does get closed, then the completion routine (with the "delete this;") gets 
called at that point.

Works great.  YMMV.

	Smokey Ardisson (offline for a while; not following bugs - do not email)
	Comment 10 • 18 years ago

*** Bug 329326 has been marked as a duplicate of this bug. ***