281022 - We need a better way of setting up the XSLT result document

Status: NEW

(Core :: XSLT, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

As things stand now XSLT regresses every now and then because some change is
made that assumes that documents are set up a certain way when they are
initially loaded.

Bug 182460 and bug 236596 is two that i know of off hand, but there has been
plenty of other ones. I'm also running into an unfiled one where we get plenty
of what seems like very serious warnings during drag'n'drop.

When this happens either noone notices, or it's noticed too late. And we end up
with a few releases with major XSLT bugs. And it's a lot of pain for us xslt
developers to track down old regressions in code we don't really know.

The only good fix for this is to make sure we use codepaths for setting up the
result xslt document that are excercided during more normal load. For example if
we tore down the DocumentViewer and set up a new one we might be able to use
existing functions rather then the current DocumentViewerImpl::SetDOMDocument
hack. Another option might be to reuse code that is used for multipart loads.

All suggestions welcome.