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)
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.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: mozilla0.9
Reporter | ||
Comment 5•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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
Reporter | ||
Comment 7•24 years ago
|
||
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 → ---
Comment 8•24 years ago
|
||
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
Reporter | ||
Comment 9•24 years ago
|
||
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.
Reporter | ||
Comment 11•24 years ago
|
||
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
Assignee | ||
Comment 12•23 years ago
|
||
Moving to m0.9
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 13•23 years ago
|
||
Marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•