650966 - [UX] Redesign + reimplement print preview UI

Status: RESOLVED DUPLICATE of bug 133787

(Toolkit :: Printing, enhancement)

Description

[Zack Weinberg (:zwol)]

The existing (non-Mac) print preview UI is very dated, window-modal, and generally in need of an update.  Limi has ideas.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is vastly easier now we clone documents for printing.

I've had some ideas for this rattling around for a while.

My main idea is to get rid of the print-preview mode for layout presentations. Introduce a new XUL <page> element that can reference a print presentation and render a page from that presentation. Implement print preview by creating a print presentation and constructing a list of XUL <page> elements rendering its pages. Then with straight XUL you can do all kinds of things we can't do today, like add per-page UI, preview N pages at a time in any layout, visually select pages to print, direct-manipulation changes to margins, use whatever style you want, etc. Would also simplify layout and provide better WYSIWYG guarantees since the same presentation would be used for print preview and printing.

Comment 2

[Steffen Wilberg]

Attachment: Chrome screenshot

Chrome does this very nicely, see the attached screenshot:
Pressing Ctrl+P opens a new tab. There's a sidebar on the left with Print/Cancel buttons, a label saying how many pages will be printed, printer selection, pages, number of copies, portrait/landscape, color/bw knobs.
The main content is print preview. The zoom controls are a bit hidden: you have to hover the bottom-right corner.

It's a HTML page, just press Ctrl+U to see it.

Comment 3

[u428464]

Print preview should really be redesigned. As most of the time, Chrome has much to tell us about how Firefox should handle print preview. Also note that in last builds of Chrome print preview is rendered in an "in-content windows" (it can be close).

Comment 4

[Alex Limi (:limi) — Firefox UX Team]

Yuan has some designs for this, CCing her, there might also be a feature page available.

Comment 5

[u428464]

Chrome will soon show page number directly into the scrollbar : https://lh4.googleusercontent.com/-nMUIx722avs/Ty1WYLVlXfI/AAAAAAAAneY/tA77rMCIqi4/s1280/Screen+shot+2012-02-04+at+10.53.17+AM.png

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Hmm, well, this may depend on bug 629500, depending on the UI we want.
But UI can be improved a lot even without fixing bug 629500.

Comment 8

[Zack Weinberg (:zwol)]

