Closed Bug 279878 Opened 21 years ago Closed 21 years ago

Unknown extension function shouldn't stop processing unless called

Categories

(Core :: XSLT, defect, P3)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: julian.reschke, Assigned: peterv)

References

()

Details

Attachments

(2 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 1) This is the default content type for files served by Apache 2 with extension "xslt". So if this is an incorrect type, an issue for Apache2/httpd should be opened 2) IE accepts this content type Reproducible: Always Steps to Reproduce: Actual Results: The message displayed is "Error loading stylesheet: (null)" Expected Results: Either the XSLT should be processed, or, at a minimum, Mozilla should display a meaningful error message.
You should always test with a nightly, this bug is already fixed. However, we signal an unknown function but I think we shouldn't. Sicking: I see an error for myns:parseXml, even though there's an xsl:if with function-available just before the call (<xsl:if test="... and function-available('myns:parseXml')">). I don't think that should error and it looks like fall-out from your fcp fix.
In particular I think the fcp() call in http://lxr.mozilla.org/seamonkey/source/extensions/transformiix/source/xpath/ExprParser.cpp#578 is wrong (see 14.2). We probably need a new error code though, we need to differentiate between functions with or without a prefix, the latter need the fcp check but the former don't.
Severity: major → normal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Summary: XSLT transformation fails when Content-Type for XSLT is application/xslt+xml → Unknown extension function shouldn't stop processing unless called
Target Milestone: --- → mozilla1.8beta
Attached patch v1 (diff -w) (obsolete) — — Splinter Review
Here's one way to fix it. Have to think it through wrt to XForms etc.
Yeah, you're right. I was staring myself blind on the fcp section of the spec. We should take this part into account too: http://www.w3.org/TR/xslt#section-Extension-Functions
Attached patch v1.1 — — Splinter Review
Attachment #172442 - Attachment is obsolete: true
Attached patch v1.1 (diff -w) — — Splinter Review
Attachment #172459 - Flags: review?(bugmail)
Comment on attachment 172459 [details] [diff] [review] v1.1 (diff -w) >Index: extensions/transformiix/source/xslt/txStylesheetCompiler.h >+ /** >+ * Should the expression be parsed in forwards compatible parsing mode. >+ */ "Should the stylesheet..." r=me
Attachment #172459 - Flags: review?(bugmail) → review+
Attachment #172459 - Flags: superreview?(jst)
Comment on attachment 172459 [details] [diff] [review] v1.1 (diff -w) sr=jst
Attachment #172459 - Flags: superreview?(jst) → superreview+
don't forget to remove the fcp function in the xforms context when you land this.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: