180756 - Is XUL script disabled in mail? Does it obey the regular pref?

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[bsharma]

This bug is reported as the issue in the module review and jrgm asked me to make
a bug out of it.

John will provide the test case.

Comment 1

[John Morrison]

Attachment: test mailbox

This is a test mailbox. Drop this into your <profile>/<salt>/Mail/Local
Folders/
when the browser is not running and then start mail and open this folder.
(Optionally, copy these documents up to an IMAP server and load from there).

This mailbox has three messages in it: an HTML document, an XML document, and 
a XUL document, with appropriate 'Content-type:' headers. All three documents
will fire an alert in the onload handler of the document when viewed in the
browser.

Comment 2

[John Morrison]

So, when you open that mailbox and view each message, if preference
|javascript.allow.mailnews| is false, then the alert will not fire for
any of the documents. 

If |javascript.allow.mailnews| is true, then the onload alert will fire 
for the HTML message, but not for the XUL or XML messages.

However, this really doesn't have anything to do with XUL or XML doing the 
right check of that preference. Mailnews will create a full-fledged HTML 
content-viewer for the HTML case, and the code in nsScriptSecurityManager.cpp
that honors that pref will be triggered.

For the XML case, it appears that a plain text viewer is created (the raw 
XML is visible inline in the message body), so the security check is moot.

For the XUL case, it appears (or I guess) that it creates no content viewer,
since the XUL file is just shown as an attachment, and the security check is
again moot.

Now it looks like if the right content viewer were created for XML and XUL 
then the right security check would happen to honor that mailnews pref (i.e.,
that check occurs during the course of a normal browser document load with 
the right content viewer). 

So, I'd say that this looks OK, although maybe this should be passed on to 
someone in mailnews to check that my statement in the previous paragraph is
really true. (In other words, if at some point in the future the handling of 
XML of XUL documents in mailnews is changed to get the right content viewer,
then the security check will definitely happen).

Comment 3

[John Morrison]

p.s., I also tried this with attachments of XUL, HTML and XML, and the same 
situation applies there (i.e., HTML gets an viewer that can handle scripts,
while XML and XUL do not).

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

As long as XML and XUL don't get rendered inline their scripts will certainly
not be run, regardless of prefs. If I understood you correctly that is what
happens. Before closing as invalid, send youself a mail where you have XML and
XUL attachment and see what happens.

Comment 5

[John Morrison]

> Before closing as invalid, send youself a mail where you have XML
> and XUL attachment and see what happens.

Done. XML attachments are shown inline as plain text, and XUL attachments
are not shown inline, only as an entry in the attachments pane.

> As long as XML and XUL don't get rendered inline their scripts will
> certainly not be run, regardless of prefs. If I understood you
> correctly that is what happens.

Yes, that is correct. The pref is moot since they are not rendered 
inline (by a content viewer that will try to execute script).

But if that were to change in the future, I'm not entirely certain that
the pref would be honored. It _looks_ like it would. I'm just flagging
this as a way we might unintentionally introduce a problem in the future.
CC: some mailnews folks, just to mention this.

-----
[By the way, mailnews will not send an XML or XUL file when you do
'File->Send Page...'. It just drops it on the floor. At this time we
don't care about this for XUL I suppose, but I suppose we might for
XML. (I didn't check XHTML as text/xml, but I assume it wouldn't be
sent either)].

Comment 6

[John Morrison]

Hmm, I guess we still have that bug where adding to CC: still excludes the newly 
added members from getting mail from a security bug. Maybe a second try will 
work. mscott, sspitzer: see http://bugzilla.mozilla.org/show_bug.cgi?id=180756#c5
just FYI (no action required).