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)
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
Reporter | ||
Comment 1•21 years ago
|
||
Reporter | ||
Comment 2•21 years ago
|
||
Reporter | ||
Comment 3•21 years ago
|
||
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.
Reporter | ||
Comment 5•21 years ago
|
||
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.
Reporter | ||
Comment 7•21 years ago
|
||
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.
Description
•