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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: phil, Unassigned)
References
()
Details
(Keywords: testcase, Whiteboard: [aok], has been contacted)
Attachments
(1 file)
268 bytes,
text/html
|
Details |
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.
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
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
Reporter | ||
Comment 4•23 years ago
|
||
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.
Reporter | ||
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
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.
Comment 7•23 years ago
|
||
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
Updated•23 years ago
|
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
Comment 9•23 years ago
|
||
*** Bug 104189 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Whiteboard: [aok]
Comment 10•23 years ago
|
||
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
Comment 11•23 years ago
|
||
fixed in the best possible way - they corrected the comments!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•23 years ago
|
||
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.
Comment 14•22 years ago
|
||
*** Bug 186763 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
*** Bug 187427 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
*** Bug 191924 has been marked as a duplicate of this bug. ***
Comment 17•21 years ago
|
||
tech evang june 2003 reorg
Assignee: doron → english-us
Status: REOPENED → NEW
QA Contact: zach → english-us
Comment 18•21 years ago
|
||
*** Bug 211837 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
*** Bug 206362 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
*** Bug 218785 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
*** Bug 224757 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Whiteboard: [aok] → [aok], has been contacted
Comment 22•18 years ago
|
||
*** Bug 360123 has been marked as a duplicate of this bug. ***
Comment 23•18 years ago
|
||
(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.
Comment 25•15 years ago
|
||
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 ago → 15 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•