Open Bug 1093774 Opened 10 years ago Updated 2 years ago

When printing to a file, the "save file" dialog pops up behind Firefox, making Firefox appear hung

Categories

(Core :: Printing: Output, defect)

x86_64
Windows
defect

Tracking

()

Tracking Status
e10s - ---
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected
firefox46 --- affected

People

(Reporter: cmtalbert, Unassigned)

Details

On my laptop I have a specific piece of software that I installed as a printer that simply saves a document to a PDF on my desktop. It's called the "Nitro PDF creator". I think you could also repro this with the standard Microsoft XPS writer that is usually installed, but I wasn't able to verify (as you will see in a moment).

1. Go to a page
2. Hit ctrl+P
3. Select the "print to a file" service you want
4. Click print
Now, two things happen -- the status window for printing may pop up, which is one of those little useless windows with a progress bar. And the file save-as dialog will also popup. In my case the save-as dialog popped up behind the browser, while the progress bar dialog was in front of the browser. Clicking on the progress bar dialog and then on the browser behind it made it go "unresponsive" according to windows b/c the UI loop was waiting on me in the modal "save as" dialog that I couldn't see (I had Firefox maximized on the laptop).

Now, when trying this again, I clicked on the "save as" dialog and let it go through, verifying that it did in fact "print" the document. Subsequently when I tried to repro it, I found that now I couldn't.  I *could* repro it before I allowed the operation to complete (i.e. if I alt-tab'ed to the save as dialog and canceled it).  But once the operation completed, it now seems to have remembered that it needs to put the save as dialog on top, and it's working well.

So, this one is a bit intermittent.
Tried again with a new profile, both with the browser maximized and with it in full screen mode. Both times it now works perfectly. :-(  So I might have stumbled upon a windows-ism or upon an intermittent.
I think that this might well get fixed by bug 1156742.
I'm pretty sure that these dialogs get popped up by the call to ::StartDoc.

In the current world these are being called by the content process, which may explain the problem.
When bug 1156742 lands we'll be calling these in the main process.

So, it would be good to see if anyone can reproduce once that's in.
Depends on: 1156742
[Tracking Requested - why for this release]:
This bug is current reproducible in release.

STR:

1) print a page
2) select XPS Writer or some other print to file driver

result: the file picker window that opens isn't modal and opens *behind* the browser window. If your browser window happens to be maximized, the only indication you get is an added taskbar icon. The browser window locks up with Windows painting the "unresponsive" overlay on it.
No longer blocks: 927188
No longer depends on: 1156742
OS: Windows 8.1 → Windows
Summary: [e10s] When printing to a file, the "save file" dialog pops up behind Firefox, making Firefox appear hung → When printing to a file, the "save file" dialog pops up behind Firefox, making Firefox appear hung
Interestingly, this bug is not reproducible for me in my local builds, nor on builds from mozregression.

I can also reproduce using the steps in comment 3 going all the way back to Firefox 4.
I don't think this save as dialog is generated by Firefox. But we might be responsible for handing the driver a parent HWND somehow. Or maybe the xps driver just broke at some point and nobody reported it.

One other oddity, if you have a debugger attached like visual studio, the bug doesn't reproduce.
pfft, this is a known issue for 64-bit version of Windows that use 64-bit save to file print drivers like the XPS Writer.

https://support.microsoft.com/en-us/kb/2567869
(In reply to Jim Mathies [:jimm] from comment #6)
> pfft, this is a known issue for 64-bit version of Windows that use 64-bit
> save to file print drivers like the XPS Writer.
> 
> https://support.microsoft.com/en-us/kb/2567869

Good find.

So from reading the MORE INFORMATION section of that article, we could special case the XPS Document Writer and the Adobe PDF printer, display our own file picker and pass the resulting file name in DOCINFO.lpszOutput to StartDoc.

We'd need to make sure the overwrite behaviour was the same etc.
Will this bug affect "Microsoft Print to PDF" printer that are added in Windows 10?

Is this still known to exist?

Flags: needinfo?(bobowencode)

(In reply to Wayne Mery (:wsmwk) from comment #9)

Is this still known to exist?

I'm afraid I don't know ... it doesn't look like a fix has been landed by Microsoft, if it only affected Windows 7 (which is not clear) then I guess they won't fix it.

I imagine that fewer people would see this anyway, as a lot of people will have been migrated to the 64-bit version of Firefox.

Flags: needinfo?(bobowencode)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.