Closed Bug 59354 Opened 24 years ago Closed 23 years ago

Layout completely messed up for form inside nested tables

Categories

(Core :: Layout: Form Controls, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME
mozilla0.9

People

(Reporter: simon.king, Assigned: karnaze)

Details

(Whiteboard: mozilla0.9)

Attachments

(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m18) Gecko/20001106
BuildID:    2000110621

I use nested tables to create a tabbed-dialog style of page. In Netscape 4.x and
IE the page lays out fine, but in Mozilla under Linux, the form seems to be
placed half ouside one of the tables, and it becomes completely unusable.

Inside the tabbed-dialog table, there are two more tables that I use to create
the impression of a table with black borders. I have experienced problems with
this under mozilla, but I believe that is bug 21461.

I will attach the offending HTML in a minute. I will also reboot to see whether
I get the same behaviour in Windows.

Reproducible: Always
Steps to Reproduce:
1. View the attatched test case in mozilla, Netscape 4.x and Internet Explorer

Actual Results:  The form appears half outside the outer table and the controls
are invisible.

Expected Results:  You should see a form with various text inputs and a listbox
inside a table.
Attached file HTML Testcase
OK - this occurs both on Linux and Windows 98 (a slightly older build, but I've
seen this happening for a while now, so I don't believe that will make a difference)

Sorry about the length of the testcase, particularly the CSS. I will try and
trim it down at some point.
I see this in Build 2000110604 in WinNT.
I have cut down your testcase, including removing the CSS.
I have also set the border of all the tables to 1, to show where the tables are.
Attached file Cut-down testcase
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: mozilla0.9
I'm just wondering about the status of this bug - I see you've put it down as
mozilla0.9 (which didn't mean much to me until I saw today's announcement of
mozilla0.6) - does this mean that you don't see this as a high priority bug?

It makes mozilla completely unusable for me on at least one web application I
have written, and I can't believe no-one else sees this bug.

If it is a problem with my HTML, then I'll happily change it, but I don't know
what it might be.

So, without trying to sound pushy (I know, I am) I'm going to raise the severity
to major
Severity: normal → major
I don't think this is a form issue and it is now fixed, I tested with 
yesterday's build. marking works for me
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Hmmm. The testcase looks about right now (apart from the black line is missing
at the bottom, but I think that is bug 21461) However, when I look at the page
as it is in my application, it is still wrong as before. I will attach the full
page this time

Scratch that - I've just been playing around with the attachment, and if I click
on the FIRST attachment, it appears properly. But then if I press BACK, then
FORWARD again, it renders badly. Combinations of reload and shift-reload seem to
fix it again. I can't get the same thing to work with the cut-down testcase.

It may also be worth noting that my page that causes me a real problem is
written in PHP, and therefore may not get cached, and also the style sheet it
uses is generated with PHP. Whereas the testcases here, although located with a
cgi script, are basically static. Could it be, then, that the page is rendered
differently when being loaded from the cache rather than from the network?

PLEASE tell me you see the same behaviour - click on the first attachment, then
click BACK, then FORWARD, and tell me what you see.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Yes, I am seeing what you are seeing when I use the Forward/Back button. From 
what you describe it sounds like a table incremental reload problem and probably 
not a form specific issue. reassigning
Assignee: rods → karnaze
Status: REOPENED → NEW
Just confirming (for the new owner of this bug) that the problem is still here
in nightly build from 17th December. The second testcase actually seems to work,
but the first definitely doesn't. To reproduce it, click on the first
attachment, and see it display properly. Then click Back, and then Forward, and
see it display badly. On the actual page (sorry, I'm behind a firewall so I
can't point you to it) the page ALWAYS lays out badly - no need for the
Back/Forward thing. And there are a whole load of other examples.
QA Contact Update
QA Contact: bsharma → vladimire
FWIW, Mozilla now appears to render the forms properly on the testcases and on
my own app. Since this was my bug originally, if no-one else continues to see
this problem I will close the bug in the next couple of days.

Thanks a lot for fixing it (consciously or unconsciously) ;-) Now I can start
persuading everyone in my company to use Mozilla
Moving to m0.9
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → WORKSFORME
Verifying 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: