Closed Bug 59912 Opened 25 years ago Closed 24 years ago

No JavaScript available (result of XSLT) ?

Categories

(Core :: XSLT, defect, P1)

Product:
Core
Component:
XSLT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: robert, Assigned: sicking)

References

(
URL
)

Details

Attachments

(3 files, 1 obsolete file)

testcase stylesheet
274 bytes, text/xml
Details
one-click xml testcase
154 bytes, text/xml
Details
possible fix B, set mDocument before adding any attributes
784 bytes, patch
peterv
: review+
jst
: superreview+
Details | Diff | Splinter Review
In the final release of the Microsoft XSLT-Parser 3.0 this sample works fine. I was so lucky to get the same result in your browser, but script functions failed with a 'no defined'-error. Is this an error or there are special restrictions to embed script in XSLT-files ? - I did not found informations and samples about this case. This is the last chance, because all newsgroups are very bad in past, present and future ?! -------------------------------------------------------------------------- <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="html" /> <xsl:attribute-set name="employer"> <xsl:attribute name="align">left</xsl:attribute> <xsl:attribute name="valign">center</xsl:attribute> <xsl:attribute name="color">#000000</xsl:attribute> <xsl:attribute name="bgcolor">#f5f5f5</xsl:attribute> <xsl:attribute name="nowrap"></xsl:attribute> <xsl:attribute name="style"> font-family: verdana, arial, helvetica, sans-serif; font-size: 10pt; border: solid #6699CC 1px; padding: 1px; height: 16px; margin: 0; </xsl:attribute> </xsl:attribute-set> <xsl:attribute-set name="control"> <xsl:attribute name="src">../../images/dot_plus.gif</xsl:attribute> <xsl:attribute name="border">0</xsl:attribute> <xsl:attribute name="align">left</xsl:attribute> <xsl:attribute name="width">17px</xsl:attribute> <xsl:attribute name="height">17px</xsl:attribute> <xsl:attribute name="style"> float: left; </xsl:attribute> </xsl:attribute-set> <xsl:template match="/"> <html> <head> <title>Profile</title> <script type="text/javascript"> <![CDATA[ function OnExpand() { alert( "To expand content here..." ); } ]]> </script> </head> <body> <table border="0" bgcolor="#f5f5f5" rules="all" cellpadding="0" cellspacing="0" style="border: solid #6699CC 1px;"> <xsl:apply-templates select="profile" /> </table> </body> </html> </xsl:template> <xsl:template match="profile"> <xsl:for-each select="employer"> <tr> <xsl:element name="td" use-attribute-sets="employer"> <a href="JavaScript:OnExpand()"> <xsl:element name="img" use-attribute-sets="control" /></a> <xsl:value-of select="Location" /> </xsl:element> <xsl:element name="td" use-attribute-sets="employer"> <xsl:value-of select="Description" /> </xsl:element> <xsl:element name="td" use-attribute-sets="employer"> <xsl:value-of select="OrgDate" /> </xsl:element> <xsl:element name="td" use-attribute-sets="employer"> <xsl:value-of select="EndDate" /> </xsl:element> </tr> </xsl:for-each> </xsl:template> </xsl:stylesheet>
Bug confirmed. We need to add some fu for <html:script> tags in nsXMLContentSink::Observe. NS6 won't have this, is there a keyword for issues that will make NS6 behaviour incompatible with mozilla? Axel
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Mozilla module issue, so taking over.
Assignee: kvisco → peter.vanderbeken
Target Milestone: --- → mozilla0.9
Netscape.com work. Need to find the bug this one depends on.
Assignee: peter.vanderbeken → peterv
This one doesn't depend on any bugs, it's just that the contentsinks hook up the script tags to script functionality, and our result doc never went thru the content sink. We need to walk the result tree and probably reproduce the code of nsXMLContentSink::ProcessStartSCRIPTTag and friends. Axel
I think this depends on bug 21771 (as many other mozilla-xslt bugs do)
Depends on: 21771
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1
Removed bogus dependency to content sink refactoring. But isn't this a dupe of bug 18843 and/or bug 26790? They are marked future, but I believe vidur is working on bug 18843 based on his status report.
No longer depends on: 21771
So is this a dupe? Vidur landed the script changes, does this now work?
Keywords: qawanted
PDT moving to 0.9.2. So dupe of bug 18843?
Whiteboard: dupe of 18843?
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Heikki: i don't know if this was fixed by 18843. I still need to try it out (tomorrow!)
Fixing bug 18843 did not fix this :( The reason for this is that when we encounter <script> function foo() { ... } </script> in the stylesheet we first add a <script> element to the result tree and *then* add a "function foo..." textnode to that element (the same for a src attribute). However mozilla processes the <script> element when it is added to the tree and then never again. And even if mozilla would parse any added textnodes we still wouldn't be able to handle the following stylesheet: <script> function foo() { <xsl:if test="@doalert"> alert("transformiix"); </xsl:if> } </script> The RightThing to do would be to tell mozilla right before the transform to not handle any added script elements, then after the transform step through the result tree and process any script elements. An alternative way to fix this is to have transformiix process and children and attributes of a <script> element and then add the <script> to the result tree. This would have to be done for any element that adds scripts to a page (can <link> do that?).
Whiteboard: dupe of 18843?
I've created a 'sample' default XSLT for xml documents. Originally the javascript was embedded which does not work as this bug states. When I put the javascript in an external file it does not seem to work either. Am I correct?
Yes, the problem arises then too. As I said in the previous comment the problem is that we first add the <script> element and then, after it is added to the tree, sets it's 'src' attribute. But mozilla only reacts when the <script> element is added to the tree, and not on subsequent changes. I actually crash when trying to add <script src="..."> to the resulting document.
my workaround for this is to use an element with style="display:none;", and use that as a container for the script (which must not contain any & or <>, because they will not be recognized in their entity form (bug?)), and get the nodeValue of the textnode in the element i abused as script tag. this can then be evaled (as onload event, preferably), and in effect acts justs like a normal script tag, ie. you can declare functions etc., no problem. but you may need to explicitly create them in the window object, to make them availiable in the same scope as a script tag in the head and to keep some references to your objects to prevent garbage collection. at least this was the way i did it last time, with several kb js code. anyway, this bug needs a fix.
This bug can not be resolved with 'fixed', because it's not acceptable to solve this simple problem with unique and tricky handling. I think, Mozilla/Netscape will be incompatible with W3C like in past. It's better to use the mutch more faster Microsoft XML-Parser on the Server and don't use any XML-Parser in the Browser.
Ok, so not fixed !
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → REMIND
Bye, and good luck with it !
Hmm, please don't close bugs that aren't fixed and are assigned to me. Thanks.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Status: REOPENED → ASSIGNED
Priority: P3 → P1
Peter, while you are working on this, could you add a null check to nsScriptLoader... While testing some stuff I noticed we need one in nsScriptLoader::ProcessScriptElement() for globalObject: mDocument->GetDocumentLoadGroup(getter_AddRefs(loadGroup)); nsCOMPtr<nsIDocShell> docshell; ! globalObject->GetDocShell(getter_AddRefs(docshell)); nsCOMPtr<nsIInterfaceRequestor> prompter(do_QueryInterface(docshell)); rv = NS_NewStreamLoader(getter_AddRefs(loader), scriptURI, this,
Target Milestone: mozilla0.9.2 → mozilla0.9.3
No longer blocks: 63906
I'm working on this, but I won't be ready for 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Peter, do you know when this will be ready for? thanks -mike
No longer blocks: 96647
Depends on: 96647
Moving out :(.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
The fix for this bug will be in bug 96647.
All these missed the bus/train/plane/boat/whatever. Sad.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The patch for 96647 is nearly done, but it's a bit big and we need time for reviews, unless something serious comes up this should land early in 0.9.7.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Summary: No JavaScript available ? → No JavaScript available (result of XSLT) ?
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Patch for bug 96647 should be final, so these will be fixed early in 0.9.9 (really!).
Target Milestone: mozilla0.9.8 → mozilla0.9.9
This bug has been mostly fixed by the outputrewrite landing. <script>-type scripts work excellent. However onclick="..."-type scripts still needs some specialhandling it seems. Testcase coming up
Over to sicking who has a fix for the event handler stuff.
Assignee: peterv → sicking
Status: ASSIGNED → NEW
This is weird - the testcase works in NS 6.2.1...
The problem is this: We set the attributes on the element before adding it to the tree (for perf-reasons). So ::SetAttr is unable to get hold of a context, there's no mDocument and no global js-context. Fix A adds code to ::SetAttr that grabs the document through the nodeinfo. I'm also a bit worried that we're just plugging one hole, and that more things like this will pop up over time. Heikki is also a bit worried that we might grab the wrong document. Fix B calls SetDocument on the element before adding any attributes. Peterv is a bit worried that that this put the element in a dangerous state, since normally mDocument should be null if an element is not in the tree. I'm not really sure that people will be able to get hold of a reference to the element though, what lists could the element end up in (.links, .getElementById, etc) could the element end up in when we call SetDocument on it? Heikki also pointed out that maybe it shouldn't really be a problem doing things the way we do now, since when the element is added to the tree (and SetDocument is called) there migth be code that should look for all onFoo attributes and take proper action. Is that the case? Should we try to track down why that don't happen instead? Or in addition to one or both of the above patches?
Check what the content sinks do, and do the same in the XSLT code... (i.e. call SetDocument() before calling SetAttr()) :-)
the contentsink calls SetDocument, adds the attributes and then adds the element to the tree. Which is what i want us to do too (i.e. act as much as the contentsink as possible). There is one problem though. We don't get all attributes at once, so there is a timespan between when we've called SetDocument and when we add the element to the tree. So there is a risk that someone will get a reference to the element during that time. So there are two questions: can someone get a reference through the document to that element, and what badness could happen if someone did?
If you don't add the element to the tree, it won't be accessable to anyone outside the XSLT code, so that shouldn't be a problem, unless there are problems with that internally to XSLT.
I wrote a testcase it is working fine for event. but it is not reconzing the extranal javascript files. Ex XML File : <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="test.xsl"?> <test> <login> <login_name>Durga</login_name> </login> </test> JS File function test1() { alert("Test") } and XSL file <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:html="http://www.w3.org/1999/xhtml"> <xsl:template match="/"> <html> <head> <LINK REL = "stylesheet" id="style_link" TYPE = "text/css" HREF = "styles.css"/> <script type="text/javascript" src="test.js"></script> </head> <body> My name : <xsl:value-of select="//login/login_name" /><br/> <A href="#" id="go1" class="bluebold" onclick="test1()">Check click</A> </body> </html> </xsl:template> </xsl:stylesheet> When i click on the hyper link it is giving test1 is not defined
Comment on attachment 66465 [details] [diff] [review] possible fix B, set mDocument before adding any attributes r=peterv.
Attachment #66465 - Flags: review+
Attachment #66464 - Attachment is obsolete: true
Comment on attachment 66465 [details] [diff] [review] possible fix B, set mDocument before adding any attributes sr=jst
Attachment #66465 - Flags: superreview+
Comment on attachment 66465 [details] [diff] [review] possible fix B, set mDocument before adding any attributes sr=jst
fix checked in. If you still have any JS-problems please file separate bugs. Thanks for reviews!
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
removed the item for this bug from the release notes for 0.9.9 and beyond, because the bug is fixed now. Let me know if you think the item should be re-added.
we didn't verify for a long time. I really checked, so VERIFIED.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: