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




19 years ago
18 years ago


(Reporter: graf, Assigned: chrispetersen)




Firefox Tracking Flags

(Not tracked)




(1 attachment)



19 years ago
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.

Comment 1

19 years ago
Confirmed on Linux build 2000.02.24.08.  -> Parser
Assignee: cbegle → rickg
Component: Browser-General → Parser
Ever confirmed: true
QA Contact: asadotzler → janc

Comment 2

19 years ago
*** Bug 29126 has been marked as a duplicate of this bug. ***

Comment 3

19 years ago
One line of code (actually, just a missing *else*). Fix in hand, reviewed and 
ready to land.

Comment 4

19 years ago
*** Bug 28799 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
This appears to be fixed as a side effect of fixing bug 28342.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 6

19 years ago
Bug 28342 was fixed 4 days ago, but the page here still doesn't render.  Have
you done something else today?

Comment 7

19 years ago
This page, as well as that noted in duplicate bug 28342, display fine on Linux
build 2000.02.26.08.  Marking verified.

Comment 8

19 years ago
Sorry to bring this to you, guys, but it's broken again in m14 (2000.02.29.16)
Resolution: FIXED → ---

Comment 9

19 years ago
I can confirm this in M14 on WinNT as well. http://www.w3c.org/MarkUp/ seems to 
be a viable test case.

Comment 10

19 years ago
Marking works for me; Chris: can you try again with tomorrows build? These pages 
look great to me.
Assignee: rickg → petersen
*** Bug 30142 has been marked as a duplicate of this bug. ***

Comment 12

19 years ago
These pages render correctly in the Win32 2000030208 build.

Comment 13

19 years ago
Rick fixed this, and it's still fixed on Linux build 2000.03.02.08.  Marking so.
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 14

19 years ago
In build 2000042208, XHTML pages are displayed with no HTML formatting. All 
tags and entities are ignored, leaving one continuous line of body text.
Resolution: FIXED → ---

Comment 15

19 years ago
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.

Comment 16

19 years ago
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:

  (In Latin 1 using XML declaration.)

  (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.


19 years ago
Keywords: 4xp

Comment 17

19 years ago
Confirmed with Win95 build 2000060520.

renders (with table height problems caused by strict doctype) - xml declaration 

both retain xml declaration and do not render, although source is available for 
viewing. Commenting out the xml declaration in <!-- --> does not make any 

Comment 18

19 years ago
Confirmed bug on Linux with build 2000.06.13.11

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.

Comment 19

19 years ago
Created attachment 10508 [details]
m16/build200022820 crashes too
The above pages seem to render well using latest cvs build on Windows 2000.

Comment 21

19 years ago
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.

Comment 22

19 years ago
*** Bug 47165 has been marked as a duplicate of this bug. ***

Comment 23

18 years ago
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.

Comment 24

18 years ago
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.)

Comment 25

18 years ago
It was broken in M17, but is fixed in the recent builds of M18.
Forget about M17.

Comment 26

18 years ago
Page looks fine the Aug 15th build for me (2000081504)
Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 27

18 years ago
Pages appears coorect in the Aug 15th builds.

Comment 28

18 years ago
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.

Comment 29

18 years ago
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.

Comment 30

18 years ago
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


18 years ago
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.