Closed Bug 59912 Opened 24 years ago Closed 23 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: 23 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: 23 years ago → 23 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: