87975 - HTML w/ JS vs XHTML w/ JS - buttons do not work

Status: VERIFIED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Ulrich Drepper]

I was trying to convert some HTML files into XHTML and stumbled across some
problems with Javascript.  I've looked a bit through the Bugzilla database and
couldn't find a problem.  This is filed against Javascript but perhaps it's
something else.  Maybe even a problem on my side.

I'll append two files: one HTML file, the other XHTML.  They should be
equivalent and are indeed rendered more or less the same.  But pressing the
buttons (which invokes a Javascript routine) doesn't work.  I know the routines
are parsed  since deliberately adding syntax errors make them show up in the
Javascript console.

This is with today's (2001-6-26's) CVS version but I've seen this for longer.

Comment 1

[Ulrich Drepper]

Attachment: HTML version which works OK

Comment 2

[Ulrich Drepper]

Attachment: XHTML version which doesn't work

Comment 3

[Phil Schwartau]

Confirming bug with Mozilla binary 20010621xx WinNT. OS : Linux --> All.
The <SCRIPT> block in the XHTML testcase looks like this:


<script language="JavaScript1.2">
<![CDATA[

function doHide(hide)
{
  var p = document.getElementById("ll");
  if (hide) {
    p.setAttribute("class", "hide");
  } else {
    p.removeAttribute("class");
  }
}

]]>
</script>



If I save the XHTML testcase locally and load it in Mozilla, I see this
error in the JavaScript Console: 


                    Error: syntax error
                    Source File: (local path)/87975_40247.xhtml
                    Line: 15
                    Source Code: <![CDATA[



For some reason, I do not see this error when I load the testcase off 
the Bugzilla server. Nevertheless, this must be the key to the problem -

Comment 4

[Phil Schwartau]

I would like to reassign this to the DOM component for further analysis.
Is this perhaps a Parser issue? Is there something in JS Engine that needs
to be done in order for "<![CDATA[" to be accepted?  I have never seen 
this before - 

Comment 5

[Ulrich Drepper]

I also tried it without the <![CDATA[ stuff with the same effect. So the
<![CDATA problem is not the only one (unless the missing <![CDATA[ makes the
script unusable by the JavaScript engine).

Comment 6

[Phil Schwartau]

You have to erase both the 

<![CDATA[

and the

]]>


At least, when I do that the testcase runs fine in Mozilla - 
does that work for you, too? 

Comment 7

[Ulrich Drepper]

I know that ]]> has to be removed as well (I'm using and writing software for
SGML for about 10 years now, so I do know the syntax and semantics of all this :-).

And no, this doesn't solve the problem.  In fact, this is what I tried first. 
I've added the CDATA stuff only afterwards to make things "easier" to digest for
the XML parser.

Comment 8

[Phil Schwartau]

Attachment: XHTML version with CDATA open/close removed

Comment 9

[Phil Schwartau]

Using Mozilla binaries 20010621xx WinNT, 20010615xx Linux, 20010615xx Mac.

On all three platforms, the XHTML testcase fails when it includes the 
CDATA open/close, and succeeds when the CDATA open/close is removed.

Will try with newer builds when I get a chance - 

Ulrich - if this doesn't work for you, do you see any errors in 
the JavaScript Console? 

Comment 10

[Ulrich Drepper]

OK, I see the problem now.

Your modified text works for me, too.  But: if I convert it into Unix-style
(i.e., convert CRNL into NL) it doesn't work anymore.  It seems the parser
assumes the
braindamaged DOS-style text format.

Comment 11

[Ulrich Drepper]

Oh, and I forgot, this still leaves the question unanswered why the <![CDATA[
stuff cannot be used.  Look, for instance, in the file

  content/xml/tests/script.xml

in the mozilla source tree.  It uses the same syntax.

Comment 12

[Ulrich Drepper]

Attachment: XHTML version without CDATA and in Unix format

Comment 13

[Ulrich Drepper]

More news.

The problem actually is that if a file loaded with the suffix .xml or .xhtml it
won't work but it does work if it is a suffix which is not known.  Similarly
things to work if the content type is not text/xml.  This is why the third
attachment works, but not the one I appended.

To reproduce it, first look at the third attachment above directly.  it should
work just fine.  Then download the file and save it as t.xml.  Load it using
file:///..../t.xml.  It shouldn't work.  Rename the file to t.xml-t and load
file;///..../t.xml-t and it should work.

For somebody who knows the difference the content type information makes in the
parsers should get an idea now.

I'm changing the component to XML since this is most probably a parser issue.

Comment 14

[Phil Schwartau]

Setting default owner and QA for chosen component - XML

Comment 15

[Ulrich Drepper]

And it's getting stranger.  Well, at least for me.

I'll append another example where additionally SVG is used (you'll need a
browser with SVG enabled at build time).

If the file loaded with .xml suffix or text/xml content type everything is
rendered correctly.  Including the SVG part.  But the buttons won't work.  If
the file is loaded with a different suffix (.xml-u in my case) or a content type
!= text/xml the buttons do work but the SVG is *not* rendered at all.

I think this qualifies this problem as critical since there is no way to work
around the bug and get everything working.  I'm appending the test case now.

Comment 16

[Ulrich Drepper]

Attachment: Extended wxample with SVG

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

CDATA section should have no effect, we should (at least we used to) treat it
correctly. Likewise, newline format should be irrelevant, and obviously things
should also work with XML mime type.

I am pretty sure this is a regression. If someone could go the trouble and try
pinpoint when this happened it'd be great. vidur and maybe somebody else landed
some changed to make scripts work dynamically, so maybe that caused a regression...

Comment 18

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Doh, found out a document whose root element is script does not work in XML.
I'll fix that at the same time.

Comment 19

[Ulrich Drepper]

Just to be sure there is no confusion, the newline format is no problem.  It's
just that I've stored the file without the CR under a name no content type could
be derived from.  The problems are CDATA and the XML content type handling.

Comment 20

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I suspect this is a duplicate of bug 47319.

This is not an XML problem per se, I think. I put dump() statements in the JS:
one to output something when the JS was loaded and one when doHide was called.
The first one produced output when the document was loaded, but the second one
was never called. Works the same way with or without a CDATA section.

Thus, it seems that the button click message gets lost somewhere, and we do not
call the JS function that is in the onclick attribute.

Sending to Event Handling.

Comment 21

[Ulrich Drepper]

Well, maybe the button handling is for the Event Handling component.

But what is about the SVG output not being visible?  I definitely think there is
something wrong with the content type handling.

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SVG will only work if the mime type is an XML type - which makes sense since SVG
is an XML language. Same with MathML, XLink, XHTML (don't confuse this with HTML
here) etc.

I am working on the script-as-root in another bug.

Comment 23

[Alex Vincent [:WeirdAl]]

This is a very probable duplicate of bug #27403, which covers CDATA sections in
scripts for XHTML documents served as text/html.

Comment 24

[Alex Vincent [:WeirdAl]]

Maybe not.  I looked at my JavaScript console and got two different error
messages for the two testcases.  Sorry for the spam.

Comment 25

[Kelson]

XHTML, being a subset of XML, is case-sensitive, and all HTML tags and
attributes have to be in lower case.  This includes events such as onClick.  I
took the second attachment, "XHTML version which doesn't work," fixed the
capitalization to make it "onclick" instead of "onClick" and it works.

Comment 26

[Kelson]

Attachment: XHTML document with capitalization fixed

Comment 27

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think kelson is right. Therefore this bug is INVALID, marking as such.

Comment 28

[Madhur Bhatia]

As per developers comments, marking verified invalid