Closed Bug 424767 Opened 14 years ago Closed 14 years ago

start page "about:" gives XML Parsing Error: undefined entity

Categories

(MailNews Core :: Security, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9

People

(Reporter: mkmelin, Assigned: philor)

References

Details

(Keywords: regression, Whiteboard: [workaround: comment 6])

Attachments

(1 file)

STR:
1) Set your start page as "about:". 
2) Go -> Mail Start page

XML Parsing Error: undefined entity
Location: jar:file:///opt/softa/moz/nightly/2008-03-07_trunk/thunderbird/chrome/toolkit.jar!/content/global/about.xhtml
Line Number 70, Column 9:    <li>&about.copy.beforeLink; <a href="about:credits">&about.copy.linkTitle;</a> &about.copy.afterLink;</li>
--------^

This broke 20080222 -> 20080223 (linux builds)

In that range, bug 418119 looks like the likely culprit, since I think the entities nor the xml didn't really change.

I think network error pages in thunderbird is broken too. (Try the url "about".)
Yes, it seems that the DTDs for this page were blocked by some content policy. However, all these DTDs are chrome:// URLs, if I read nsMsgContentPolicy correctly those will always be let through. And that's the only mail-specific content policy from what I can tell.
According to bug 349985, the about page doesn't have chrome privileges, however. 

(There is also an older bug for the showing the icon on that page properly - bug 391600.)
You don't need chrome privileges to load DTDs from chrome://, any web page can do that (which was exactly the point of bug 418119).
Flags: blocking-thunderbird3?
[Mozilla Thunderbird, version 3.0a1pre (2008041903)] (nightly) (W2Ksp4)

Confirmed, with Windows.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Confirmed, with SeaMonkey.

{{
XML Parsing Error: undefined entity
Location: jar:file:///.../seamonkey/chrome/toolkit.jar!/content/global/about.xhtml
Line Number 70, Column 9:
    <li>&about.copy.beforeLink; <a href="about:credits">&about.copy.linkTitle;</a> &about.copy.afterLink;</li>
--------^
}}
(+ same error in Error Console)


|dom.report_all_js_exceptions| and |javascript.options.strict| don't show up anything more.
Assignee: nobody → dveditz
Component: General → Security
Flags: blocking-thunderbird3?
OS: Linux → All
Product: Thunderbird → Core
QA Contact: general → toolkit
Summary: start page "about:" gives XML Parsing Error: undefined entity → SeaMonkey/Thunderbird <about:> start page gives "XML Parsing Error: undefined entity"
Target Milestone: --- → mozilla1.9
Flags: blocking1.9?
Bug 400263 comment 17 gave me a hint:

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla Thunderbird, version 3.0a1pre (2008041903)] (nightly) (W2Ksp4)

Still works fine:
<chrome://global/content/about.xhtml>

Broken:
<about:>

That's a workaround for developers,
but end-user won't guess the <chrome://...> URL.

NB: FWIW, <about:config> works fine.
Depends on: 349985
(Or could it be related to bug 427333 ?)
Sort of vaguely amusing, if you have a taste for that sort of thing: yes, our content policy allows through all the chrome:// DTDs. Then, since we're loading XHTML, the xhtml11.dtd is loaded from a file:/// URI, and we deny it.
Assignee: dveditz → nobody
Component: Security → MailNews: Security
Flags: blocking1.9?
QA Contact: toolkit → security
Hardware: PC → All
Attached patch Fix v.1Splinter Review
Lots of ways we could go here, right down to precisely saying that for DTD loads with aRequestingLocation being about: and aContentLocation being file: and xhtml11.dtd we'll allow it (and then working around Tb not liking about:logo similarly), but really, in terms of message content policy as distinct from security, I just don't think we care what about: wants to load, as long as everything else has vetted it.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #316973 - Flags: superreview?(neil)
Attachment #316973 - Flags: review?(bienvenu)
No longer depends on: 349985
Summary: SeaMonkey/Thunderbird <about:> start page gives "XML Parsing Error: undefined entity" → start page "about:" gives XML Parsing Error: undefined entity
Blocks: 391600
Attachment #316973 - Flags: superreview?(neil) → superreview+
Setting to block Thunderbird 3.0a2, given how useful this is to QA folks who want to be able to paste a full user-agent string into Bugzilla.
Flags: blocking-thunderbird3.0a2+
about: gives the following error on OS X on the latest trunk nightly:

XML Parsing Error: undefined entity
Location:
jar:file:///Applications/Internet%20Apps/Thunderbird%203.app/Contents/MacOS/chrome/toolkit.jar!/content/global/about.xhtml
Line Number 70, Column 9:    <li>&about.copy.beforeLink; <a
href="about:credits">&about.copy.linkTitle;</a> &about.copy.afterLink;</li>
--------^

This makes it difficult for QA to get full user agent strings for testing and
bugs. 
(In reply to comment #10)
> Setting to block Thunderbird 3.0a2, given how useful this is to QA folks who
> want to be able to paste a full user-agent string into Bugzilla.
> 
Why not update our Help->About page to include the full user-agent string, similar to the Firefox way? See Bug 426046...
(In reply to comment #10)
> Setting to block Thunderbird 3.0a2, given how useful this is to QA folks who
> want to be able to paste a full user-agent string into Bugzilla.

While I'm happy as this should help to get a fix,
this rationale might not be the good one as there is a workaround in comment 6,
which I guess is "enough" for QA-users.

(In reply to comment #12)
> Why not update our Help->About page to include the full user-agent string,
> similar to the Firefox way? See Bug 426046...

Both are (wanted/)open bugs ;->
Whiteboard: [workaround: comment 6]
(In reply to comment #13)
[...]
> While I'm happy as this should help to get a fix,
> this rationale might not be the good one as there is a workaround in comment 6,
> which I guess is "enough" for QA-users.
[...]
yes, if they find out about it, and I wouldn't say it's really "discoverable", other than by visiting this bug or a couple of others where that workaround is mentioned.
Comment on attachment 316973 [details] [diff] [review]
Fix v.1

thx, Phil.
Attachment #316973 - Flags: review?(bienvenu) → review+
mailnews/base/src/nsMsgContentPolicy.cpp 1.53
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008051402 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

V.Fixed
Status: RESOLVED → VERIFIED
Product: Core → MailNews Core
Depends on: 522019
You need to log in before you can comment on or make changes to this bug.