User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; rv:1.0.0) Gecko/20020820 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; rv:1.0.0) Gecko/20020820 when the standard mac os x print dialog is invoked clicking on a navigator window can cause the dialog to be hidden. The browser window looks active but will not respond to mouse clicks. The menu bar is disabled/grayed out so you cannot retrieve the dialog without moving the browser window out of the way. Novice users could easily believe that the app had crashed and become unresponsive. Reproducible: Always Steps to Reproduce: 1.Select File / Print... or hit Command-P 2.Click on a browser window in background to bring it forward. Actual Results: Print Dialog disappears behind browser window and can only be brought back my moving windows out of the way and clicking on it. Also, while testing this a second ago, I was entering text in the textbox above when I tried to print. After bringing the browser forward some keys still produced output (a,b,c etc. keys), some did nothing (backspace) and others produced garbage (up arrow key). Expected Results: Navigator should make use of the modal sheets UI widgets to prevent this happening. Omniweb uses these and it also gives the benefit that printing from one window doesn't affect the operation of the rest of the browser. I don't know how this will fit with your nonstandard tabbed UI but is seems like the best solution to me.

WFM; the print dialog always stays in front.

WorksForMe using FizzillaCFM/2002081803. Print dialog hoards focus until it is dismissed. No Mozilla windows can be brought to the foreground in front of it.

> WorksForMe using FizzillaCFM/2002081803 Notice we're talking about Chimera here.

I can reproduce this consistently with Navigator 4,0 and the nightly for 20th August on both my home and work machines (both running MacOS X 10.1.5), I am certain this is a real bug. A further related bug is that the text entry fields ( i.e. print page [X] to [Y]} in the print dialog never accept keystrokes. Can someone please retry this.

In Chimera 2002082005, I can no longer bring a window in front of the Print dialog, but I can still get it to lose focus if click another window while the dialog is coming up. The main point is that using an application modal dialog for Print is a UI disaster, and we should make Print a sheet whether there are problems with the modal dialog or not. We already have sheets working with tabs for things like the site not found alert, so that's not the issue. Page Setup is also supposed to be a sheet (see TextEdit 1.2's behavior on all these points).

The printing code for OSX was recently moved to using the session APIs so using sheets is at least an option. Problem is, the nsIPrintingPromptService API expects each "dialog" that gets posed to be modal. It's some work in the printing back end to allow nsIPrintingPromptService routines to be non-modal. That is, the dialog (sheet) is shown, the nsIPrintingPromptService method returns immediately, and then makes a callback when the sheet is confirmed or canceled. Of course, the site not found alert you mention is done through nsIPromptService which also expects the dialogs to be modal. Maybe we're using sheets modally there?

Confirmed using Chimera/2002082005.

This is either a 10.1 only problem or WFM. Under 10.2, it's impossible to bring a modal print dialog in front of a browser window.

Confirmed with a 4/29/2004 build on 10.1.5, so this is indeed a 10.1 issue. Adding 10.1 to summary, taking, and putting on the 0.8 list so we can try to fix this before we drop 0.8 support

Note that this also affects Page Setup as well. Also, even without bringing it to the front, the most recent browser looks active (the titlebar stays opaque) which isn't correct. It looks like we are interfering somehow with the OS's ability to make the printing windows key/active/something. See also bug 155558.

Giving my bugs back to pink.

I can replicate this bug (10.1), but this also happens with (some) other apps. This is a trivial bug, since you can use command+tab to jump to another application, and then use the same key combination to come back to Camino (in which case the focus is on the print dialog). WONTFIX?

Since this is apparently a 10.1-only bug which missed 0.8, should it now be closed, or is there potential for it to make it into a 0.8.x-point release yet?

we're not going to fix this for 0.8.x and 0.9 requires 10.2. sorry.