Closed Bug 40982 Opened 24 years ago Closed 24 years ago

Out-of-band xml loading crashes Mozilla if doc not found

Categories

(Core :: XML, defect, P1)

x86
Windows 95
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: mozilla, Assigned: nisheeth_mozilla)

References

Details

(Keywords: crash, Whiteboard: [nsbeta3+])

Attachments

(2 files)

Behaviour:
Out-of-band XML loading crashes mozilla if the external document is not found.

Expected behaviour:
Not crashing ;-)

Tested on:
W95 2000052508
Severity: enhancement → critical
Keywords: crash
Summary: [FEATURE] Out-of-band xml loading crashes Mozilla if doc not found → Out-of-band xml loading crashes Mozilla if doc not found
This doesn't like an enhancement/feature to me.

reporter: please attach a testcase or URL where the problem occurs.  At the very 
least, some more details would be helpful.
Testcase:

Notice that test2.xml is loaded to crash the browser. If test2.xml is changed to 
test.xml everything works.

Dependency on bug http://bugzilla.mozilla.org/show_bug.cgi?id=39330? Could be if 
something strange happens internally with the mime-type (it is provided in the 
.load method, but maybe ignored if the file is not found or something like that) 
but I'm not sure

The reason I put [FEATURE] in there is because Nisheeth asked this in the 
n.p.m.xml newsgroup (news://news.mozilla.org/390D2B8A.6B6932D7%40netscape.com)



-- 
test.html: 

<html> 
<head> 
<script> 
<!-- 
  function documentLoaded(e) { 
    s = xmlDoc.getElementsByTagName("test")[0].firstChild.data; 
    alert(s); 
  } 

  var xmlDoc = document.implementation.createDocument("", "", null); 
  xmlDoc.addEventListener("load", documentLoaded, false); 
  xmlDoc.load("test2.xml", "text/xml"); 
//--> 
</script> 
</head> 
<body> 
This is a test. 
</body> 
</html> 

test.xml: 

<?xml version="1.0"?> 
<test>This is content in an XML document.</test> 
Cannot verify because of bug #40552. Adding dependency.
(2000-06-01-08 on Linux)
Depends on: 40552
setting to new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is not going to make it into beta 2 because 
there is a workaround to this crash -- make sure that the document you are 
pointing to exists.

Marking nsbeta3 and setting target milestone M18...
Status: NEW → ASSIGNED
Keywords: nsbeta3
Target Milestone: --- → M18
nsbeta3+ to stop the crash.
Whiteboard: [nsbeta3+]
Marking P1
Priority: P3 → P1
QA Contact: chrisd → petersen
I cannot reproduce the crash with a recent nightly build (24 aug.).

Notes:
-the "onload" handler of the "to-be-loaded" document will still fire.(Is this
correct?).
-trying to attach an "onerror" handler seems not to work.(Query Bugzilla for my
name to see some bugs/RFEs related to XML parsing error reporting.
-The platform I'm using is WinNT, SP6a

Ronald, can you still reproduce the crash using Win95? If yes, could you attach
your sample file, so other platforms can easily test it?
Nisheeth, if you're only going to allow "text/xml" for load(), why not just
remove the parameter?
Cannot reproduce on Linux using a 25 aug nightly build.
Thanks a lot for testing this bug out, Taras.  The mime type parameter in the 
Load method() has been removed for some time now.  Vidur removed it when he was 
working on the XML extras component.

Am trying to reproduce this using today's debug build...
I couldn't reproduce this either.  Marking worksforme.  Taras, the reason the 
onerror event listener doesn't get called is because errors in document loads do 
not generate error events.  That is a bug that I do not have the cycles to fix 
right now.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Verified works for me with the Sept 5th build.
Status: RESOLVED → VERIFIED
I can crash trunk build 2000-10-27-04 on Win2k, by creating an empty document
and then calling either getElementsByTagName or getElementsByTagNameNS on it.
This also happens if you use XMLHttpRequest to load an non-existent file and
then call either method on the XMLHttpRequest::responseXML.

The crash is hard.  No message, no nothing, Mozilla just goes away.

Work around is to a) check that you have a non-empty document before calling the
getElementByTagName methods, b) check the status of the XMLHttpRequest before
trying to get any Elements from the Document.

I think this should be reopened since it *does* crash even if it is marked Future.

Attaching the following example:

var doc = document.implementation.createDocument(null, '', null);
var parseErrorList = doc.getElementsByTagName('parsererror');
Tested with debug build pulled from 10/31/00 AM sources on win2k.  The attached
test case did *not* crash.  I believe that the fix that went in for bug 40121
may have fixed this crash as well.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: