[Webkit-unassigned] [Bug 24418] transformToFragment() method from XSLTProcessor objects returning null when processing XML data read from on-disk files

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 6 08:55:00 PST 2009


------- Comment #3 from jmpp at macports.org  2009-03-06 08:55 PDT -------
(In reply to comment #2)
> This is caused by a mistake in stylesheet.xsl. For the first output element,
> the stylesheet attempts to add an id attribute after adding a child, which is
> forbidden by XSLT spec, see <http://www.w3.org/TR/xslt#creating-attributes>:
> -----------
> The following are all errors:
> - Adding an attribute to an element after children have been added to it;
> implementations may either signal the error or ignore the attribute.
> ...
> -----------

Thanks for pointing me to this, I made the corrections to the stylesheet and
everything is working fine now, mystery solved! I apologize for the loud noise,
I was very confused with this "problem" as no analysis led me to any logical
conclusion. I did look for help in #Webkit @ freenode to review the XML and
XSLT in case there was anything at fault in them that I was missing, but I was
requested to instead come here and open a bug.

When I said the XSLT in this testcase and that used at the dykasa.com server
(the sample used in 'fragment_working.js') had the same structure, I was
referring to their <xsl:output> elements, as the review in bug #10419 led me to
believe that's where I should focus my efforts. They were nevertheless
different, as the latter doesn't incur on the error I was making here.

> Firefox silently ignores the error, but libxslt does not.

That didn't help one bit in finding the error ;)

> Please note that the XSLT transformation error is printed to Mac OS X console.


3/6/09 12:07:24 PM [0x0-0x29029].org.webkit.nightly.WebKit[423] runtime error:
file http://jmpp.org/ttf_testcase/stylesheet.xsl line 9 element attribute
3/6/09 12:07:24 PM [0x0-0x29029].org.webkit.nightly.WebKit[423] xsl:attribute :
node already has children

> We certainly should make it so that errors are printed to Web Inspector console
> in the future for easier debugging.

Please! That would definitely be of great help, and I guess many would say
they'd expect these types of errors to be shown right on the browser, which is
where we are working after all; it never occurred to me to look in the Console
until you mentioned it. Firebug prints these errors to its console too (though
in an extremely cryptic manner, sadly), further supporting this move.

But I'm not complaining, I understand the nature of open source and I don't
have a patch handy ;) Thanks for all the help!


Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list