Closed Bug 106162 Opened 23 years ago Closed 23 years ago

javascript code processed as plain text

Categories

(Tech Evangelism Graveyard :: Portuguese, defect)

Product:
Tech Evangelism Graveyard
Component:
Portuguese
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: thomashansen, Assigned: roger)

References

(
URL
)

Details

Attachments

(5 files)

Testcase: unclosed HTML comment tag in strict mode makes JavaScript to appear in clear text
1.47 KB, text/html
Details
Testcase [ showing a bug in strict comment parsing as well ]
289 bytes, text/html
Details
Proposed Fix...
2.73 KB, patch
Details | Diff | Splinter Review
Testcase showing incorrect "view source" with above patch.
201 bytes, text/html
Details
A test case html with various options of -- and >
337 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 BuildID: 2001101202 When running the javascript funcion COMVCGetCookie() from this page, everything from "if (nId_>0)" to the next "</script>" is interpreted as plain text. This never happened on 0.9.4 version of mozilla (I've tested it). The same error occurs on the Windows version of mozilla. Reproducible: Always Steps to Reproduce: 1.Open site www.uol.com.br 2. 3. Actual Results: Javascript is interpreted parcially as plain text. Expected Results: Execute the javascript code, instead of showing it to me!
Confirming 2001102203 on Win2k. No dupes found. Marking NEW. -> Parser, but punt as needed
Assignee: rogerl → harishd
Status: UNCONFIRMED → NEW
Component: Javascript Engine → Parser
Ever confirmed: true
QA Contact: pschwartau → moied
Summary: javascript code processed as plain text - bug new to 0.9.5 (0.9.4 works fine) → javascript code processed as plain text
OS: Linux → All
Hardware: PC → All
JavaScript don't show if you remove the DOCTYPE. I guess the JavaScript code is treated differently in quirks mode than it is in strict mode with DOCTYPE: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Transitional//EN">
JavaScript will show with this testcase if you don't remove the DOCTYPE. In strict mode (i.e. with the DOCTYPE set), comments which aren't closed are very harmful. This is the case with the testcase, reduced from the URL above. Webmaster obviously forgot to close one HTML comment, leaving <!-- unclosed. Then, somehow, Mozilla respects the brackets very closely and will show some JavaScript code because of opening and closing brackets. (I'm too tired to see exactly what happens). However, if someone confirms, this should be moved to Tech Evangelism.
Yup, -> Tech Evangelism.
Severity: major → normal
Component: Parser → The Americas
Product: Browser → Tech Evangelism
Version: other → unspecified
--> Evangelism
Assignee: harishd → momoi
QA Contact: moied → jonrubin
*** Bug 109300 has been marked as a duplicate of this bug. ***
Assuming its the same, this problem is particularly visible at http://www.nme.com. Click on 'more' in the news panel to be brought to the main news page, where the script appears across the top half of the page. Is this a result of the same bug, or should I post a new one, perhaps sending it to Evangelism. I can'find any dupes. Nme.com is a particularly popular site in the UK & Ireland,so this bug would be particularly obvious to a large number of users. I'm using build 2001111903 on Win2K
In the attached testcase we have: <!-- ONE TAG NOT CLOSED HERE !!!!!!!!!!!!! #<!--CHKS=00009831--> I think it is closed by the last '-->'... Shouldn't everything in the middle of '<!--' and '-->' be treated as comment? The view source window highlights this way... Is it a highlighting bug?
From http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4 : -- White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments. -- Ok, so '--' ends the comment, but it is inside a tag and in HTML invalid tags or tag attributes are ignored, aren't they? Is it a valid point: <!-- blablabla -- bla bla bla> == <!-- blablabla --> <a href="#" bla bla bla> == <a href="#"> ?
bug id 113111 is a duplicate
*** Bug 113111 has been marked as a duplicate of this bug. ***
*** Bug 116126 has been marked as a duplicate of this bug. ***
With the latest Mozilla build(Dec 22), www.uol.com.br is throwing ASSERTION FAILURE errors in layout/html/base/src/nsFrameManager.cpp though I can reproduce the bug after ignoring these errors.
*** Bug 117513 has been marked as a duplicate of this bug. ***
The problem could be in the DOCTYPE sniffing code. dbaron: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Transitional//EN"> should trigger quirks layout. no? It does in N6.2 but not on the tip.
Well, there's no such thing as 3.2 Transitional, but if it's used on real sites we could add it...
Just to inform, the UOL website is the number 1 in the brazilian ranking of domains, acording to Ibope/eRatings, it had 4,35 milions of unique visitors in February(2002), wich represents 65,9% of the brazilian audience, you can check it in this url: http://www.bluebus.com.br/noticias/busca.php3?st=shw&key=ibope&data_i=2002-03-20&n_i=1&data=2002-03-11&n=21 Note that yahoo.com.br is the 4th with 39,0% and microsoft.com is 7th with 27,6%
Attached patch Proposed Fix... — — Splinter Review
I considered various possibilities for comments including the followings: o <!-- ABCD -- XYZ --> o <!--ABCD -- -- XYZ --> o <!-- ABCD -- GHJK --DFGH --> As per the HTML specifications, it states 1) there can be no white space between the starting '<!' and '--' but there can be white space(s) between the end of the comment i.e. '--' and mark up delimiter '>'. 2) A comment starts with a '--' and ends with the next occurrence of '--'. I modified the code to handle malformed HTML with the assumption that if between a sequence of '--' (other than the starting one) and '>' we find any character other than white space then that particular sequence of '--' is not the actual end of the comment, and we should look for the next occurence of '--'. If we find it ('--'), we should repeat the process till we encounter the delimiter '>'. Once we reach till '>', we should just ignore the content between the last '--' and this '>'. Now even if it is something other than the white space, it will be ignored. e.g. in the first case we assume that comment is actually being ended at the last sequence of '--', as the one appearing prior to that is having non white space characters before it reaches '>'. This actually violates the fact that the "comment starts with a '--' and ends with the next occurence of '--' " but to handle the incorrect HTML, just thought of this assumption. However, in such situations one of the two specifications is going to be violated. With this patch content tree seems to be fine on viewing it with "viewer.exe->dump content" but view source is not showing the comment content as per the above assumption. Any pointer for that part ? Is that a different bug? Next I'm attaching the testcase where I do not see the correct view source.
Well, I don't know if it helps, but I have made a html with some -- and > that could be part of a script, hope it works with the purposed patch :)
In XML (and XHTML) comments start with '<!--' and end with '-->'. '<!-- -- -->' or '--->' are not allowed solely for compatibility with SGML: http://www.w3.org/TR/REC-xml#sec-comments I don't know much about SGML so I can't tell the implications to breaking with the standard here. But in a XML/DOM perspective, it now makes a lot of sense to me to consider '--' invalid within a comment. Comments aren't elements, they are nodes, so you just can't have invalid attributes after the closing statement and I am ok with the browser not rendering it correctly in a *strict* mode. Now, what about the doctype triggering quirks mode... is there a reason an invalid doctype shouldn't trigger quirks mode? After all, it works fine on quirks mode and netscape 6.2...
Mass re-assigning .br bugs to marcio.
Assignee: momoi → mgalli
Just to update this bug... I'm using build 2002040503 win2k, www.uol.com.br is rendering fine and also the mne news from comment #8.
They removed the '--' inside comments in the page, but from times to times another '-->' inside a comment is appearing causing the columns to render in the wrong position.
Re assigning to Roger@livesidebar.com - Roger is now (as of yesterday) more involved with the Evangelism Effort. UOL was his first contacted site and it's fixed. He sent the original message yesterday and they fixed by this morning! :) Thanks Roger!! happy news!. I will be updatinng all other bugs and I am reassigning to you so you can close and mark FIXED! See the nice, it's DOCTYPE now.. 4.x Transitional without URL! Since UOL asked for the full-nice diagnose, some additional Teacher Style Document will be sent for UOL developers from Roger.
Assignee: mgalli → roger
*** Bug 125678 has been marked as a duplicate of this bug. ***
Great Roger! Now I have one more vote to cast with other things =) Lets keep the brazilian evangelism, maybe we can do something related with bug 100309 in São Paulo...
*** Bug 131592 has been marked as a duplicate of this bug. ***
*** Bug 136450 has been marked as a duplicate of this bug. ***
*** Bug 133738 has been marked as a duplicate of this bug. ***
We contacted UOL and they updated the DOCTYPE, it is now triggering quirks mode and the page is rendering fine. Thanks to UOL for the quick fix!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
tech evang june 2003 reorg
Component: The Americas → Portuguese
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: