296919 - Firefox doesn't understand empty SCRIPT element

Status: VERIFIED INVALID

(Firefox :: General, defect)

Description

[Victor Engmark]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

After making my XHTML 1.0 Strict work in "standards compliance mode" according
to Firefox, it doesn't load JavaScript in "script" elements formatted as follows:
<script type="text/javascript" src="forms/scripts/nifty.js" />
Changing this to the following works:
<script type="text/javascript" src="forms/scripts/nifty.js" ></script>

There are two problems with this:
- The former format is valid XHTML 1.0 Strict, and should pose no problems for
Firefox
- Attempting to output the end tag in XSLT doesn't work, as it is (correctly)
truncated by Xalan

Reproducible: Always

Steps to Reproduce:
1. Generate a valid XHTML page with empty "script" elements referencing
JavaScript files
2. View the page
3. Observe the (lack of) JavaScript functionality
Actual Results:  
Nothing showing that any JavaScript had been loaded. The JavaScript Console
doesn't show any error either...

Expected Results:  
All JavaScript should be activated, and transformed the page accordingly

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Do you have a link or a testcase you could provide that shows the problem?

Comment 2

[Victor Engmark]

Attachment: Working file - with end tags

Comment 3

[Victor Engmark]

Attachment: Non-working file - empty elements

Comment 4

[Victor Engmark]

Attachment: Additional files needed to test the bug

Comment 5

[Bastiaan Jacques]

Could you please elaborate exactly what each testcase is supposed to do? 

Additionally, it would be particularly helpful if you could reduce the testcase
to *just* the HTML/js that causes the problem, and get rid of the HTML which is
otherwise not interesting to the developers.

Comment 6

[Victor Engmark]

To test this, download the "Additional files" and either of the XHTML files.

When using the "Working file", you should see that the header and footer have
round edges, and that the list in the "Usage" section can be expanded when
clicking the plus (+) signs next to any line.

When using the "Non-working file", the header will be rectangular, and the list
in the "Usage" section will only show the lowest level of list elements.

Comment 7

[Martijn Wargers (dead)]

You are absolutely sure, that you don't encounter bug 151506?

Comment 8

[William Bumgarner [:zsinj]]

I think it is bug 151506, as mentioned in comment 7.
In my opinion, reporter, refer to bug 151506, comment 5.

<- DUPE 151506

*** This bug has been marked as a duplicate of 151506 ***

Comment 9

[Bastiaan Jacques]

(In reply to comment #8)
> I think it is bug 151506, as mentioned in comment 7.


If I understood the mentioned bug correctly, when application/xhtml+xml is used,
the <script /> tag should work. However, as you can see in the attachment table,
the content type of the testcases _is_ application/xhtml+xml. However, the
problem still exists in those files, and this is, from my perspective, not
accounted for in said bug.

Comment 10

[Victor Engmark]

Attachment: Working file - with end tags

Added content-type meta element

Comment 11

[Victor Engmark]

Attachment: Non-working file - empty elements

Added content-type meta element

Comment 12

[Victor Engmark]

Reopened
- Tomcat 5.0.28 is cofigured to serve *.xhtml as application/xhtml+xml (the URL
is http://localhost/chiba/XFormsServlet?form=/forms/slots.xhtml)
- The meta content-type is set to "application/xhtml+xml; charset=ISO-8859-1"
- The XHTML validates at http://validator.w3.org/

However, FF /still/ reports the file as being of type "text/html". Maybe this is
the core of the problem?

Comment 13

[Martijn Wargers (dead)]

What does page info say on that page? (Right click Mouse -> View Page Info)
If it says, Type: text/html then it is text/html and then it is logical you see
this problem. If it is application/xhtml+xml, then there is something odd with
Mozilla.
Setting meta content-type to application/xhtml+xml will not work, afaik (and
should not afaik).

Comment 14

[Victor Engmark]

The info page shows that the type is "text/html". Can anyone point to a resource
for serving JSP results as application/xhtml+xml on Tomcat?

Comment 15

[Jamie]

This problem is observed when working with Wikiwyg.

I have observed this problem in both FireFox (User agent: Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4) and Mozilla
(User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041217).

The page declares itself as XHTML Strict and validates as such.

The file in question can be found at <http://pastebin.ca/14276>.

Comment 16

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 17

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 18

[William Bumgarner [:zsinj]]

When reopening an expired bug, please state why you are doing so. Download a
nightly build (1.6 Alpha) from http://developer.mozilla.org and use that version
to verify whether or not the bug still exists.

Comment 19

[William Bumgarner [:zsinj]]

Correction to URL: 1.6 Alpha is available at http://www.mozilla.org/developer/

Comment 20

[Phil Ringnalda (:philor)]

Since saving attachment 185555 [details] as XFormsServlet.xhtml and loading it as a local
file works perfectly, the only possible remaining Mozilla bug would be if your
localhost server is sending a correct Content-type: application/xhtml+xml
header, and we misinterpret it. Please capture a HTTP log
(http://www.mozilla.org/projects/netlib/http/http-debugging.html) of opening the
non-working page, and attach it.

Comment 21

[Victor Engmark]

(In reply to comment #20)
> Since saving attachment 185555 [details] [edit] as XFormsServlet.xhtml and loading it as
a local
> file works perfectly [snip]

Please read the initial description. The issue is that the Javascript files are
not read, even if the file is valid XHTML, if I use the shortcut "/>" syntax to
end the script tag. I have verified this in FF 1.0.4, 1.0.7, and the current
nightly build.

Comment 22

[Phil Ringnalda (:philor)]

No, I do understand the issue. However, if Firefox believes that your files were
served as application/xhtml+xml (which it does, if it loads a local file named
.xhtml), then it works: the <script .../> files are loaded and interpreted, the
plusses toggle the list items. That is how it is supposed to work: whether or
not you have "valid XHTML" either it is served as application/xhtml+xml or you
cannot use empty tag syntax for things that are not empty tags in HTML,
including <script>.

In comment 12 you said that you had Tomcat configured to serve
application/xhtml+xml, but Firefox was still reporting that it was seeing it as
text/html. That's the remaining possible bug: are you sending headers which
should be interpreted as meaning application/xhtml+xml, that Firefox
misinterprets, or not? The rest of my comment was just verifying that if you do
convince Firefox that you are sending application/xhtml+xml, then it will
interpret it the way you expect.

Comment 23

[Victor Engmark]

(In reply to comment #22)
> No, I do understand the issue. However, if Firefox believes that your files were
> served as application/xhtml+xml (which it does, if it loads a local file named
> .xhtml), then it works: the <script .../> files are loaded and interpreted, the
> plusses toggle the list items. That is how it is supposed to work: whether or
> not you have "valid XHTML" either it is served as application/xhtml+xml or you
> cannot use empty tag syntax for things that are not empty tags in HTML,
> including <script>.

[old comment]I must be doing something really weird, because the files are not
loaded here (v1.0.7). The file extension is xhtml, the page info page lists the
type as application/xhtml+xml, and http://validator.w3.org/ validates the file
as XHTML 1.0 Strict. Could there be some issue when loading JavaScript
locally?[/old comment]

Aha! The path to the first JS file is generated by 3rd party software, and that
was pointing to a non-existing directory. Some observations:
- If script elements use the shortcut syntax, only the first one is highlighted
- If a valid XHTML 1.0 Strict file is loaded from a web server with a script
element pointing to a non-existing JS file, the rest of the files are still
loaded (served correctly as application/xhtml+xml)
- If a valid XHTML 1.0 Strict file is loaded from a local directory with a
script element pointing to a non-existing JS file, /none of the consecutive
files are loaded/
  - I tried moving the faulty element last, and then the others were loaded

Summing up, there seems to be a difference in how invalid paths to JS file
references are handled when XHTML is loaded from a web server or locally. Dang.

Comment 24

[Phil Ringnalda (:philor)]

I can't reproduce having a broken script path cause later scripts to not load, but that's miles away from where this bug started anyway: if you have a reproducible way of triggering it, please file a new bug in some Core component, probably Networking: File, with a minimized testcase attached (just the absolute minimum needed to trigger the bug).