Closed
Bug 59912
Opened 23 years ago
Closed 22 years ago
No JavaScript available (result of XSLT) ?
Categories
(Core :: XSLT, defect, P1)
Core
XSLT
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: robert, Assigned: sicking)
References
()
Details
Attachments
(3 files, 1 obsolete file)
274 bytes,
text/xml
|
Details | |
154 bytes,
text/xml
|
Details | |
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>
Comment 1•23 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9
Comment 3•23 years ago
|
||
Netscape.com work. Need to find the bug this one depends on.
Assignee: peter.vanderbeken → peterv
Comment 4•23 years ago
|
||
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
Assignee | ||
Comment 5•23 years ago
|
||
I think this depends on bug 21771 (as many other mozilla-xslt bugs do)
Depends on: 21771
Updated•23 years ago
|
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
Comment 9•23 years ago
|
||
Heikki: i don't know if this was fixed by 18843. I still need to try it out (tomorrow!)
Assignee | ||
Comment 10•23 years ago
|
||
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?
Comment 11•23 years ago
|
||
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?
Assignee | ||
Comment 12•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
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.
Reporter | ||
Comment 14•23 years ago
|
||
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.
Reporter | ||
Comment 15•23 years ago
|
||
Ok, so not fixed !
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → REMIND
Reporter | ||
Comment 16•23 years ago
|
||
Bye, and good luck with it !
Comment 17•23 years ago
|
||
Hmm, please don't close bugs that aren't fixed and are assigned to me. Thanks.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Updated•23 years ago
|
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,
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 19•23 years ago
|
||
I'm working on this, but I won't be ready for 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 20•23 years ago
|
||
Peter, do you know when this will be ready for? thanks -mike
Comment 22•23 years ago
|
||
The fix for this bug will be in bug 96647.
Comment 23•23 years ago
|
||
All these missed the bus/train/plane/boat/whatever. Sad.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 24•22 years ago
|
||
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) ?
Updated•22 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 25•22 years ago
|
||
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
Assignee | ||
Comment 26•22 years ago
|
||
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
Assignee | ||
Comment 27•22 years ago
|
||
Assignee | ||
Comment 28•22 years ago
|
||
Comment 29•22 years ago
|
||
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...
Assignee | ||
Comment 31•22 years ago
|
||
Assignee | ||
Comment 32•22 years ago
|
||
Assignee | ||
Comment 33•22 years ago
|
||
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?
Comment 34•22 years ago
|
||
Check what the content sinks do, and do the same in the XSLT code... (i.e. call SetDocument() before calling SetAttr()) :-)
Assignee | ||
Comment 35•22 years ago
|
||
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?
Comment 36•22 years ago
|
||
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.
Comment 37•22 years ago
|
||
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 38•22 years ago
|
||
Comment on attachment 66465 [details] [diff] [review] possible fix B, set mDocument before adding any attributes r=peterv.
Attachment #66465 -
Flags: review+
Assignee | ||
Updated•22 years ago
|
Attachment #66464 -
Attachment is obsolete: true
Comment 39•22 years ago
|
||
Comment on attachment 66465 [details] [diff] [review] possible fix B, set mDocument before adding any attributes sr=jst
Attachment #66465 -
Flags: superreview+
Comment 40•22 years ago
|
||
Comment on attachment 66465 [details] [diff] [review] possible fix B, set mDocument before adding any attributes sr=jst
Assignee | ||
Comment 41•22 years ago
|
||
fix checked in. If you still have any JS-problems please file separate bugs. Thanks for reviews!
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Comment 42•22 years ago
|
||
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.
Comment 43•22 years ago
|
||
we didn't verify for a long time. I really checked, so VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•