dcone, this may be a dup of bug #12504, but I'm not sure yet.
Status: NEW → ASSIGNED
Depends on: 12504
we depend on 12504...until printing with frames works, we can't print an email message correctly. accept bug.
Target Milestone: M11
marking m11. but it depends on when 12504 is fixed.
Triage to M15
Bug 12504 (which this bug is dependent on) is marked a dup of 7201. So, I added 7201 to the dependency list.
Release Note for M11
Assignee: sspitzer → rhp
Status: ASSIGNED → NEW
re-assign to rhp. the current plan is to create a new emitter that will create a frameless version of a mail message for printing. (we can't print a document with frames)
Have to dig into this one. - rhp
There is now a printing format in libmime or you can use the arguments: ?header=print on the end of the mailbox: or IMAP url and you should get something that looks very similar to the normal output. - rhp
Target Milestone: M13 → M14
moving this to m14.
Priority: P3 → P2
Release Notes for M13
Nominating for Beta 1. The information in the headers of a mail message is valuable. Not having this in a print out makes the hard copy much less valuable. While it would be great to live in a world without paper, the majority of users print lots of mail messages, which makes this a high impact, high usage problem.
Putting on PDT+ radar for beta1.
Summary: [PRINTING] printing mail only prints message body, not the headers → printing mail only prints message body, not the headers
rich is going to help me out.
Assignee: sspitzer → rhp
Status: ASSIGNED → NEW
I'm all over it like hair on a monkey. - rhp
Status: NEW → ASSIGNED
I have my functionality in place for this, but I need some answers from the webshell/doc loader guru's so I'll probably need an extra day for this. - rhp
Whiteboard: [PDT+] Checkin by: 2/14/00 → [PDT+] Checkin by: 2/15/00
If not fixed by 03/03, will punt for beta. Please put an ETA to fix in the Status Whiteboard.
Whiteboard: [PDT+] [UNKNOWN] → [PDT+] [UNKNOWN] Must fix by 03/03
Whiteboard: [PDT+] [UNKNOWN] Must fix by 03/03 → [PDT+] w/b minus on 02/25[UNKNOWN]
Whiteboard: [PDT+] w/b minus on 02/25[UNKNOWN] → [PDT+] w/b minus on 3/3 [UNKNOWN]
Marking PDT- for beta1. Would like to have this, but we're out of time for making new features work.
Whiteboard: [PDT+] w/b minus on 3/3 [UNKNOWN] → [PDT-] w/b minus on 3/3 [UNKNOWN]
mscott, you are the man! you've cut the Gordian Knot once again!
it looks like mscott has a fix for this, right on the 3/3 cut off date. clearning status whiteboard, to get PDT re-evaluation. this would be a great bug to fix for beta.
Whiteboard: [PDT-] w/b minus on 3/3 [UNKNOWN]
Uh, almost...he got me a fix for the observer issue, but there are some issues with knowing when the print operation is done that I am working on. There is no listener mechanism for print operations so now I am trying to find a way to close out the print window. - rhp
Good news on this bug. I solved all the problems and at least on Win32 it is working like a charm...feedback and all :-) Now, to get this stuff done, I needed to create a new interface nsIPrintListener.idl and that logically lives in mozilla\layout. Then I needed to make some small changes to \mozilla\mailnews\base\src\nsDocumentViewer.cpp and nsPluginViewer.cpp. With all of this, it is working for mail printing and will allow the browser folks to give some feedback in the UI.
Ok, I'll make my case to get this into the tree. Personally, I think this is a really bad problem to ship a beta with. If you print a mail message, I really think you should get the entire message, not just the body. I have the changes in the tree. They have been reviewed by mscott and dcone since it hits both of their areas. They all think this is a good approach to solve the problems and I have it compiled and running on Win32, Linux and Mac. I rest my case :-) - rhp
I should say that I have the changes in MY tree(s). - rhp
Putting on PDT- radar for beta1.
Jan - Rich already has fix for this. Plus, this "feature" is on our beta1 criteria page from marketing.
rich is the print window now hidden or is it still visible to the user?
No, its offscreen...I have everything working with this feature including multiple print operations. - rhp
If PDT does decide to fix this then I need to spend more time looking at the fixes I gave rhp before I consider them primetime for beta. Some of the load group manipulation to get printing for pop and news need to be thought out some more to make sure I'm doing the right thing.
Well, considering we don't print headers with email, I wouldn't think instability would be as bad as stable and non functional. With printing working like it does currently, I think its pretty useless. But that's just one man's opinion... - Rich
I think it's pretty clear we are taking stability over functionality at this point in the beta game.
Just putting this on the M15 train...all aboard! - rhp
Summary: printing mail only prints message body, not the headers → [FIXED] printing mail only prints message body, not the headers
Target Milestone: M14 → M15
Upadating QA Contact to Printing tester.
QA Contact: fenella → shrir
*** Bug 5658 has been marked as a duplicate of this bug. ***
By the way, it turns out my innocent change to the imap protocol to get this working for imap has some pretty nasty side effects. About half the time I run, every time we try to display a message, we attempt to unload the xul for the chrome in the 3pane. You'll see the words "Onload xul...cleanup()" printed to the console. This isn't good. In case the tree opens to general checkins over the weekend before I get a chance to look at this, please don't check that in =).
Well, when I get my part of the change checked in (i.e. layout, base, etc), I will forward this bug to you. - rhp
Hi Scott, My changes are all in the tree so the rest is up to you. Now, when you print, you will see a window pop up ... unfortunately, the XPFE guys changed something that prevents XUL from creating offscreen windows, but there is another bug pending where they are going to allow us to create a hidden window from XUL. - rhp
Assignee: rhp → mscott
Status: ASSIGNED → NEW
Summary: [FIXED] printing mail only prints message body, not the headers → Printing mail only prints message body, not the headers
rhp - would your fix also work for printing in the compose window (if the Print menu item were enabled?)
*** Bug 33757 has been marked as a duplicate of this bug. ***
Because of the current state (printing doesn't work at all - not just the headers having problems printing), I'm adding dogfood keyword.
Keywords: beta1 → dogfood
Putting on PDT+ to fix on the TRUNK ASAP!
Whiteboard: [PDT+] TRUNK ONLY
I agree that this is important but we haven't had it working in the product yet. I disagree that it needs to become the most important thing that I work on all of the sudden =).
mscott, this is still on the M15 radar. We need to decide today what's happening with it. Thanks.
just putting my 2 cents in. I can see this being beta2 but is this really M15 since as mscott says, it's never worked? This doesn't really add any stability to the product.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
I get a crash on linux trunk and branch builds for today. Windows builds (trunk and branch) print a mail message fine with no crash. WAs this fixed only on windows? Stack Trace: Trigger Type: Program Crash Trigger Reason: SIGPIPE: Write on Pipe, with no one to read: (signal 13) Call Stack: (Signature = libc.so.6 + 0xa4df4 (0x40384df4) a7f8b7eb) libc.so.6 + 0xa4df4 (0x40384df4) libc.so.6 + 0x55634 (0x40335634) libc.so.6 + 0x55714 (0x40335714) libc.so.6 + 0x551d0 (0x403351d0) libc.so.6 + 0x548a5 (0x403348a5) libc.so.6 + 0x56017 (0x40336017) libc.so.6 + 0x4b0bc (0x4032b0bc) libc.so.6 + 0x4637d (0x4032637d) libc.so.6 + 0x4cf47 (0x4032cf47) nsPostScriptObj::box() nsRenderingContextPS::FillRect() nsCSSRendering::PaintBackground() nsTableCellFrame::Paint() nsTableRowFrame::PaintChildren() nsTableRowFrame::Paint() nsTableRowGroupFrame::PaintChildren() nsTableRowGroupFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableFrame::Paint() nsContainerFrame::PaintChild() nsTableOuterFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsContainerFrame::Paint() PresShell::Paint() nsView::Paint() nsViewManager2::Display() nsSimplePageSequenceFrame::Print() DocumentViewerImpl::PrintContent() DocumentViewerImpl::DocumentReadyForPrinting() DocumentViewerImpl::Print() nsMsgPrintEngine::OnEndDocumentLoad() nsWebShell::OnEndDocumentLoad() nsDocLoaderImpl::FireOnEndDocumentLoad() nsDocLoaderImpl::DocLoaderIsEmpty() nsDocLoaderImpl::OnStopRequest() nsLoadGroup::RemoveChannel() nsFileChannel::OnStopRequest() nsOnStopRequestEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x407ea52a) libglib-1.2.so.0 + 0xfbe6 (0x407ebbe6) libglib-1.2.so.0 + 0x101a1 (0x407ec1a1) libglib-1.2.so.0 + 0x10341 (0x407ec341) libgtk-1.2.so.0 + 0x8c209 (0x40713209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402f81eb)
are you still seeing this crash shrir? If so, then we should open a new bug for this problem as it doens't appear to be mail related at all. Looks like somewhere down in: nsPostScriptObj::box() nsRenderingContextPS::FillRect() nsCSSRendering::PaintBackground()
Linux (2000-04-21-08 M16) Win32 (2000-04-21-09 M16) Mac (2000-04-21-08 M16) Printing mail now prints header and body.
Status: RESOLVED → VERIFIED
QA Contact: shrir → fenella
You need to log in before you can comment on or make changes to this bug.