(In reply to Olli Pettay [:smaug] from comment #7)
> Hmm, well, this may depend on bug 629500, depending on the UI we want.
> But UI can be improved a lot even without fixing bug 629500.

The only caution I have about that is that if you touch the print *progress* stuff in this bug, you may get the rug yanked out from under you by bug 629500 and/or bug 650960.  The UI that shows up after the print preview is rendered is not touched much at all by the changes I've made to date, and given my extremely limited time to work on that for the next while, I would hate to see anyone get stuck waiting for me.

Comment 9

[u428464]

I think it would be nice to add this to the desktop backlog. (bug 950073).

Comment 10

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Should be on there, thanks for noticing!

Comment 11

[Oskar Eisemuth]

Attachment: UIPrintPreviewPlusAddon on Firefox 25

Screenshot of my addon as additional reference.

First the underlying printing systems needs a good amount of work, as the options code, print preview setup and handling is quite broken, and needs a lot workarounds.

Comment 12

[Zack Weinberg (:zwol)]

(In reply to Oskar Eisemuth from comment #11)
> First the underlying printing systems needs a good amount of work, as the
> options code, print preview setup and handling is quite broken, and needs a
> lot workarounds.

You wouldn't happen to be interested in helping me with bug 650960, bug 693230, or bug 702678, would you?  They ought to help you a bit by themselves, and if that set of bugs ever gets completed and landed then I can dust off and land bug 629500, and *then* I fully intend to gut and rewrite print settings so they actually work, but I can't justify the time until the code I don't know how to write (693230) or need design help with (650960) or debugging assistance on a platform I don't have (702678) is sorted.

Comment 13

[Oskar Eisemuth]

I already subscribed to these bugs, even tried to apply the patch bundle to a local tree but failed. 
I eventually gave up I have not see what direction Mozilla wants to go and doesn't want to spend even more time on useless stuff. Specially what happens when Gecko should work in multiprocess mode is unclear. Needs a full rewrite again?

Then there are other logical bugs and disagreement between Win32 and Linux Printing.
https://bugzilla.mozilla.org/show_bug.cgi?id=947125

So I tried to write a workaround at the internals using negative margins for win32, but this end up not very successfully as page reflow was crashing.  The margins system is insane for win32 and I have no idea to fix this as the internals have no concept that a actually device surface is actually smaller on windows (only the printable area) then the selected paper size.

Currently this means printing is unusable on both platforms and see no way to fix this alone. 
(Linux: paper selection and querying broken, win32: margins). Current Workaround -> Disabled internal PDF Viewer + using PDF.

Comment 14

[Zack Weinberg (:zwol)]

(In reply to Oskar Eisemuth from comment #13)
> I already subscribed to these bugs, even tried to apply the patch bundle to
> a local tree but failed.

Yah, patch bundles of that size tend to bitrot.  I apologize.  693230 and 702678 should be much less troublesome, and (conveniently) they are also the things that I could most use help with.

> I eventually gave up I have not see what direction Mozilla wants to go and
> doesn't want to spend even more time on useless stuff.

Mozilla doesn't really _have_ a direction for printing at the moment; it's not important to them.  The last time I tried to enlist help with these bugs from MoCo employees the modal reaction was "Uh, does anyone ever print anything anymore?"  The built-in PDF viewer, for instance, which I see you are not a fan of: the primary reason MoCo cares about that is, Acrobat is a giant ball of bugs, many of which are security holes. And it is also seen as an opportunity to integrate PDFs better into the Web, and a tech demo for the capabilities of the Web As A Platform.  None of these have anything to do with printing, and indeed printouts from pdf.js are subpar on several levels, and that's just not all that important to the people working on it, because, again, "Uh, does anyone ever print anything anymore?"

But the thing is, this is an opportunity!  You clearly _do_ care about printing.  (And so do I, to be clear, or I wouldn't have sunk a bunch of effort into these bugs already.)  If we do the work, we get to _decide_ what the direction will be.

> Specially what happens when Gecko should work in multiprocess mode is unclear. Needs a full
> rewrite again?

To first order, I don't see that _anything_ necessarily need change for multiprocess.  Whatever content process is displaying the page that gets printed will be responsible for running the print engine.  On its main thread.  Getting the print engine off the main thread is only ever going to happen in Servo.

Anyhow, don't even bother thinking about that right now.  There are so many other things that need fixing first, and most of them are unrelated to the things that will need changing for multiprocess.

> Then there are other logical bugs and disagreement between Win32 and Linux
> Printing.
> https://bugzilla.mozilla.org/show_bug.cgi?id=947125

This is a useful list to have compiled.  I'll reply to you more there - we prefer to keep each bug about one thing only.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Zack Weinberg (:zwol) from comment #14)
> Mozilla doesn't really _have_ a direction for printing at the moment; it's
> not important to them.
"them"? You're more than welcome to spend time on making printing better.
Whether or not paid employees have time for hacking printing support is different thing, and
doesn't tell anything about Mozilla as a community.

>  The last time I tried to enlist help with these bugs
> from MoCo employees the modal reaction was "Uh, does anyone ever print
> anything anymore?"
I doubt.

Anyhow, I'll spend sometime to make printing work in e10s. Well, I'll make at least the
setup multiprocess compatible, and possible layout/gfx changes will be done by someone else.

> But the thing is, this is an opportunity!  You clearly _do_ care about
> printing.  (And so do I, to be clear, or I wouldn't have sunk a bunch of
> effort into these bugs already.)  If we do the work, we get to _decide_ what
> the direction will be.
Yes! All the help is more than welcome!

> Anyhow, don't even bother thinking about that right now.  There are so many
> other things that need fixing first, and most of them are unrelated to the
> things that will need changing for multiprocess.
Yup. The UI of print preview certainly can be fixed without thinking too much about multiprocess

Comment 16

[Zack Weinberg (:zwol)]

(In reply to Olli Pettay [:smaug] from comment #15)
> (In reply to Zack Weinberg (:zwol) from comment #14)
> > Mozilla doesn't really _have_ a direction for printing at the moment; it's
> > not important to them.
> "them"? You're more than welcome to spend time on making printing better.
> Whether or not paid employees have time for hacking printing support is
> different thing, and doesn't tell anything about Mozilla as a community.

I suppose I should have been clearer that I meant the paid staff there rather
than the community at large.  But what you're saying here is also what I was
trying to get at: yeah, maybe the Firefox product managers don't consider
printing a priority (and I think that's perfectly understandable) but that
means community members who do consider it important have an opportunity to
set the direction.

> >  The last time I tried to enlist help with these bugs
> > from MoCo employees the modal reaction was "Uh, does anyone ever print
> > anything anymore?"
> I doubt.

That really was what about six different people said to me at the summit when
I tried to drum up some interest in the Windows stuff that I can't do myself.

> Anyhow, I'll spend sometime to make printing work in e10s. Well, I'll make
> at least the setup multiprocess compatible, and possible layout/gfx changes
> will be done by someone else.

Good to know; I haven't been following e10s at all and wouldn't know where to
begin if it got stuck on my plate :-)

Comment 17

[Oskar Eisemuth]

To get back to topic
For tabbed approach (as seen on the screenshot) in the code I faced some problems:

The actual print preview code needs a parent browser window or in firefox a tab browser. As the code comments in the print preview the underlying parent gets modified and switched into some page mode. So it shouldn't be messed with while in print preview. Technical I solve this problem currently by hiding the "parent" tab. Not very nice, but as addon there aren't much options. Calling enterPrintPreview again after changing underlying settings, crashes print preview. So my current workaround being checking the status of PP and closing and restarting it.

This means in e10s I need two tabs in the same process! First the tab of the webpage the printpreview gets bound, and then the print preview display. The statement via irc I got is that with e10s the tab shouldn't have direct connection to the OS and the whole thing gets a proxy. Chrome sandbox like. So the actually print out calls to OS runs somewhere the parent browser process? With the current system (hijacking a different browser) I have no idea how that should work.

The pdf reader comment was misleading. Technical my goal with my software is to create a perfect printout without any plugins or pdf workaround! Running a webkit browser headless on the server to create not so broken pdfs it's a shame to allow a printout on FF. But it's the de facto standard. 

FF is simply completely broken. As the pdf addon in FF uses the same broken technology, I face the same problem.
So technical there is still the need to use a PDF Reader plugin. The other way would be simpler, dropping support for FF for now. (Using Chrome/IE on win32 and a older Midori version on Linux)  Even IE10/11 gets a better print preview result on Win32. At least some Google Devs are interested with Webkit/Blink in printing.

So I started with writing an addon and reading into the print preview code of FF and trying to patch it without success.

When Bug 844473 doesn't even get attention I have no idea how I can help, if even simple stuff won't get fixed or at least a reason why not.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Oskar Eisemuth from comment #17)
> Calling enterPrintPreview again after changing underlying settings,
> crashes print preview. So my current workaround being checking the status of
> PP and closing and restarting it.
Have you filed a bug about the crash you see. Obviously you're using pp in a different way to normal FF, but
that doesn't mean the crash shouldn't be fixed. Please CC me to the bug.

> 
> This means in e10s I need two tabs in the same process!
So? There will be many tabs using the same process. All the window.open etc.
No problem with that.


> FF is simply completely broken.
It is not. But please file bugs about the issues you see.


> When Bug 844473 doesn't even get attention I have no idea how I can help, if
> even simple stuff won't get fixed or at least a reason why not.
There is a patch in bug 844473.  Does that fix the issue you see? If so, ask a review from someone.

Comment 19

[Oskar Eisemuth]

I can't fill a bug about this, without having a sample code so it can be triggered. For this I have to release a version of my inhouse addon.

Currently I am not willing to do this, however there is enough other problems:

Bug 947125 is exactly the sum up of the design/code flaws, currently I try to collect all bugs I see that a related so I won't create duplicates. 

Bug 844473, what should be done? Bugzilla asked me who I send the review to when attaching the patch. I am sorry. I don't know...

Comment 20

[Zack Weinberg (:zwol)]

(In reply to Oskar Eisemuth from comment #19)
> Bug 947125 is exactly the sum up of the design/code flaws, currently I try
> to collect all bugs I see that a related so I won't create duplicates. 

This work is very much appreciated.

> Bug 844473, what should be done? Bugzilla asked me who I send the review to
> when attaching the patch. I am sorry. I don't know...

In addition to what I said over there, if you can't figure out who should review a patch you can ask on IRC (irc.mozilla.org:#mentors is probably the best channel) - do this after posting the patch to a bug, so you can just mention the bug number in the chat room.

Comment 21

[Jonathan Watt [:jwatt]]

Closing this bug in favor of bug 133787.