Closed Bug 227835 Opened 21 years ago Closed 21 years ago

Crash using XSLT with only non-root XPath for template match to general HTML

Categories

(Core :: XSLT, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 213013

People

(Reporter: grahamf, Assigned: peterv)

Details

Attachments

(2 files)

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031205 Mozilla crashes when using only a non-root Xpath for a template match to generate HTML. It does not matter if a matching node exists in the XML: it seems that it is crashing before generation. I will attach the modified test XML and XSLT files from previous bugs. Reproducible: Always Steps to Reproduce: 1. Save the attached form.xml and style.xsl files locally; 2. Start Mozilla 3. Open the form.xml file Actual Results: Crashes. Expected Results: Should render HTML if a node matches, or a blank page if no matches. This did not occur using Mozilla 1.0. Stack trace (via VC++ debugger): nsDebugImpl::Assertion(nsDebugImpl * const 0x002a7ab0, const char * 0x03c7dfe8, const char * 0x03c7dfd4, const char * 0x03c7df74, int 505) line 276 nsDebug::Assertion(const char * 0x03c7dfe8, const char * 0x03c7dfd4, const char * 0x03c7df74, int 505) line 109 txMozillaXMLOutput::closePrevious(char 3) line 505 + 39 bytes txMozillaXMLOutput::endDocument() line 202 txUnknownHandler::endDocument() line 75 txExecutionState::end() line 224 txMozillaXSLTProcessor::DoTransform() line 380 txMozillaXSLTProcessor::setStylesheet(txStylesheet * 0x02c90340) line 671 + 8 bytes txCompileObserver::onDoneCompiling(txStylesheetCompiler * 0x00a29310, unsigned int 0, const unsigned short * 0x00000000, const unsigned short * 0x00000000) line 487 txStylesheetCompiler::maybeDoneCompiling() line 535 txStylesheetCompiler::doneLoading() line 414 txStylesheetSink::DidBuildModel(txStylesheetSink * const 0x02fad428) line 243 nsExpatDriver::DidBuildModel(nsExpatDriver * const 0x02ff8d40, unsigned int 0, int 1, nsIParser * 0x02d5ae08, nsIContentSink * 0x02fad428) line 1034 + 12 bytes nsParser::DidBuildModel(unsigned int 0) line 1244 + 46 bytes nsParser::ResumeParse(int 1, int 1, int 1) line 1819 nsParser::OnStopRequest(nsParser * const 0x02d5ae0c, nsIRequest * 0x02d5ad60, nsISupports * 0x02d5ae08, unsigned int 0) line 2471 + 21 bytes txStylesheetSink::OnStopRequest(txStylesheetSink * const 0x02fad430, nsIRequest * 0x02d5ad60, nsISupports * 0x02d5ae08, unsigned int 0) line 364 + 47 bytes nsFileChannel::OnStopRequest(nsFileChannel * const 0x02d5ad68, nsIRequest * 0x02d4e5e0, nsISupports * 0x00000000, unsigned int 0) line 578 nsInputStreamPump::OnStateStop() line 499 nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x02d4e5e4, nsIAsyncInputStream * 0x027ed7c4) line 339 + 11 bytes nsInputStreamReadyEvent::EventHandler(PLEvent * 0x02d4c8e4) line 117 PL_HandleEvent(PLEvent * 0x02d4c8e4) line 671 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a351d8) line 606 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00bf12a0, unsigned int 50028, unsigned int 0, long 10703320) line 1412 + 9 bytes
Uh, stupid me. It actually ASSERTs (I have a debug build). Ignoring the assert shows the following text: Error loading stylesheet: Parsing an XSLT stylesheet failed. Terribly sorry about the confusion.
Attachment #137051 - Attachment mime type: text/html → text/xml
The assert is known and arguably bogus (we assert applying the default template to whitespace textnodes which tries to insert whitespace in root of document). I don't understand how you could get a parse-error though, if you get a parse-error we won't even run the stylesheet, which we're clearly doing in your stacktrace.
You are absolutely right. I made the assumption that the assertion was reporting my problem. It turns out that if I ignore the assert I get the later parse error. I will need to track that down, as Mozilla 1.0 was quite happy. As for the examples, please ignore. Can this bug be put on ice until I either figure it out as my problem with the XSL or otherwise" Also, has anything been tightened up with the transformiix that would puke on previously working XSL? Sorry and thanks. Graham
Yes, paring-rules have been tightened up. In particular we now require the 'version' attribute on the <xsl:stylesheet>-element which we didn't before.
Uh, yup, me bad. This is a duplicate of #213013 involving the xml:space="preserve" option. I will update that bug with some other stuff I noted. Sorry for the false alarm - you would think I would have learnt to dig more deeply after all these years. Cheers, Graham *** This bug has been marked as a duplicate of 213013 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: