379120 - [FIX]XSLTProcessor appears to perform validation in alpha 4

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Matthew Wilson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a4) Gecko/20070427 GranParadiso/3.0a4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a4) Gecko/20070427 GranParadiso/3.0a4

The wmlbrowser extension (wmlbrowser.mozdev.org) installs a component which uses nsIXSLTProcessor to transform WML to HTML before displaying.

This behaviour stopped working sometime between 3.0a3 and 3.0a4. I now get NS_ERROR_FAILURE from nsIXSLTProcessor.transformToDocument.

I haven't yet tracked down the reasons for all the problems, but one of them is resolved by changing

  <div onload="">

to

  <div>

(Yes, I know <div onload=""> is useless...)

"onload" is not a valid attribute on a "div" element in XHTML 1.0 Transitional (which is what the XSLT outputs), however this never used to be a problem.

Has there been validation added between the releases?

Reproducible: Always

Steps to Reproduce:
1. Set extensions.checkCompatibility to false.
2. Install wmlbrowser 0.7.15 from wmlbrowser.mozdev.org.
3. Load a test page such as http://wmlbrowser.mozdev.org/tests/basic/single-card.wml.
Actual Results:  
The extension shows "wmlbrowser couldn't interpret this page". (Extra logging shows that this is due to a failure from transformToDocument, and that removal of onload from div fixes the error, at least for this test case.)

Expected Results:  
I expected the page to render as it did in 3.0a3.

I don't have a simple test case for this at the moment.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Matthew, could you perform a binary search through the builds at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ to find a smaller regression range than "between a3 and a4"?

Even if you don't have a minimized testcase, uploading any document that shows the error to the bug would be good. Documents on the web tend to sometimes disappear before someone can look into fixing the bug.

Comment 2

[Matthew Wilson]

Attachment: Test case (HTML with Javascript); succeeds in 3.0a3, fails in 3.0a4

Comment 3

[Matthew Wilson]

Attachment: Corrected attachment (sorry)

Comment 4

[Matthew Wilson]

The testcase breaks between 2007-03-28-04 and 2007-03-29-04.

Comment 5

[Martijn Wargers (dead)]

Matthew, thanks for the testcase and regression range!
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-28+04&maxdate=2007-03-29+04&cvsroot=%2Fcvsroot
Based on that, I would think this is a regression from bug 349467.

Comment 6

[Nickolay_Ponomarev]

Yes, the debugger indicates the error code comes from
nsEventListenerManager::AddScriptEventListener and context is null.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So either XSLT needs to ignore the retval from SetAttr, or we need to change AddScriptEventListener to just return early (not throw) when there is no script context.  Probably the latter.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 9

[Boris Zbarsky [:bzbarsky]]

Matthew, thank you for the excellent testcase and for narrowing down the regression range!

Comment 10

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

Note to reviewer, check if this is same as bug 374334 (sorry, it's late here)

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Note to reviewer, check if this is same as bug 374334 

It's not quite, no.  At least not given my "proposed fix" -- that just fixes the case of a missing script global, whereas the situation in bug 374334 has a script global.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Checked in.