Print Preview Card and Abook both unuseable

RESOLVED FIXED in Thunderbird 3.0a3

Status

defect
P1
major
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: ronkillmer1, Assigned: philor)

Tracking

({regression})

Trunk
Thunderbird 3.0a3
Bug Flags:
blocking-thunderbird3 +
wanted-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080818131059 Shredder/3.0b1pre

Print preview in Abook is not something I usualy pay attention to.  However after reading th Standard8 blog on the new menu widget I decided to lokk around in Abook and explore functions I seldomly pay attention to.  This is a regression, with no clue to when it broke.

Reproducible: Always

Steps to Reproduce:
1. Select an Abook
2. Select a Card
3. Select either Preview option for File menu
Actual Results:  
Print Preview card is dead, no activity. Console reports:
Error: AbPrintCardPreview is not defined
Source File: chrome://messenger/content/addressbook/addressbook.xul
Line: 1

Print Prview Abook opens the Preview window, but tosses:
Error: 
Source File: addbook://moz-abmdbdirectory/abook.mab?action=print
Line: 2, Column: 1
Source Code:
<?xml-stylesheet type="text/css" href="chrome://messenger/content/addressbook/print.css"?>

Additional the Console reports Warning:
Security Error: Content at addbook://moz-abmdbdirectory/abook.mab?action=print may not load or link to chrome://messenger/content/addressbook/print.css.
 

Expected Results:  
View a preview of the printed content of either a card or Abook.
Nominated for Blocking Tb 3
Flags: blocking-thunderbird3?
Spotchecked Shredder 3.0a2 and it also fails.  This is a trunk issue as the Tb 2.0 branch works.
FWIW it's broken in Seamonkey 2.0a1pre also.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-thunderbird3+
Keywords: regression
Priority: -- → P1
Product: Thunderbird → MailNews Core
QA Contact: address-book → addressbook
Target Milestone: --- → Thunderbird 3.0b1
Version: unspecified → Trunk
Duplicate of this bug: 451866
I think there are two bugs here:

1) is the fact the function (AbPrintCardPreview) is not defined, Joshua - could you take a look at that please?

2) The security error:

Security Error: Content at addbook://moz-abmdbdirectory/abook.mab?action=print
may not load or link to chrome://messenger/content/addressbook/print.css.

I think remember seeing an email about this a year or two ago (possibly from bz?). David, can you remember?
Untrusted content can only link to chrome packages that explicitly say they can be linked to from untrusted content.

Is addbook untrusted content?  Does messenger say it can be linked to by the world?  If so, you'll get that error message.  Note that I suspect that messenger does NOT want to be world-accessible.  I have no idea whether the addbook URI is trusted; that's your call.  ;)
Whiteboard: [needs patch for new gecko rules]
Marking blocking‑thunderbird3+, wouldn't want to ship (final) without this fixed.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
OS: Windows Vista → All
Hardware: PC → All
Assignee: nobody → bugzilla
This patch corrects the errors that we currently have in calling print preview card - this doesn't fix the underlying security issue. So with this patch applied, print preview card and print preview address book will end up in the same state.

The base64 -> base64xml was a missed change in bug 413260, the function call seems to have been wrong for a long time.

Once this patch is in, I'll take a look at the main issue.
Attachment #339234 - Flags: superreview?(bienvenu)
Attachment #339234 - Flags: review?(bienvenu)
Attachment #339234 - Flags: superreview?(bienvenu)
Attachment #339234 - Flags: superreview+
Attachment #339234 - Flags: review?(bienvenu)
Attachment #339234 - Flags: review+
Whiteboard: [needs patch for new gecko rules] → [js/xul errors fixed][needs patch for new gecko rules]
Comment on attachment 339234 [details] [diff] [review]
[checked in] Correct errors for print preview card

Checked in, changeset id: 374:9ff1eeabeae4
Attachment #339234 - Attachment description: Correct errors for print preview card → [checked in] Correct errors for print preview card
By comparison we put the message body CSS into its own contentaccessible package (somewhat obviously named messagebody) and then promptly overrode its new chrome URI with the original URI that we were previously using.
(In reply to comment #10)
> By comparison we put the message body CSS into its own contentaccessible
> package (somewhat obviously named messagebody) and then promptly overrode its
> new chrome URI with the original URI that we were previously using.

I don't see how that benefits not having to expose a URI/protocol (in this case the addbook one).

From discussion on irc with Dan, we decided that the addbook protocol had been written with exposure in mind, although we'd do a security review before final release.

Boris, where do I look for being able to expose the addbook protocol that this needs?
Well, the addbook protocol *is* exposed, by http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/addrbook/src/nsAddbookProtocolHandler.cpp&rev=1.61&mark=85-89#85 - because of the way we do vcards, as a link to an addbook URI that we stick into the message content, it has to be loadable_by_anyone, which means it can only link to chrome:// URIs that are contentaccessible, which means we only have two options, to either make every chrome URI needed by an addbook URI contentaccessible, or to be sluts like browser/ and make everything contentaccessible. Since you don't want to be a slut, like Neil said, you look at how bug 428996 exposed a single chrome://messenger/ URI as a contentaccessible chrome://messagebody/ override, and do that with print.css and any other chrome URIs that addbook URIs need to use.

(Okay, we have a third option, do vcards in chrome instead of content, but...)
Comment 12 pretty much covers everything I was going to say in response to comment 11, I think (and more).
Sort of like this.
Attachment #340078 - Flags: superreview?(neil)
Attachment #340078 - Flags: review?(bugzilla)
Oops. This would be the "paying attention to what I'm doing" version, where I realize that those are the only two uses and nobody else is jarring it up under a different URI.
Attachment #340078 - Attachment is obsolete: true
Attachment #340091 - Flags: superreview?(neil)
Attachment #340091 - Flags: review?(bugzilla)
Attachment #340078 - Flags: superreview?(neil)
Attachment #340078 - Flags: review?(bugzilla)
Whiteboard: [js/xul errors fixed][needs patch for new gecko rules] → [js/xul errors fixed][needs review Neil,standard8]
Attachment #340091 - Flags: superreview?(neil) → superreview+
Comment on attachment 340091 [details] [diff] [review]
contentaccessible print.css, v.2

I wonder whether it's stretching a point for it to be called messagebody ;-)
Attachment #340091 - Flags: review?(bugzilla) → review+
Assignee: bugzilla → philringnalda
Whiteboard: [js/xul errors fixed][needs review Neil,standard8] → [needs landing]
http://hg.mozilla.org/comm-central/rev/3a7803661daa

I thought about the messagebody thing for a minute, but since the point is "even if you aren't using this chrome://messagebody/ URI in a message body, anyone else can" I think it's best not to have any other, more subtle, way to make a URI contentaccessible.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
You need to log in before you can comment on or make changes to this bug.