Closed
Bug 55545
Opened 24 years ago
Closed 23 years ago
tables not rendered with misplaced input type=hidden
Categories
(Core :: Layout: Form Controls, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: stephe, Assigned: karnaze)
References
Details
(Whiteboard: [rtm-])
Attachments
(3 files)
30.00 KB,
application/octet-stream
|
Details | |
247 bytes,
text/html
|
Details | |
1.79 KB,
patch
|
Details | Diff | Splinter Review |
Mozilla chokes on a FORM that is ok in NN4 and IE5 and is mostly ok with a version of Mozilla from the previous day. If you untar the attachment with its html file, log.html, and associated gifs and load it in Mozilla 100504, you will see the form looks screwy: the texareas are not displayed. However, you can still type in the invisible textareas and click on the Login button and actually manage to log in. Now in Mozilla 100604 (one day later), enter a username and password and click on the Login button, and the button disappears and Mozilla does not attempt to submit the form. I should memtion, of course, that log.html contains invalid html. On line 169 is an INPUT field that does not belong there. It should be up a few lines so that it is under the FORM tag. I would just fix the html, but this is the login page for a @#&(*^ commercial bug tracking system, and I have no access to the source. In any case, this page works fine with NN4 and IE5 so it is a compatibility bug if nothing else. Tested using Mozilla 100604 on NT4.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
The page is incorrectly authored, they have a <input type=hidden tag right after a table tag. This is still a bug because we should be rendering something.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
if I remove the outer table or the input type=hidden element then it seems to render fine. - reassigning
Assignee: rods → karnaze
Severity: normal → major
Priority: P3 → P1
Summary: Mozilla chokes on a FORM that is ok with NN4 and IE5 → tables not rendered with misplaced input type=hidden
Assignee | ||
Comment 5•24 years ago
|
||
Assignee | ||
Comment 6•24 years ago
|
||
Nominating for rtm. In general, this bug will occur anytime a nested nsTableOuterFrame gets an incremental reflow for which it is the target and its nsTableInnerFrame has not gotten an incremental reflow prior.
Assignee | ||
Updated•24 years ago
|
Whiteboard: [rtm need info] r=dcone [fix-in-hand] → [rtm+] a=buster, r=dcone [fix-in-hand]
Comment 7•24 years ago
|
||
rtm-, we don't see that this will happen often enough to hold the rtm. If you have data that says this is a high profile problem, please add it here.
Whiteboard: [rtm+] a=buster, r=dcone [fix-in-hand] → [rtm-] a=buster, r=dcone [fix-in-hand]
Assignee | ||
Comment 9•24 years ago
|
||
Sorry, I don't have time to try that.
Comment 10•24 years ago
|
||
please reconsider for rtm based on likely dups: bug 55736 and bug 55780
Whiteboard: [rtm-] a=buster, r=dcone [fix-in-hand] → [was r t m -] a=buster, r=dcone [fix-in-hand]
Assignee | ||
Comment 11•24 years ago
|
||
I'm marking this rtm+ again based on the previous comments, the likely dups, and the fear that there are a lot more pages being hit by this (since <input type=hidden> is very common).
Whiteboard: [was r t m -] a=buster, r=dcone [fix-in-hand] → [was r t m -] [rtm+] a=buster, r=dcone [fix-in-hand]
Comment 12•24 years ago
|
||
*** Bug 57324 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
Duplicate bug found same situation on this Mac Zone page: http://www.zones.com/cgi-bin/zones/zbs/scripts/home/home_page.jsp?zone=Mac Input type="hidden" is found on most top 100 sites. If table is malformed, they will probably have this problem (looking now to see if I can find more sites). Please consider for rtm++.
Comment 14•24 years ago
|
||
We need to know which popular sites exhibit this problem (top100 would be good.) Please also test this patch against sites which exhibit the problem to determine whether the potential dups are real dups. Send it back to rtm+ when this is done and described in this bug.
Whiteboard: [was r t m -] [rtm+] a=buster, r=dcone [fix-in-hand] → [rtm need info] a=buster, r=dcone [fix-in-hand]
Comment 15•24 years ago
|
||
It's been about 2 weeks now. This should be set back to rtm+ PDT: One of the major complaints I've heard over and over is NS6PR3 dropping certain tables. I think any fix that helps this problem should get in.
Assignee | ||
Comment 16•24 years ago
|
||
Ok, I'm marking rtm+, but we still seem to be missing specific popular sites as requested by PDT.
Whiteboard: [rtm need info] a=buster, r=dcone [fix-in-hand] → [rtm+] a=buster, r=dcone [fix-in-hand]
Comment 17•24 years ago
|
||
rtm-, not ship stopper.
Whiteboard: [rtm+] a=buster, r=dcone [fix-in-hand] → [rtm-] a=buster, r=dcone [fix-in-hand]
Comment 18•24 years ago
|
||
On the question of 'top100', this occurs on 1) ticketmaster.com and 2) networksolutions.com, including a Netscape cobranded page. http://netscape.networksolutions.com/account/retail_a1.jhtml https://ticketing.ticketmaster.com/cgi/purchasePage.asp?event_id=C00315F8864479A&event_code=EHS1129 -- which is the URL from bug 55780 (which is a dup of this bug, I believe). This wasn't difficult to predict (that we would have top100 sites with this bug). And in fact, both chrisd and karnaze did predict it.
Comment 19•24 years ago
|
||
*** Bug 60188 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Bug also shows on http://www.queenswood.co.uk/acatalog/Queenswood_Online_Power_Tools_3.html and any other pages in this catalog generated by the popular (?) Actinic Catalog program. Real nuisance. Renders fine on Netscape and IE. Because the templates are pre-set, I now have to revert to Netscape 4.76 to develop this site -- Mozilla was fine until the end of last week. A pity.
Assignee | ||
Comment 21•24 years ago
|
||
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 22•24 years ago
|
||
Nifty. Works for me, Mozilla 113004 on NT4.
Comment 23•24 years ago
|
||
I The text areas still disappear on Windows 98 build 2001-01-24-13-MTEST When I start typing they appear. Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 24•24 years ago
|
||
http://netscape.networksolutions.com/account/retail_a1.jhtml from a dup of this bug, still has some oddities in layout.
Assignee | ||
Comment 26•23 years ago
|
||
Moving to m0.9.1
Status: REOPENED → ASSIGNED
Whiteboard: [rtm-] a=buster, r=dcone [fix-in-hand] → [rtm-]
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 27•23 years ago
|
||
I'm not seeing any problems on the (too) many urls menioned in this bug or attachment #2 [details] [diff] [review]. Sorry but I can't untar attachment #1 [details] [diff] [review] (it would be better to attach images and then attach an html file referencing them). The patch fixed most of this and the urls after the patch may have been fixed by other checkins. Marking fixed and moving to m0.9.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.1 → mozilla0.9
Comment 28•23 years ago
|
||
It untars fine for me using tar on Linux and WinZip on Windows, but to save you the trouble, I hereby verify that my test case is working fine on the latest Linux and Win32 trunk builds (2001032604 for Win32 and the previous day's for Linux).
Comment 29•23 years ago
|
||
Hmm you didnt verify it. Verifying on build 2001-03-29-04-Mtrunk
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•