1088061 - Investigate not opening the progress dialog for print preview manually in PrintUtils

Status: RESOLVED WONTFIX

(Toolkit :: Printing, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

When entering print preview, PrintUtils manually opens the progress dialog. The print engine already knows how to open progress dialogs, so we might want to let it continue doing that by itself. The only reason PrintUtils opens the progress dialog itself is because of a supposed crash that occurs otherwise. This progress dialog workaround was introduced in 2003, and I think we should investigate alternatives, because it makes things unnecessarily complicated.

Comment 1

[Jonathan Watt [:jwatt]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #0)

This progress dialog workaround was introduced in 2003

When you added the comments to the source code, presumably that was because of this pre-existing comment as shown in your commit:

https://hg.mozilla.org/mozilla-central/rev/24a95294f600d50960d388151fa1e8d28d0474ba#l4.264

That may look like it was added in 2003:

https://github.com/mozilla/gecko-dev/commit/31e49513d60cb80be01623887744d186550778b6

but FWIW it actually dates back to the very first commit Blake made for what would become the Firefox source code:

https://github.com/mozilla/gecko-dev/blame/bb05882143e9cfc8a999dec03820ec559b6738d1/browser/base/content/browser.js#L2056

That code in turn appears to have been copied from the Mozilla Suite code:

https://dxr.mozilla.org/mozilla/search?q=will+layout+before+the+content+window+and+a+crash+will+occur

So anyway, uh, no, I didn't manage to dig up a bug that would shed any more light on this.

Comment 2

[Jonathan Watt [:jwatt]]

Actually, I disagree with this bug. I think ideally we would not be using app-modal dialogs to show print [preview] progress. A tab-modal doorhanger would probably be better. But regardless of the UI, I think nsPrintJob should not be in the business of imposing a specific UI for showing progress on the app. Rather, it would be better if the progress dialog showing code was removed from nsPrintJob and it just continue to fire progress at the consumer, allowing each app to choose its own UI.

Mike, what do you think?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Yeah, on second thought, I very much agree - experience with the printing code suggests that putting more UI responsibility on the print engine backend is probably a bad idea. The more we can add hooks for the various consumers of the API to implement their own UI, the better.

So I'm gonna WONTFIX this. Thanks for reminding me about it.

Comment 4

[Jonathan Watt [:jwatt]]

Thanks. I filed bug 1558588 to remove the dialog opening code from the core printing code.