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

RESOLVED INVALID

Status

()

Core
XUL
RESOLVED INVALID
16 years ago
10 years ago

People

(Reporter: bsharma, Assigned: John Morrison)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
Created attachment 106753 [details]
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.
(Assignee)

Comment 2

16 years ago
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).
(Assignee)

Comment 3

16 years ago
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).
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.
(Assignee)

Comment 5

16 years ago
> 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)].
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Assignee)

Comment 6

16 years ago
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).
Group: security

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.