Printing address book cards prints a blank page

VERIFIED FIXED in mozilla0.9.8

Status

SeaMonkey
MailNews: Address Book & Contacts
P3
normal
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: Simon Fraser, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
mozilla0.9.8
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nab-print)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

17 years ago
If you print an address book card, you get a blank page. I guess that XUL doesn't 
print.

Comment 1

17 years ago
reassigning to cavin
Assignee: chuang → cavin
Keywords: nsbeta1

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+

Comment 2

17 years ago
How do you print it?
(Reporter)

Comment 3

17 years ago
File->Print?
we're trying to run a url, like:

addbook:printone?email=sspitzer@netscape.com&folder=Collected%20Address%Book

that causes some assertions in the print engine code, as it first tries to 
figure of the message service for that url. 

then, we'll try to load it

rv = webNav->LoadURI(uri->get(), nsIWebNavigation::LOAD_FLAGS_NONE);

we never get back to the nsAddbookProtocolHandler.cpp, so we need to start 
there.

but if we get working, the protocol handler does some scary stuff to turn that 
url into a card, and then turn the card into html.

I think we're going to have to revisit how we print address books cards, and 
entire address books.

not being able to print is pretty bad, let's say 0.9.9 to get it on the radar.
Target Milestone: --- → mozilla0.9.9

Updated

16 years ago
Priority: -- → P3

Comment 6

16 years ago
is bug 54527 a dup of this?

Comment 7

16 years ago
It can't find a protocol handler whose scheme is "addrbook" and here is the 
stack trace. We only cache "chrome", "resource", "file" and "http" handlers.

nsIOService::GetCachedProtocolHandler(nsIOService * const 0x01d20f70, const char 
* 0x06329050, nsIProtocolHandler * * 0x0012d11c, unsigned int 0, unsigned int 0) 
line 332
nsIOService::GetProtocolHandler(nsIOService * const 0x01d20f70, const char * 
0x06329050, nsIProtocolHandler * * 0x0012d11c) line 413 + 21 bytes
nsIOService::NewChannelFromURI(nsIOService * const 0x01d20f70, nsIURI * 
0x06329cb0, nsIChannel * * 0x0012d160) line 784 + 46 bytes
NS_OpenURI(nsIChannel * * 0x0012d230, nsIURI * 0x06329cb0, nsIIOService * 
0x01d20f70, nsILoadGroup * 0x062f9850, nsIInterfaceRequestor * 0x062f8058, 
unsigned int 0) line 148 + 20 bytes
nsDocShell::DoURILoad(nsIURI * 0x06329cb0, nsIURI * 0x00000000, nsISupports * 
0x062fd360, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000) line 4221 
+ 89 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x062f8030, nsIURI * 0x06329cb0, 
nsIURI * 0x00000000, nsISupports * 0x00000000, int 1, const unsigned short * 
0x06329800, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned 
int 1, nsISHEntry * 0x00000000) line 4124 + 39 bytes
nsDocShell::LoadURI(nsDocShell * const 0x062f8030, nsIURI * 0x06329cb0, 
nsIDocShellLoadInfo * 0x063295e0, unsigned int 0) line 585 + 65 bytes
nsDocShell::LoadURI(nsDocShell * const 0x062f8040, const unsigned short * 
0x063287c0, unsigned int 0, nsIURI * 0x00000000, nsIInputStream * 0x00000000, 
nsIInputStream * 0x00000000) line 2256 + 36 bytes
nsMsgPrintEngine::FireThatLoadOperation(nsMsgPrintEngine * const 0x062fd640, 
nsString * 0x06328880) line 324 + 43 bytes
nsMsgPrintEngine::StartNextPrintOperation(nsMsgPrintEngine * const 0x062fd640) 
line 284 + 16 bytes
nsMsgPrintEngine::StartPrintOperation(nsMsgPrintEngine * const 0x062fd640) line 
253

Comment 8

16 years ago
Didn't mean to commit the comment as I was debugging the problem. Please ignore 
the previous comment.
here's one place to start, nsAddbookProtocolHandler.cpp:

