Closed Bug 216417 Opened 22 years ago Closed 22 years ago

about: page has major errors

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.6alpha

People

(Reporter: mozilla, Assigned: Biesinger)

References

Details

(Keywords: fixed1.5, regression)

Attachments

(2 files)

Screen capture
15.56 KB, image/png
Details
patch
1006 bytes, patch
bzbarsky
: review+
bzbarsky
: superreview+
asa
: approval1.5+
Details | Diff | Splinter Review
20030810 and 20030815 trunk builds Help -> About Mozilla leads to page that says, "%brandDTD; %regionDTD; ]>" at the very top. Where it should say Mozilla 1.5b, it says "&brandShortName; 1.5b" in huge letters instead.
wfm windows server 2003 2003081515 trunk
Attached image Screen capture —
confirmed
well it does not seem to be in the code, code from a build20030824 does the same thing on my build which is also 20030824? got the code from someone else
as klaas alluded to I passed him the code from my build (20030823/trunk/OS X) and he saw this rendering problem (he also confirmed via IRC there isn't any difference in the code from our two builds), although I don't see any rendering errors with that same code, nor do I see this rendering error in any recent trunk nightly on OS X.
Duplicate of bug #217378 ?
*** Bug 217378 has been marked as a duplicate of this bug. ***
I have also met with the same bug. My case, this bug appeared after Mozilla 1.5a trunk to now (1.5b trunk). Now trying, I uninstall 1.5b trunk and install release 1.4, this bug disappeared.
FWIW, I can confirm this using 1.5b on both Windows 98 and Windows XP.
It seems I can't repro on OS X for whatever reason... can someone take the time to attempt to track down a regression window? setting blocking 1.5? flag... I know there's nothign close to a fix but it would look bad if this bug made it into a 1.5Final
Flags: blocking1.5?
Keywords: regression
It looks like the data inside of <!DOCTYPE > is interpreted as HTML data or deplaced into <HTML> tag instead of begin used as DTD information. Or maybe the <!DOCTYPE tag is closed too early while loading the page? I tried to save the page into a file using 2 versions and I get the following results. Also, if I load the page generated with the older version into 1.5b, I get the same problem. When saving to HTML the about: page using 1.5b, I get something like: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>About:</title><style type="text/css"> ... (css styles skipped in the sample) </style></head> <body><!--ENTITY % brandDTD SYSTEM "chrome://global/locale/brand.dtd" --> <!--ENTITY % regionDTD SYSTEM "chrome://global-region/locale/region.dtd" --> %brandDTD; %regionDTD; ]&gt; When saving the same page using 1.2.1 (I did not try with later version) I get the correct data: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [ <!ENTITY % brandDTD SYSTEM "chrome://global/locale/brand.dtd" > <!ENTITY % regionDTD SYSTEM "chrome://global-region/locale/region.dtd" > %brandDTD; %regionDTD; ]> <!-- - The contents of this file are subject to the Netscape Public ...
I cannot reproduce on RH 9 with the latest trunk nightly build.
Still seeing the same as in the screenshot (http://bugzilla.mozilla.org/attachment.cgi?id=129928&action=view) in 2003090304 trunk.
not going to hold the release for this. we'd consider approving a reviewed patch.
Flags: blocking1.5? → blocking1.5-
Sounds like we might be treating the document as HTML instead of XML somehow.
When you see the problem, could someone right click on the page and do "View Page Info" and tell us what the MIME type is?
URL: about: Type: text/html Render Mode: Standards compliance mode Source: (not cached) Encoding: UTF-8 Size: Unknown
Hmm. It's supposed to be "application/xhtml+xml". That's likely the cause of the problem, but the question is what's causing that... bz, any idea?
Will changing the content-type to XML make Mozilla magically fill in the variables when it displays the page? As it is, the source is filled with variables like "&releaseURL;" and "&vendorURL;" and so on. Being completely unfamiliar with how the about page is constructed, it seems though like something isn't replacing the variables with the appropriate values before the about page is stuck into the Mozilla builds. I think this might be in addition to the fact that it's got the wrong content-type.
Almost certainly fallout from bug 212468 -- we used to force the "xhtml" extension to the XHTML MIME type, but now we go out to helper app settings and the OS before treating things with that extension as XHTML (and apparently Windows maps that extension to text/html, yay). I think we need to add xhtml to defaultMimeEntries.
hmmm. that would work, but why does this need to happen at all for about: pages? Can't Mozilla _know_ the content type of them? (This could be fixed by renaming about.xhtml to about.xml, right?) I'd rather not increase the list of unoverridable extensions...
It's not just about: pages... we also want to treat .xhtml pages coming from disk via file:// as xhtml, because that allows reasonable testing. As for about:, it's basically a redirector to a chrome:// url, so it doesn't have much control over the MIME type reported.... (it could probably call SetContentType at some point if really desired, but that would not help the general .xhtml problem, of course). about.xml would be a workaround, yes. Again, it would only solve part of the problem... I don't like adding entries to that array either, but I think we need this one.
Verifying that renaming about.xhtml to about.xml fixes all problems reported in this bug.
hmm... ok then... taking to add a default .xhtml->application/xhtml+xml mapping
Assignee: general → cbiesinger
Attachment #131262 - Flags: superreview?(bz-vacation)
Attachment #131262 - Flags: review?(bz-vacation)
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
I do not know what the patch does, but just in case: adding "application/xhtml-xml" under Prefs for the xhtml extension does not fix this bug. Is that what the patch does? However, changing the MIME type in the Windows registry under HKEY_CLASSES_ROOT\.xhtml to application/xhtml+xml from text/html DOES fix this bug.
Comment on attachment 131262 [details] [diff] [review] patch r+sr=me if you also add .xhtm in addition to .xhtml.... What this patch does is make it impossible for either the OS or user prefs to override this extension.
Attachment #131262 - Flags: superreview?(bz-vacation)
Attachment #131262 - Flags: superreview+
Attachment #131262 - Flags: review?(bz-vacation)
Attachment #131262 - Flags: review+
> adding >"application/xhtml-xml" under Prefs for the xhtml extension does not fix this >bug. that's bug 217893
So is that, in fact, what this patch does (add application/xhtml+xml to the helper apps)? If so we need to add bug 217893 to the dependency list.
no, it's not, not in the way you mean it...
checked in, with .xhtm added Checking in nsExternalHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v <-- nsE xternalHelperAppService.cpp new revision: 1.214; previous revision: 1.213 done
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment on attachment 131262 [details] [diff] [review] patch this fixes the display of the about: page; it should be low risk
Attachment #131262 - Flags: approval1.5?
checked in a change of .xhtm to .xht, per email from bz
Comment on attachment 131262 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch. Please add the fixed1.5 keyword when this is landed on the branch. Thanks.
Attachment #131262 - Flags: approval1.5? → approval1.5+
*** Bug 219249 has been marked as a duplicate of this bug. ***
fixed on 1.5 branch Checking in nsExternalHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v <-- nsE xternalHelperAppService.cpp new revision: 1.210.8.1; previous revision: 1.210 done
Keywords: fixed1.5
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: