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)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: stephe, Assigned: karnaze)

References

Details

(Whiteboard: [rtm-])

Attachments

(3 files)

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.
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
Attached file reduced testcase
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
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. 
Status: NEW → ASSIGNED
Keywords: rtm
Whiteboard: [rtm need info] r=dcone [fix-in-hand]
Whiteboard: [rtm need info] r=dcone [fix-in-hand] → [rtm+] a=buster, r=dcone [fix-in-hand]
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]
does the patch also fix bug 52012 / bug 40855?
Sorry, I don't have time to try that.
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]
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]
*** Bug 57324 has been marked as a duplicate of this bug. ***
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++.
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]
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.
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]
rtm-, not ship stopper.
Whiteboard: [rtm+] a=buster, r=dcone [fix-in-hand] → [rtm-] a=buster, r=dcone [fix-in-hand]
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.
*** Bug 60188 has been marked as a duplicate of this bug. ***
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.
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Nifty.  Works for me, Mozilla 113004 on NT4.
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 → ---
Keywords: nsbeta1
http://netscape.networksolutions.com/account/retail_a1.jhtml
from a dup of this bug, still has some oddities in layout.
QA Contact Update
QA Contact: bsharma → vladimire
Moving to m0.9.1
Status: REOPENED → ASSIGNED
Whiteboard: [rtm-] a=buster, r=dcone [fix-in-hand] → [rtm-]
Target Milestone: --- → mozilla0.9.1
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 ago23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.1 → mozilla0.9
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).
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.

Attachment

General

Creator:
Created:
Updated:
Size: