With this error in Error Console. Error: tabbrowser.loadOneTab is not a function Source File: chrome://global/content/printUtils.js Line: 216 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091216 Lightning/1.1a1pre Shredder/3.1a1pre ID:20091216032644

Sid should this be moved to CORE ?

(In reply to comment #0) > With this error in Error Console. You were trying to print from a tab right ?

(In reply to comment #2) > You were trying to print from a tab right ? Not only: I try to print from tab and I try also selecting a message in messages pane and then click on print preview (both context menu and menu-->File): all behaves the same and print the above message in error console.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100117 Shredder/3.2a1pre XP as well. Exit TB. Tb is still running and needs to be killed. If not and reopened it is non functional, at least as far as opening a imap connection.

Bug 487667 was about this time. I put this bug in that one for that cc

Sorry, I know next to nothing how Thunderbird does printing. I need to investigate this a bit, after figuring out why the latest TB doesn't build on my machine.

And for someone not too familiar with TB, what are the steps to reproduce, and which version of TB do I need to use (I assume trunk). Hmm, I thought TB 3.1 was going to be based on gecko 1.9.2, not 1.9.3.

Needs to block.. can't print without hanging TB. If printpreview (and I think even print) is clicked, once use exits TB the window closes. User must realize it is still active and use task manager to kill TB.

the problem happens on trunk, not with tb 3.1pre, right? tb3.1 will be based on gecko 1.9.2 which doesn't have the change to print handling. anyway, I'm about to start fixing this today. this is definitely a top priority bug for me.

(In reply to comment #9) > the problem happens on trunk, not with tb 3.1pre, right? > > tb3.1 will be based on gecko 1.9.2 which doesn't have the change to print > handling. Comment 1 was from before we created 3.2. This was a short period of time when 3.1 was running from gecko 1.9.3. Comment 4 also confirms this happens in 3.2/1.9.3. So I think we can definitely say it happens with gecko 1.9.3. > anyway, I'm about to start fixing this today. this is definitely a top > priority bug for me. I guess you've realised we don't have a tabbrowser... and most xulrunner applications won't. In case you hadn't realised and iirc, mailnews creates its own copy of the message in a standalone print preview window. It doesn't work as nice as it could, and I think there may be a reason behind it (though I don't expect you to fix that).

I believe I'll need to add a new <xul:browser> or <xul:iframe> for the print preview and hide the original document. (Nowadays we can show the print preview of any document in any other docshell container.)

sorry, got excited seeing an imminent release date

The patch takes similar approach as what bug 544018 has for view-source.

Still a problem, I clicked printpreview of one message and it came up ok and TB closed ok. But selecting a certain imap msg with an attachment, the print preview imformation dialog come ups up and it hangs there but not always. However the real problem is when I close the dialog box and exit program, TB doesn't close without killing it in task manager. Clicking print seems to work, only print preview has problems and it seems to be not all emails and those problem ones will preview sometimes. All of this is not a major problem if TB would only exit cleanly.

selecting a problem message, click pp, close loading dialog, then retrying. After this the pp window comes up ok. but I do get an error on this second good attempt. Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: :: line 638" data: no] Source File: chrome://global/content/bindings/browser.xml Line: 644

+ browser = document.createElement("browser"); + browser.setAttribute("id", "ppBrowser"); + browser.setAttribute("flex", "1"); + document.documentElement.appendChild(browser); Probably needs: disablehistory="true" disablesecurity="true"

review ping

I installed the patch and it still hangs TB. But it is better. Here's my most consistent STR mail.imap.mime_parts_on_demand = true mail.imap_mime_parts_on_demand_threshold = 1 // keep from caching mail.server.default.mime_parts_on_demand = true; mail.inline_attachments = false; open imap folder. Select a message with large attachments. Before it loads and displays hit the print preview. loading message dialog hangs and needs to close. subsequent previews seem to work ok. close TB TB is left open without a window, doesn't shutdown.

Hangs? Huh. A hang might be a different bug or not. I'll investigate. I assume you didn't have that hang before Bug 487667?

(In reply to comment #20) > Hangs? Huh. A hang might be a different bug or not. I'll investigate. > I assume you didn't have that hang before Bug 487667? Can't guarantee that as I always run a trunk build but this is only thing I have ran into hanging TB in my present install. As I mentioned before, hanging was always an effect of this bug but since the preview opens ok now on most occasions, when it does have a problem it's as if there's a loop still running after close.

(In reply to comment #20) > Hangs? Huh. A hang might be a different bug or not. I'll investigate. > I assume you didn't have that hang before Bug 487667? Can't guarantee that as I always run a trunk build but this is only thing I have ran into hanging TB in my present install. As I mentioned before, hanging was always an effect of this bug but since the preview opens ok now on most occasions, when it does have a problem it's as if there's a loop still running after close.

with the js debugger after running the STR and closing TB debugger shows open windows as messengercompose.xul msgPrintEngine.xul under this is the js files but also a subwindow called INBOX%3E1312 which is probably the file name portion of the imap url

Comment on attachment 425980 [details] [diff] [review] patch Sorry, I tried looking at this today and I can't get my windows build working and I don't want to delay the review longer, so I'm passing this over to David who can hopefully take a look at it.

Comment on attachment 425980 [details] [diff] [review] patch This works great. We should, however, have a mozmill test for this...

the failure I saw on shutdown w/o this patch had to do with an uncaught exception in the onUnload handler in specialtabs trying to remove an observer: http://mxr.mozilla.org/comm-central/source/mail/base/content/specialTabs.js#834 w/ this patch, there's no such problem.

http://hg.mozilla.org/comm-central/rev/1b0341bc4d0a I tried print preview with several large attachments and it seemed to work. Phil, if you still see some problems, please file new bugs.

Looks like this broke Print Preview here, see bug 535343.