• Roadmap
• Projects
• Coding
  • Module Owners
  • Hacking
  • Get the Source
  • Build It
• Testing
  • Releases
  • Nightly Builds
  • Report A Problem
• Tools
  • Bugzilla
  • Tinderbox
  • Bonsai
  • LXR
• FAQs

Reporting bugs on XSLT in Mozilla

by Axel Hecht

A few common evangelism issues:

Mimetypes

Your server needs to send both the source and the stylesheet with a XML mime type, text/xml or application/xml. To find out the current type, load the file in Mozilla and look at the page info. Or use a download tool, those usually tell the mime type.

XSLT Namespace

The XSLT1.0 namespace is http://www.w3.org/1999/XSL/Transform. Older IEs had a namespace with WD in it, which is uncompatible with XSLT1.0 and therefor unsupported.

Prerequisites

Use a current build.

We are, like all Mozilla modules, not making as much progress as we'd love, but we do change stuff. If you feel like you have encountered a bug in our XSLT implementation, try a current build. Or check for resolved bugs, too.

Search already filed bugs.

XSLT is a pretty small component within Mozilla and our buglist is reasonably small. Just take a minute or two and look thru the existing bugs. If your build is somewhat dated (Netscape builds, stable Mozilla releases or maybe just a milestone), please look for dupes in the RESOLVED and VERIFIED bugs as well.

It's a boy, err, bug *

There are basically four types of bugs in XSLT:

Crashers and hangs:

File those as they are, debuggers will show us the way. Unless you file bugs like "10k works, 20 doesn't". That's most likely an out of memory crash (we still have some of those) and we need you to produce the stacktrace. (You need to build a debug build for that.) Out of memory is system dependent.

XPath expressions don't work:

File 'em, this should be a trivial testcase though (see below).

XSLT output is wrong:

In general you want to create a testcase focusing on reproducing what doesn't work in your application. It might be easier to create a new testcase then stripping down your application.

Creating testcases

Keep in mind, XSLT is complex, and so is finding out what's wrong. As we can only guess what you expect to see, we need you to do most the work on the testcase. Here are a few rules of thumb.

1. Keep the size of the testcase to a minimum. If you double the size of your testcase, it will take at least 4 times the amount of work to understand what your stylesheet does.
2. Make clear what you expect your testcase to do.
3. Use separate files only if they are required to reproduce the bug. Import precedence would be an example. Please spare us the time to look into several stylesheets to find the offending code. Is an image in your testcase really the item that the bug is about? Stuff like this are alot easier for you to track and reduce than for us.
4. Attach the XSLT stylesheet first, and use the bugzilla URL as href in the PI in the XML source. Set the mimetypes of the both attachements to text/xml. You have to do that by hand, bugzilla doesn't provide a drop down item (known bug). If your testcase needs a CSS stylesheet, you'll probably need to attach that before.
5. "But it works in IE". IE has a different understanding of XSLT than Mozilla. IE serializes your output and parses it again, so it suffices that stuff *looks* fairly well to work. Mozilla takes the tree as generated as result. BIG DIFFERENCE, trust us.
6. Related to the above, if you have other means of generating your output, run it thru a validator like validator.w3.org. If your output doesn't validate as HTML 4, we have no way to fix it.

Now what's a good testcase? See Attachment 43502 in bug 88745. It links directly to Attachement 43501, so we get one stop shopping here. And it's small. The xml contains just the necessary two testcase, one matching, one not, and the stylesheet contains only the relevant test. It gives prompt feedback as to wether the bug is resolved or not.

---