Closed Bug 453441 Opened 11 years ago Closed 11 years ago
Parsing an XSLT stylesheet with two xsl:version attributes fails
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/2008070208 Firefox/3.0.1 Error loading stylesheet: Parsing an XSLT stylesheet failed. XML file contains either <?xml-stylesheet type="text/xsl" href="styles/traffic_history.xsl" ?> or <?xml-stylesheet type="text/xsl" href="http://www.gemusicboosters.org/styles/traffic_history.xsl" ?> This is not a transformed file, just the XML file with a stylesheet applied. This is for http://, not for file://, which was reported in bug 397894. Reproducible: Always Steps to Reproduce: 1. visit link 2. error displays 3. Expected Results: Error loading stylesheet: Parsing an XSLT stylesheet failed. display a two-column table with dates and visitor counts
My guess is that this is bug 435078
Nope, not a dupe. Somehow the XSLT processor gets confused by the second xsl:version attribute.
Status: UNCONFIRMED → NEW
Component: General → XSLT
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → xslt
Hardware: PC → All
Version: 3.0 Branch → Trunk
Summary: Parsing an XSLT stylesheet fails in subfolder for http → Parsing an XSLT stylesheet with two xsl:version attributes fails
Ooh, i wonder if it's something in the forwards compatible parsing code that fails.
Still need an automated testcase.
Assignee: nobody → peterv
Status: NEW → ASSIGNED
I don't think this fix is correct since we'd no longer be requiring a version attribute on the root. Another way of fixing this would be to add a getStyleAttr call (with aRequired=false) to txFnStartLRE.
Since we already loop over attributes in txFnStartLRE I decided to just null the attribute's localName there.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Attachment #355813 - Flags: approval1.9.1?
Comment on attachment 355813 [details] [diff] [review] v2 Trivial spec compliance issue. Risk is very low with taking this patch I'd say.
Attachment #355813 - Flags: approval1.9.1? → approval1.9.1+
Looks good! My page does not work using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 (.NET CLR 3.5.30729) but is fixed as of: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090115 Minefield/3.2a1pre (.NET CLR 3.5.30729) Thanks!!
verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090415 Minefield/3.6a1pre ID:20090415030845 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090416 Shiretoko/3.5b4pre ID:20090416030924
You need to log in before you can comment on or make changes to this bug.