Investigate not opening the progress dialog for print preview manually in PrintUtils
Categories
(Toolkit :: Printing, defect)
Tracking
()
People
(Reporter: mconley, Unassigned)
Details
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•5 years ago
•
|
||
(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:
That code in turn appears to have been copied from the Mozilla Suite code:
So anyway, uh, no, I didn't manage to dig up a bug that would shed any more light on this.
|
|
||
Comment 2•5 years ago
|
||
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?
|
Reporter | |
Comment 3•5 years ago
|
||
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•5 years ago
|
||
Thanks. I filed bug 1558588 to remove the dialog opening code from the core printing code.
Description
•