Closed Bug 68824 Opened 24 years ago Closed 19 years ago

XMLParser::getDocumentFromURI returns empty documents for missing pages

Categories

(Core :: XSLT, defect, P5)

Product:
Core
Component:
XSLT
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta5

People

(Reporter: sicking, Assigned: peterv)

References

Details

(Keywords: fixed1.8)

Attachments

(2 files, 5 obsolete files)

better oneclick testcase
402 bytes, text/xml
Details
v1
1.21 KB, patch
axel
: review+
bzbarsky
: superreview+
asa
: approval1.8b5+
Details | Diff | Splinter Review
The mozmodule implementation of XMLParser::getDocumentFromURI returns an empty document when given an url to a missing page. It should return NULL. This is needed for the document() xslt function which should return an empty nodeset if the document is missing.
The following happens: nsSyncLoader::LoadDocument creates an empty document and tries to load from the given URL. However if the load fails nsSyncLoader is never notified. Neither ::Error or ::Abort is called. Then once the load is finished (and unsuccessful) the empty document is returned.
Target Milestone: --- → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla1.1
Depends on: 73936
It should be fairly easy to workaround this by checking if doc.documentElement returns NULL right before the doc is returned from the syncloader.
Sicking: I think my patch in 73936 fixes this, so no need for the workaround?
Priority: -- → P5
I think this is fixed now. Sicking, could you verify?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
sorry, I seem to get empty documents for failed http loads... testcase coming up
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is partly fixed with the output rewrite. It works fine for http-loaded documents (except that moz locks up for a while), but file-loaded documents are really doing some wierd things. Doing document('file:///fud.xml') returns a document which contains a <html><body></body></html> tree.
Attached file 68824.xml (obsolete) —
Attachment #44770 - Attachment is obsolete: true
Attachment #44771 - Attachment is obsolete: true
save the two attachments above to a local directory
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
This is still a problem?
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
Attached file oneclick testcase (obsolete) —
Attachment #66692 - Attachment is obsolete: true
Attachment #66693 - Attachment is obsolete: true
this works on windows both from file:// and from http://. It'd be great if we could get tested on more platforms. Just download the testcase, save it as anything, and open in browser.
I get a "not loaded" from http: and a "loaded" from file: Peter, you have some experience now, any idea? Maybe we don't propagate the Open rv good enough. (couldn't triage 1.4, so unsetting milestone, this is neither 1.4a nor b)
Target Milestone: mozilla1.4alpha → ---
WFM for both file:// and http:// on OS X.
obviously this is either random or just the other way around as I reported it. Note that neither nsParser::OnStopRequest nor nsForceXMLListener::OnStopRequest handle http status messages. One of them probably should, maybe even both. As nsParser is prolly defined to return its about:blank empty doc, should nsForceXMLListener be the one? No idea how to pass this thru the woods, though.
Blocks: 226425
Attached patch v1 — — Splinter Review
Let's do this for now, might try to get this on the branch too. The real fix is probably in the syncloader, but since that has more consumers it'll take more time.
Attachment #194329 - Flags: review?(axel)
Attachment #194329 - Flags: review?(axel) → review+
Attachment #194329 - Flags: superreview?(bzbarsky)
Attachment #194329 - Flags: superreview?(bzbarsky) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 19 years ago
Resolution: --- → FIXED
Comment on attachment 194329 [details] [diff] [review] v1 This makes us detect 404 pages etc and avoids treating them as XSLT stylesheets, which could lead to hangs/crashes (as seen in bug 226425).
Attachment #194329 - Flags: approval1.8b5?
Attachment #194329 - Flags: approval1.8b5? → approval1.8b5+
Keywords: fixed1.8
Target Milestone: --- → mozilla1.8beta5
Depends on: 334179
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: