Unable to see content on this website (<script src="..." /> in XHTML served as text/html)




11 years ago
10 years ago


(Reporter: marcia, Unassigned)



Firefox Tracking Flags

(Not tracked)



Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2. Reported via reporter.mozilla.org.

1. Visit URL above.

Expected: See some content like I do in Safari
Actual: Only see blank page

This isn't Mac-only (I also see it with the 2007-12-13-05-trunk
Minefield nightly on Windows).

But it does seem to be trunk-only (I don't see it on the branch).

And it's not a new problem -- I see it with the 2007-08-05-04-trunk
Minefield nightly (on OS X).

I've no idea what could be the cause.
OS: Mac OS X → All
Hardware: PC → All

Comment 3

11 years ago
Looking at the page in DOMi I see all of the source after the script tag ends up inside the script.
<script type="text/javascript" src="/js/focus-432.js" defer="defer" />

I'd say Bug 305873.  So this could be a wontfix like Bug 393281.
Blocks: 305873

Comment 4

11 years ago
Wontfix per bug 327796 and bug 162653.  It's blank in IE too, right?
Last Resolved: 11 years ago
Resolution: --- → WONTFIX

Comment 5

11 years ago
The site works in IE7 on XP.  But the source sent is different:
<script type="text/javascript" src="/js/focus-432.js" defer="defer"> </script>

And the site works in the latest minefield nightly when using the IE6 UAstring.  
This is something that used to work, so tech evangelism might be more appropriate.

Comment 7

11 years ago
Sounds like they misinterpreted the "You can send XHTML to Firefox but not to IE" memo.

Comment 8

10 years ago
Mostly wrong.  According to the W3C validator, <script ... /> tags are legal and treated as closed.

It would be nice to see this parsed properly.  <script> .... is not the same as <script />.....

Comment 9

10 years ago
Just note:  This is NOT the same issue as Bug 305873.

That bug dealt with unclosed script tags.  This bug deals with self-closing script tags which should be seen by the browser as being closed.

It is too bad that content which passes the W3C validator is seen as wrong by the FF team.  So much for standards-compliance :-(

Comment 10

10 years ago
1. The shorthand form <script /> is not valid HTML. 
2. Script is not an empty element so the shorthand form is not even valid in XHTML. 

The validator isn't perfect.  

Comment 11

10 years ago
I have added notes to another bug with a full XHTML document which passes validation and still fails to render on FF3.

The tag in question is:

<script type="text/javascript" language="JavaScript" src="UI/login.js" />

I would expect a <script /> tag with a src attribute to be empty.  Perhaps you can point me to the entry on the DTD which shows that this is not the case?

At any rate it is a shame that we can't rely on the W3C validator to ensure that code works on FF3 :-(  I suppose it is time to write a more public complaint....

Comment 12

10 years ago
Search http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Transitional for "EMPTY".  But I think it's bizarre and un-XML-like of the XHTML spec to allow <script></script> and not <script/> -- my impression was that XML considers the two to be exactly equivalent.  http://mail.python.org/pipermail/python-list/2005-March/312768.html agrees and points out that the section in question is informative, not normative.

Given crowder's recent change to the summary of bug 327796, this is now a dup of bug 327796 (which is also WONTFIX, for the same reasons).


10 years ago
Summary: Unable to see content on this website → Unable to see content on this website (<script src="..." /> in XHTML served as text/html)

Comment 13

10 years ago
Yes, it is a shame if the W3C validator treats your code as XHTML despite a text/html mime type.  It should warn you about that being invalid and/or point out things like self-closing SCRIPT tags where serving as text/html will cause compatibility issues.
You need to log in before you can comment on or make changes to this bug.