42627 - documents with an XML declaration don't load

Status: RESOLVED WORKSFORME

(Core :: XML, defect, P3)

Description

[Richard Lanyon]

It appears that all XHTML documents which start with an XML declaration:
<?xml version="1.0"?>
fail to load. The URL given above is an example of this problem. The error given
in the controlling terminal is:
Entry at index 0 is http://www.jitter.co.uk/moonkat/ie5/about.html
Document: Done (0.501 secs)
*** check number of frames in content area
Error loading URL http://www.jitter.co.uk/moonkat/ie5/about.html

A related document can be found at http:
//www.jitter.co.uk/moonkat/ie5/news.html. This has a different declaration:
<?xml version="1.0" encoding="iso-8859-1"?>
and doesn't give an error in the terminal window, but still fails to load.

Comment 1

[Andreas Franke (gone)]

Richard, which build ID are you using? You can find it in the lower right corner
of the browser window. Does the problem go away if you set the environment
variable "ENABLE_STRICT" to "1" before running mozilla? 
I can reproduce the "Error loading URL ..." messages with M16, but newer builds
like 2000061420-M17 say "... loaded successfully" and display these pages.
Please add the build ID to all future bug reports.

Comment 2

[Richard Lanyon]

The build ID was 2000061311 - it's the M16 for Linux binary drop released just
recently. And yes, it does go away if I set ENABLE_STRICT to 1. I hope this info
is of some use! Sorry for not including the build id before.

Comment 3

[Richard Lanyon]

Setting ENABLE_STRICT to 1 does have some other undesirable effects on XHTML
page rendering, however (build id 2000061311, as before). In particular, the
failure to display unordered lists as lists
(http://www.jitter.co.uk/moonkat/ie5/about.html) and the failure to center a
table despite text-align being set to center in an external stylesheet
(http://www.jitter.co.uk/moonkat/ie5/buttonz.html - compare with
nearly-identical but non-XML
http://www.jitter.co.uk/moonkat/ie5/front-buttonz.html which does become
centred). All the XHTML mentioned here validates against XHTML Strict, so it's
not the author's (viz me) fault.

Comment 4

[Asa Dotzler [:asa]]

RIchard, this seems to work with more recent builds.  Can you test with 061611 
ore more recent builds and reopen if the bug is still there.  Thanks.