NS_ASSERTION(0, "fix me, FindPossibleAbName");

I noticed other issues, like how we use nsAbCardProperty and how we call
GetMessageServiceFromURI with the addressbook url when we are trying to print 
it.

last time I looked, the way we printed addressbook card and how we contructed 
and ran the urls to do it looks very brain dead to me.  we should re-examine 
how to do this.
*** Bug 116991 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
*** Bug 59121 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
reassigning to sspitzer
Assignee: cavin → sspitzer
ok, I've made some progress on this.

at least, I've gotten it so that cards in the personal addressbook should print 
(but you'll get a few assertions).

I'll attach my patch, but there's still a lot of work to do to clean this code 
up.
Status: NEW → ASSIGNED
Created attachment 63642 [details] [diff] [review]
start of the patch, still working on it.
those changes will be needed when printing an entire addressbook is supported, 
but I'm working on changing the way we print single cards.

here's how it works now:

from the selection in the results pane we get the nsIAbCard and we create a 
addbook url (which isn't even a valid URL or URI), like this:

"addbook:printone?email=foo@bar.com&folder=Personal%20Address%20Book"

when we run that url, we try to find a card in the "Personal Address Book" with
the email "foo@bar.com".  if we find it, we get the fields out of it, generate 
some html, and then that's what gets read on the stream.  Some problems with 
that are what if you have more than one card with the same email?  also, there 
are bugs with determining the proper directory (see #54527)

here's what I've got working:

I've added to the nsIAbCard interface:

  wstring convertToHTML(in boolean aBase64Encode);

from the selected card, we call card.convertToHTML(true) and then the url we 
create is:

var url = "data:text/html;base64," + card.convertToHTML(true /* base64 encode 
*/);

the impl of ConvertToHTML() will generate (and base64 encode) the html for the 
card, for printing.

when we run that url, we don't have to look up anything, we won't be going 
through the addbook url handler at all, since mozilla can already handle data: 
urls.

for printing addressbooks, I'm going to rework it so we do this:

"moz-addbook://<foo>?action=printall"

<foo> will be the same thing we currently use for our addressbook uri paths.

then, on the backend, in the addbook protocol handler, when I get one of these 
printall urls, I'll get the addressbook, enumerate all the nsIAbCards, 
call card.convertToHTML() for each of them, and put that on the stream.
moving back to 0.9.8, closing in on a fix.
Target Milestone: mozilla0.9.9 → mozilla0.9.8
Created attachment 63743 [details] [diff] [review]
implement card printing with data: urls

items left:

1)  generate all the html for the card (not just the primary email)

later:

2)  clean up more of the addressbook backend code
3)  implement printing entire addressbooks
Attachment #63642 - Attachment is obsolete: true
cool, mozilla can print xml.

so instead of generating html, I'll generate xml, and provide a default .css 
file for the default styles to make the output look good.

then, we can restyle by modifying the output, or the user can style by 
modifying user.css

providing a way to generate xml for a card will be useful for when we add XML 
exporting of addressbooks.
blocked by #118613

printing data urls works, but only if the url is < 64 chars long.  rods is 
working on that.
Depends on: 118613
Created attachment 63918 [details] [diff] [review]
implement print ab cards, print addressbook, clean up of the addbook url code.

still todo:  
add a proper license to the new file (print.css)
Attachment #63743 - Attachment is obsolete: true

Comment 21

16 years ago
Comment on attachment 63918 [details] [diff] [review]
implement print ab cards, print addressbook, clean up of the addbook url code.

sr=bienvenu
Attachment #63918 - Flags: superreview+
Created attachment 63926 [details] [diff] [review]
patch, fixes some issues that bienvenu raised privately
Attachment #63918 - Attachment is obsolete: true
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Whiteboard: nab-print

Comment 24

16 years ago
Trunk build 2002-03-01: WinMe, Linux RH 7.1, Mac 9.1
Verified Fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.