Closed Bug 91769 Opened 23 years ago Closed 15 years ago

scriptsearch.com - Mozilla doesn't display content within tables on some pages on Scriptsearch.com

Categories

(Tech Evangelism Graveyard :: English US, defect, P2)

x86
Windows NT

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: phil, Unassigned)

References

()

Details

(Keywords: testcase, Whiteboard: [aok], has been contacted)

Attachments

(1 file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010720 BuildID: 2001072003 While perusing the listings at Scriptsearch.com, I noticed that when you try to view the details of a listing, the content in the middle of the page is not displayed at all in Mozilla (see the above URL). This content is displayed in other browsers such as Netscape 4.x and IE 5.x. I looked at the source code for this page, and I noticed that the content that doesn't display in Mozilla is contained within the <td> area of one of a series of nested tables. I didn't look at the code long enough to determine if there are HTML coding areas, but in any event, even if there are, Mozilla should still be able to display this page, since Netscape 4 and IE 5 are able to do so. I have noticed this behavior on a few other web sites as well, although I don't recall which ones right now. Reproducible: Always Steps to Reproduce: 1. Go to http://www.scriptsearch.com/details/1094.html and view the page. Actual Results: Content in the middle of the page is not displayed in Mozilla. Expected Results: Content in the middle of the page should have been displayed, as it is in other browsers such as Netscape 4.x and IE 5.x.
Attached file Testcase (deleted) —
The missing content is caused by the following comment markup: <!-- ----> Removing the DOCTYPE fixes it. Reassigning to Parser.
Assignee: karnaze → harishd
Component: HTMLTables → Parser
Keywords: testcase
QA Contact: amar → bsharma
This is not a parser error. We are doing what we should be doing. The doctype enables standards mode. <!-- foo ----> is not a legal comment per w3c spec. The open comment is legal but the following: ----> does not close it. see http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4 for explanation. This bug then is either invalid or evangelism. Since it targets a specific site, I am sending over to EVANGELISM.
Assignee: harishd → bclary
Status: UNCONFIRMED → NEW
Component: Parser → Evangelism
Ever confirmed: true
QA Contact: bsharma → zach
You can call this bug "invalid" if you like, but that doesn't change the fact that these pages won't appear for Mozilla users, most of whom will not say "gee, this page isn't displaying because it's using non-W3C-standard HTML, so I'll just do without looking at these pages." Instead, they will simply assume that Mozilla "doesn't work" and then switch to another browser such as IE that *does* display these pages, however "broken" or "invalid" the HTML may be. I strongly would urge that this is not just "evangelism", but a bug/issue/problem in Mozilla (or at least a backwards compatibility issue) that needs to be fixed so that the pages are displayed.
I took a look at the W3C article mentioned by Christopher Aillon, and it states the following: ------------------------------------------- 3.2.4 Comments HTML comments have the following syntax: <!-- this is a comment --> <!-- and so is this one, which occupies more than one line --> 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. Information that appears between comments has no special meaning (e.g., character references are not interpreted as such). Note that comments are markup. -------------------------------------------- The comment in the HTML code for the page in question (http://www.scriptsearch.com/details/1094.html) is listed below: <!--------------------------- --------------------> While I would certainly agree that this is questionable HTML, my reading of the W3C article above does not lead me to believe that it would be appropriate for the browser to disregard all HTML after this comment, since the comment does have an opening (<!--) and a closing (-->) in line with the article above, and it fits into the example given in the article of a comment that is all contained on one line. While it's certainly questionable in that it doesn't contain any text in between the opening and closing of the comment, and it uses too many dashes (---), I see nothing in the W3C article that would lend support for the argument that Mozilla should throw out all HTML that comes after this line. As I mentioned in my previous message above, there are a number of other reasons as well why Mozilla should not do this. I should also note that I mean no disrespect by my comments, which are intended solely to make Mozilla a better browser that more people will want to use. Fixing this bug (and it *is* a bug IMHO) would aid in that effort.
Phil, I'm not arguing with you on the ambiguity of the HTML spec, and there currently is some discussion on how Mozilla should handle these comments (see bug 52931 - "Space between '--' and '>' breaks comments"). Anyway, because you have isolated a single site and technically their comments are invalid because of the way the HTML spec is written, I have marked this for evangelising, not a bug in the parser (see bug 91441, bug 84743, bug 65049 to name a few). This is because right now, they are telling us that they are including valid HTML (which they are not) by using a DocType Declaration. The solution to this specific bug is to evangelise them (let them know of their mistake) and have them fix it. it's a simple fix, so I expect them not to have a problem with it. The more general one bug which you describe is bug 52931 like I mentioned and you are welcome to join in on the discussion on that one. I hope this clears up the reasoning behind this bug's status.
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Priority: -- → P2
Summary: Mozilla doesn't display content within tables on some pages on Scriptsearch.com → scriptsearch.com - Mozilla doesn't display content within tables on some pages on Scriptsearch.com
*** Bug 98135 has been marked as a duplicate of this bug. ***
*** Bug 104189 has been marked as a duplicate of this bug. ***
Whiteboard: [aok]
Mass reassign of all tech-evangelism us general bugs assigned to bc to doron except bc's P1 bugs. You may search for this mass reassign (it is 305 bugs) by searching for the keyword 'greeneggsandham'
Assignee: bclary → doronr
fixed in the best possible way - they corrected the comments!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Unfortunately, it has not been "fixed" yet, as they have not changed the comments. If you go to the URL that I referenced when I first filed this bug and look at the source code, you will see that it still contains the following "comment": <!--------------------------- --------------------> This has not changed one bit from when I filed this bug. What has changed, however, is that recent versions of Mozilla, include RC1, which I am currently using, would sometimes display this page (and the pages for other items listed in ScriptSearch) the first time that I went to it. Curiously, however, if you reload the page or visit it again later, then the main body part of the page disappears again, just as it did when this bug was first filed. Please try this yourself to confirm. Thanks.
ah - DAMN
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 186763 has been marked as a duplicate of this bug. ***
*** Bug 187427 has been marked as a duplicate of this bug. ***
*** Bug 191924 has been marked as a duplicate of this bug. ***
tech evang june 2003 reorg
Assignee: doron → english-us
Status: REOPENED → NEW
QA Contact: zach → english-us
*** Bug 211837 has been marked as a duplicate of this bug. ***
*** Bug 206362 has been marked as a duplicate of this bug. ***
*** Bug 218785 has been marked as a duplicate of this bug. ***
*** Bug 224757 has been marked as a duplicate of this bug. ***
Whiteboard: [aok] → [aok], has been contacted
*** Bug 360123 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > *** Bug 360123 has been marked as a duplicate of this bug. *** > After reading the comments, I believe that the quoted specification states that multiple dashes lead to accidentally use combinations of "-->" WITHIN a comment and therefore SHOULD be avoided. It doesn't explicitly say that any combination of dashes within a comment are a syntactical error.
I'm going to go ahead and mark this as Reso Fixed, as this bug is over 7 years old, and it wfm
Status: NEW → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: