Closed Bug 208195 Opened 22 years ago Closed 22 years ago

Forms fail to render in tables with rowspan

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: cursus.publicus, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Build Identifier: Netscape/6.2.3 NS 6.2.3 on a PC fails to render forms except in quirks mode. Reproducible: Always Steps to Reproduce: See demo page Actual Results: Form not rendered Expected Results: Render form
WFM, 2003-06-03-05 trunk Linux. Reporter, please try a recent build, 1.4RC1 for example.
Marking worksforme, since NS 6.2.3 is based on Mozilla source that is nearly 3 years old now. Please reopen if this is a problem with anything like a recent build.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
This version has been issued to 60,000 of our students. It is a pity that such a serious bug was never recorded. It is important that this bug report remains firmly on the record so that searches will find it? I would be interested to know about any workarounds. It is most unfortunate that web editors are inclined to use an incorrect doctype to get their forms to work. Neville Hillyer Telematics Webmaster Open University
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Resolved bugs are still found by searches. And the bug has gotten resolved sometime in the three years since Netscape 6.2.3 branched off the trunk, as far as anyone can tell. If you _can_ reproduce the bug in a _recent_ build (1.3.1 or 1.4rc1), please reopen; the build you are filing the bug against corresponds to approximately Mozilla 0.6. I'm sorry that your site administrators decided to install such an ancient (and very buggy) piece of software that was utterly not ready for release (hence the 0.6 version number). As for workarounds, could you clearly explain exactly what fails to render (post a screenshot in this bug, maybe?) It's hard to guess at what's going on otherwise.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
Thanks for your comments. I could not find this bug listed during the several hours that I searched for it so it is important that this report is not removed. Can you point to an earlier report about it? I would like to see an explanation for it together with any satisfactory workarounds. Our problem is nothing to do with site administrators. Each year my employer (the largest University in the UK) sends software on CDs to about 60,000 remote students. Decisions are taken in October and the CDs shipped in February. It is unfortunate that we cannot update these 60,000 versions of Netscape 6.2.3 until February 2004. If there was any documentation about the bug we may be able to use it to update our web sites. I am afraid this episode has not done much for the reputations of either Mozilla or Netscape. I have put revised pages with the requested PC screenshot at: http://informatics.open.ac.uk/brow/ns/bug/rowspan/ Neville Hillyer Telematics Webmaster Open University
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Neville, I did not say this bug _was_ already filed. Resolving the bug does NOT remove the bug report -- it merely makes it not be in a developer's queue of things to work on. Which is why bugs are marked resolved once they are resolved with current Mozilla builds. Please do not reopen this bug every time you comment. I'm sorry that the university you work on decided to ship version 0.6 of a software package and was (understandably) unhappy with the result. I can guarantee you that Mozilla 1.0 (which is the basis for Netscape 7.0x) was a whole lot better than the alpha-quality Mozilla 0.6. I realize that Netscape was shipping this same code as a product, but Mozilla.org has no control over Netscape or AOL and cannot prevent them from shipping whatever they want and calling it whatever they want... Looking at the screenshot, nothing really jumps out at me as an obvious possibility for the rendering problem.... how much of the HTML can you remove and keep the testcase rendering incorrectly? Are the tables necessary, for example? Hopefully we can work together to figure out a workaround you can use...
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
I suspect that this bug was never "resolved". It was probably not noticed (as many editors do not use the correct doctype) and went away during some change of code. It is a pity that, apparently, there is little interest in understanding serious historic bugs that affect a significant proportion of users. My experience is that 'Neville's rowspan bug' (this is what I have decided to call it) affects PCs only and most (not all) tables that contain both rowspan and forms. As far as I am aware this is an HTML issue and not related to style. The simple workaround, which I deplore, is to alter the doctype to force quirks mode. However, I would prefer to add extra style or HTML statements rather than use an incorrect doctype. Any thoughts? Please don't keep saying that NS 7 is much better. It has serious instability problems on non-OSX Macs. This is an historic problem with most Netscapes from 4.0 onwards but it has become much more of a problem with version 7. It has been reported by myself and others over several years. There is a view that it is a memory management problem. Typically the memory used increases indefinitely until the application crashes often crashing the Mac at the same time. No other application does this. I have a (perhaps severe) test that causes Netscape 7.02 to crash my OS 9.1 iMac within 4 minutes every time. Faced with your comments about testing the latest builds I did some tests on Mozilla 1.2.1 and can confirm that it does the same. Perhaps both Mozilla and Netscape could put more effort into solving some of the fundamental problems ie play with CSS after HTML is made to work and only do that when the application runs without crashing computers so predictably. Neville
Neville, "resolved" just means "no longer reproducible". "resolved worksforme" means precisely "no longer reproducible and not clear what exact change made the problem disappear".... I suppose I could spend a week or so narrowing down the exact change that fixed this bug, and with almost complete certainty it would be one of: the two nearly complete rewrites of the form control rendering code that have happened since 0.6, the numerous parser changes that happened in the 0.7-0.8 timeframe, or the numerous table layout changes that have happened along the way. My personal bet is on the first two of those, but in any case, finding the exact patch that changed this behavior would really not help anyone. You say that some tables are affected but not others. How much code can you remove from your testcase and still reproduce this bug? Producing such a minimal testcase (see last paragraph of comment 6) would give us some idea of what you can change to not trigger the bug...
Below is the minimum code for Neville's rowspan bug. Removing any one of the following 'cures' the bug: 1 rowspan=2 2 a 'br' tag 3 "http://www.w3.org/TR/html4/loose.dtd" It appears to require 3 'br' tags prior to a table element to inhibit rendering of the element. The location of the 'form' and '/form' tags appears unimportant. The bug affects all forms on http://informatics.open.ac.uk/brow/ns/bug/rowspan/info.html except the one at the top of column 2. To overcome this an incorrect doctype is used on the live page at http://informatics.open.ac.uk/ The code below is mounted at: http://informatics.open.ac.uk/brow/ns/bug/rowspan/min.html Any further thoughts? Neville <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title></title></head><body><table><tr><td>B</td><td rowspan=2><br><br><br><form method=get action="http://www.htmlhelp.com/cgi-bin/validate.cgi"><input type=hidden name=url value="referer"><input type=submit value="G"></form></td></tr><tr><td>U</td></tr></table></body></html>
Sorry typo in last post - 'table' should have read 'form' - corrected word in capitals in this post. - Neville Below is the minimum code for Neville's rowspan bug. Removing any one of the following 'cures' the bug: 1 rowspan=2 2 a 'br' tag 3 "http://www.w3.org/TR/html4/loose.dtd" It appears to require 3 'br' tags prior to a FORM element to inhibit rendering of the element. The location of the 'form' and '/form' tags appears unimportant. The bug affects all forms on http://informatics.open.ac.uk/brow/ns/bug/rowspan/info.html except the one at the top of column 2. To overcome this an incorrect doctype is used on the live page at http://informatics.open.ac.uk/ The code below is mounted at: http://informatics.open.ac.uk/brow/ns/bug/rowspan/min.html Any further thoughts? Neville <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title></title></head><body><table><tr><td>B</td><td rowspan=2><br><br><br><form method=get action="http://www.htmlhelp.com/cgi-bin/validate.cgi"><input type=hidden name=url value="referer"><input type=submit value="G"></form></td></tr><tr><td>U</td></tr></table></body></html>
Does adding "height='100%'" to the <td> in question help? (Not sure that's what you actually want on that page, but...)
Afraid not - tried it here: http://informatics.open.ac.uk/brow/ns/bug/rowspan/minh.html Neville
If you put a border on the <form>, what does it look like? Is the <form> the right height?
I have added a border to the table on http://informatics.open.ac.uk/brow/ns/bug/rowspan/minhb.html NS 6.2 on a PC looks the same as other platforms/browsers except that the 'G' does not look like a button. Neville
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.