77257 - fail gracefully for deprecated namespace

Status: VERIFIED FIXED

(Core :: XSLT, enhancement)

Description

[Morten Nilsen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010323
BuildID:    2001032319

the xml document (which is outside my control) renders a nice faq using IE...
mozilla outputs a lot of text appearing to be parts of the source code.

Reproducible: Always
Steps to Reproduce:
1. open www.php.no
2. click :: FAQ ::
3. wait for it to load

Actual Results:  the garbled page is shown

Expected Results:  displayed a nice FAQ as seen using IE

Comment 1

[Boris Zbarsky [:bzbarsky]]

Are you using a build with XSLT enabled?

Comment 2

[Morten Nilsen]

XSLT? what is that?
my build is the 0.8.1 build as provided from www.mozilla.org

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The page in question uses an XSL stylesheet, and default Mozilla does not
support that. You can build XSLT component yourself or install it from the
Mozilla XSLT project page to try the page in question.

I am changing the summary, and sending this to XSLT component. Good test material.

Maybe not a real bug, but dupe, or whatever...

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Uh, to peterv.

Comment 5

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

dup of support-xslt-bug

*** This bug has been marked as a duplicate of 63906 ***

Comment 6

[Axel Hecht]

Changing the world once more.

The above page uses the deprecated namespace http://www.w3.org/TR/WD-xsl 
instead of the correct http://www.w3.org/1999/XSL/Transform.

We segfault on this one, I'll attach a patch in a minute.
(Can't remove 0 Node)

Should we add support for the deprecated namespace in
XSLTProcessor::getElementType ? (before changing this into evangelism).

There are GOOD arguments against it, IMHO, cause the old namespace is a sign
for deprecated, or MS specific XSLT.
Adding back heikki, and nisheeth, this is probably more a management issue. 

Axel

Comment 7

[Axel Hecht]

Attachment: adding 0 check to MozillaNode::removeChild

Comment 8

[Axel Hecht]

ugh, looked at the source once more.
<xsl:eval>uniqueID(this)</xsl:eval>
This is like street lights in Redmond.

Axel

Comment 9

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

Attachment: Fix nullhandling on a few more places

Comment 10

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

The attached patch fixes nullhandling in a few more places. It does so by 
forwarding any NULLs to mozilla.

snatching from peterv

Comment 11

[Axel Hecht]

r=me, thanx, sicking, for completing this.
As sicking, I'm not too sure if we should forward the nulls to mozilla, but 
as we gonna hit assertions there at a few times, it's probably a good thing to
do so. It might indicate an error, so use the thick rich mozilla fun.

Adding jst for sr (please? thanx).

Still no religious opinions on what to do on http://www.w3.org/TR/WD-xsl ?

Axel

Comment 12

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

I've come to the conclusion that I like forwarding the NULLs (as the patch does)
best. First of all this is wrappers so we really shouldn't implement any
functionallity in them. Second, in most cases there is defined behaviour for
NULL so always forwarding to mozilla should be the RightThing

Comment 13

[Johnny Stenback (:jst)]

sr=jst

Comment 14

[Axel Hecht]

I mark this fixed. Patch is checked in, so we shouldn't fail bad, but 
gracefully.

Axel

Comment 15

[Axel Hecht]

bitching buttons, verfication spam