297702 - Print compose window as formatted message - currently prints plain, unformatted text, no addresses or headers, no attachment informations, "about:blank" title

Status: NEW

(MailNews Core :: Printing, enhancement)

Description

[jakobi]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

printing from the compose window (context menu) doesn't
print the message header already supplied in the
compose window.

Reproducible: Always

Steps to Reproduce:
1. compose a message
2. context-menu-print
3.

Actual Results:  
printout without To:/Subject:/...

Expected Results:  
Added the user-provided mail headers in a block
before the actual text, possibly with a date
field marked with a comment as "compose-in-progress".

there's only an annoyingly long work-around...
(going to the sent folder and printing from there).

Comment 1

[jakobi]

294591 is an earlier report on this, from last year.

If I just need to rtfm, please also give me the manpage
in question to look at :).

Comment 2

[zug_treno]

Related to/duplicate of Core bug 158106?

Comment 4

[Thomas D. (:thomas8)]

This should be at least wanted, or even blocking 3.1.

This is basic functionality, and it's obviously incomplete. We can also assume that use cases are frequent where people would want to print out a msg before sending it so as to proof-read. It's about time to fix this. After 7 yrs (core bug 158106), we should no longer force people to use workarounds.

Don't forget to add a DRAFT heading on the printout somewhere, otherwise it'll be impossible to distinguish from real sent message.

(In reply to comment #2)
> Related to/duplicate of Core bug 158106?

Mailnews core bugs that refer to TB are getting more and more rare. I think the preferred category is now TB, which will make it easier to find, anyway.

Comment 5

[Thomas D. (:thomas8)]

At least the "unformatted" printing of drafts during composition lets us print Selections correctly: See bug 66806, probably technically related: bug 66806, comment 76 claims that for printing compositions, we actually just print the document which is on-screen, while otherwise, we create a separate print-document. That's interesting for this bug because what we print from received messages actually includes the headers that we don't print from drafts. Solving both bugs probably needs the best of both worlds.

Comment 6

[Thomas D. (:thomas8)]

Shame, even that little bit which we *do* print on those useless printouts from composition is WRONG:

Bug 759039 Submitted - Composition: Printing no subject (if draft not saved), or stale/old subject (if saved) in page header Title field

+1 for my "ridiculous" collection: Mail client can't print compositions directly, correctly and completely, unless using clumsy workarounds.

Comment 7

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #6)
-> ux-trust, ux-efficiency

Comment 8

[Thomas D. (:thomas8)]

Jim's attachment 627636 [details] has a nice mockup of how the printed output could look, and we could easily add "DRAFT" note e.g. below the date header on the right.

Comment 10

[Steffen Wilberg]

When Print or Print Preview is opened from the main window (not the compose window), nsMimeBaseEmitter::WriteHTMLHeaders (and the following functions) generates the Subject/From/Date/To table.
http://mxr.mozilla.org/comm-central/source/mailnews/mime/emitters/nsMimeBaseEmitter.cpp#908

Would be nice if that could be used here as well, instead of rewriting all of that.
I don't know where that's called from though.

Comment 11

[Thomas D. (:thomas8)]

Attachment: Patch V.1: (untested, wip) try to print draft with msg headers

Could I please have a try build and/or preliminary feedback if this succeeds (partially?) to do or the following:

When printing from "Write" window, print msg headers with msg body.

Jörg, if you are too busy, please relegate to someone else.

Comment 12

[Jorg K (CEST = GMT+2)]

Comment on attachment 8914143 [details] [diff] [review]
Patch V.1: (untested, wip) try to print draft with msg headers

Thomas, thanks for persisting with this. Applying a small patch and compiling is not a big deal, so I should find time for this (for you) any time.

I've done these experiments in Daily and with your patch:

Print preview message, then print and print message without preview.
Daily: Shows unwanted header, then prints it, direct print doesn't print it (known state).

The same for a compose window:
Daily: Shows "about:blank" (the URL of the compose window) in all three cases.

With your patch:
The very same behaviour, so no change at all.

Sorry that I don't have better news.

Comment 13

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #12)
Thanks. Sorry I wasn't clear enough about the expected result, so I think there has been a misunderstanding.

With patch attachment 8914143 [details] [diff] [review], I am NOT trying to fix *page* headers (Title, URL).

Current behaviour:
* Only message body text is printed/previewed, no information about message header (subject/from/date/to/cc/bcc).

Expected result with this patch:
(In reply to Thomas D. from comment #11)
> When printing from "Write" window, print *message headers* with msg body.
* So for print/(preview), I would expect the following information to be printed/shown:
HTML <table> with
- subject
- From
- Date
- To/CC/BCC

Are those message headers appearing anywhere? (I would be very surprised if they don't)

Comment 14

[Jorg K (CEST = GMT+2)]

Sorry about the misunderstanding (must be frustrating, but at least I'm replying quickly).

Neither direct print nor print preview show anything but the message body and about:blank.

Comment 15

[Jorg K (CEST = GMT+2)]

I accidentally found where the URL is suppressed: nsMsgPrintEngine.cpp:600:

      // fix for bug #118887 and bug #176016
      // don't show the actual url when printing mail messages or addressbook cards.
      // for mail, it can review the salt.  for addrbook, it's a data:// url, which
      // means nothing to the end user.
      // needs to be " " and not "" or nullptr, otherwise, we'll still print the url
      mPrintSettings->SetDocURL(NS_LITERAL_STRING(" "));

Comment 17

[Thomas D. (:thomas8)]

Alex / Geoff, this would be nice to have. The typical scenario is proof-reading an important message on paper before sending. The current printout from composition window is really useless: no headers, no attachment list, subject not emphasized, etc. Having to go back to 3-pane just for printing a formatted draft is pretty clumsy. Essentially, I think we'll want the write window to print just like a saved draft, and both the draft print and the write window print should have a clearly visible "Draft" indicator somewhere. Alex, what do you think?

Comment 18

[Alessandro Castellani [:aleca]]

Printing all styles and proper text formatting should indeed be supported.
I'm not sure about showing "Draft" in the printed page as I don't see the usefulness, but I'm not against it if there are some legit scenarios where it might be useful.

Comment 19

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #18)

Printing all styles and proper text formatting should indeed be supported.
I'm not sure about showing "Draft" in the printed page as I don't see the usefulness, but I'm not against it if there are some legit scenarios where it might be useful.

The "Draft" indicator is useful to distinguish a sent or received message from a draft message - otherwise there's no way to tell from the printout if it was actually sent or not, because after this bug, draft and sent messages will look exactly the same. The typical scenario is proof-reading a message on paper, doing some more changes, then sending it, and probably print the sent message again for archival purposes. "Draft" indicator then allows to distinguish the draft prints from the final sent message, and prevents a false impression from the draft print's time stamp etc. that the message has already been sent.