Closed Bug 29125 Opened 25 years ago Closed 25 years ago

XHTML pages not displayed unless <?xml...?> omitted

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: graf, Assigned: chrispetersen)

References

(
URL
)

Details

(Keywords: xhtml)

Attachments

(1 file)

m16/build200022820 crashes too
300 bytes, text/plain
Details
XHTML-formatted pages don't get displayed in the browser past M13, including the latest build -- just black screen. The page works if the top first line, <?xml version="1.0" ?> is removed. However, that line is required by the XHTML standard.
Confirmed on Linux build 2000.02.24.08. -> Parser
Assignee: cbegle → rickg
Status: UNCONFIRMED → NEW
Component: Browser-General → Parser
Ever confirmed: true
QA Contact: asadotzler → janc
*** Bug 29126 has been marked as a duplicate of this bug. ***
One line of code (actually, just a missing *else*). Fix in hand, reviewed and ready to land.
Status: NEW → ASSIGNED
*** Bug 28799 has been marked as a duplicate of this bug. ***
This appears to be fixed as a side effect of fixing bug 28342.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Bug 28342 was fixed 4 days ago, but the page here still doesn't render. Have you done something else today?
This page, as well as that noted in duplicate bug 28342, display fine on Linux build 2000.02.26.08. Marking verified.
Status: RESOLVED → VERIFIED
Sorry to bring this to you, guys, but it's broken again in m14 (2000.02.29.16)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I can confirm this in M14 on WinNT as well. http://www.w3c.org/MarkUp/ seems to be a viable test case.
Marking works for me; Chris: can you try again with tomorrows build? These pages look great to me.
Assignee: rickg → petersen
Status: REOPENED → NEW
*** Bug 30142 has been marked as a duplicate of this bug. ***
These pages render correctly in the Win32 2000030208 build.
Rick fixed this, and it's still fixed on Linux build 2000.03.02.08. Marking so.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
In build 2000042208, XHTML pages are displayed with no HTML formatting. All tags and entities are ignored, leaving one continuous line of body text.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Gecko/2000052120 for Windows 98 doesn't render XHTML pages at all. If opened in a new window, it appears as a blank page; if opened in the same window, the previous page continues to be displayed (though the new URL appears in the address bar and you can view source the new page). I suggest adding the "4xp" keyword to this bug, since Netscape 4.x can display XHTML pages with <?xml ...?> headers.
I can confirm this. I used: Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000525 The problem is acually only with XHTML pages that have an XML declaration at the top. If the XML declartion is not there (using UTF-8) the pages display just fine. Try these pages: <http://www.concinnity.se/bertilow/html/signokodoj/latino1.htm> (In Latin 1 using XML declaration.) <http://www.concinnity.se/bertilow/html/signokodoj/unikodo.htm> (In UTF-8 - ASCII only actually...) The Latin 1 page is not displayed at all. The UTF-8 page displays fine. Both are valid XHTML 1.0 Strict.
Keywords: 4xp
Confirmed with Win95 build 2000060520. http://www.billlericaybaptistchurch.freeserve.co.uk/ renders (with table height problems caused by strict doctype) - xml declaration removed. http://www.billericaychoralsoc.freeserve.co.uk/ http://www.tranchant.freeserve.co.uk/ both retain xml declaration and do not render, although source is available for viewing. Commenting out the xml declaration in <!-- --> does not make any difference.
Confirmed bug on Linux with build 2000.06.13.11 <http://www.billericaychoralsoc.freeserve.co.uk/> <http://www.tranchant.freeserve.co.uk/> Neither render. The rendering area remains grey and doesn't repaint. I also confirmed on my own box that (malformed) XHTML pages will render if the XML 1.0 decleration is omitted.
The above pages seem to render well using latest cvs build on Windows 2000.
Yes, they display now, which is great, but at the same time a new error has appeared: XHTML pages _without_ an XML declaration should be treated as using UTF-8 (or UTF-16 if it is detected), but instead Latin 1 is being used. Info about UTF-8 in a META element is ignored.
*** Bug 47165 has been marked as a duplicate of this bug. ***
I just tested Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20000811, and all traces of this bug are gone. It seems to be fixed.
This is broken (again?) in the M17 release (build 2000080712, Win98 SE). Visit any of the XML pages at http://www.gotc.com/ - these are properly constructed, and worked fine under M15 (as well as IE 5.x). The problem, as nearly as I can discern, stems from the completion of the page load cycle; the page displays fine as it's loading, but as soon as the load is complete, everything on the page vanishes. Creepy. When visiting gotc.com with a Mozilla build, you will be automatically steered to the XHTML pages. For every XHTML document, however, there exists a correlating HTML document; just change the .xml extension to .html and go. (And don't let the dynamic content throw you; that's a feature.)
It was broken in M17, but is fixed in the recent builds of M18. Forget about M17.
Page looks fine the Aug 15th build for me (2000081504)
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Pages appears coorect in the Aug 15th builds.
Status: RESOLVED → VERIFIED
This bug is NOT fixed. It has become worse in the latest builds. I'm using build 2000091108 and if you take a look at bug 47165, you'll see I mentioned that spacing is handled very incorrectly on XHTML declared documents. The quick work-around I used previously, that is, adding an extra newline at the beginning of the document no longer works. You can see the terrible results at http://www.swva.net vs. how it looked in builds from last week, or NS/IE4+. I've added DHTML to the page since then, and apparently that is handled incorrectly too: the popups should position at the bottom-right, not top-left. This bug is not resolved, and possibly the priority should be upped.
I've figured out another workaround. The problem can still be viewed at http://www.swva.net/bad.html Instead of adding a blank line to "trick" Mozilla, I've added a comment <!--Mozbug--> which will still allow it to be validated properly by W3C and will display properly in Mozilla.
Bug 47165 looks like a separate issue to me. Rewriting Summary to clarify this one.
Summary: W3C XHTML standard pages not displayed → XHTML pages not displayed if <?xml...?> omitted
Summary: XHTML pages not displayed if <?xml...?> omitted → XHTML pages not displayed unless <?xml...?> omitted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: