From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010918 BuildID: 2001091808 At the above URL, whenever I click on one of the select buttons in the table, the button moves downward, sometimes taking the entire line of that table downward as well. Effect is negligible on buttons near top of table, more pronounced toward bottom of table. Bug is present in 0.9.4 as well as Sept. 18 2001 nightly build. Component is specified as "HTML Tables", since I do not see this problem anywhere else. Reproducible: Always Steps to Reproduce: 1. Go to above web site (duh) 2. Choose a nice sound card. I chose the SBLive PCI 5.1 OEM version. 3. Attempt to buy the card by clicking select. Actual Results: The submit button moves downward and out of the way as soon as it is clicked. On some occasions, the entire line of text from the table moves downward as well, crashing into the following line. Expected Results: Button should have gone down and come back up without moving around (and let me buy my sound card). For that particular line of the table, even after it has moved, attempting to click it again will move it further down.
*** Bug 101217 has been marked as a duplicate of this bug. ***
related to bug 96321?
Definatly related, but the 96321 has alot to do with border weirdness with forms in tables, this is a different weirdness, with forms in tables, that doesn't require some of the other bugs conditions. Attaching a testcase, based upon testcase for 96321, but it doesn't require the image tr, if added, you see both bugs in same table.
Guess this should atleast be confirmed :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Would like to note that if you change the tag order from form-tr-td-input-/td-/tr-/form to tr-form-td-input-/td-/form-/tr it renders properly. If you move the form tags inside the td tags, it still renders properly in Mozilla, but fails to render properly in IE (if that matters). Not sure which, if any, of those orders is the 'correct' one, but I would expect that any of them _should_ render the same way. As for the progressive nature of it, it appears that it is a cumulative 1 pixel per row offset. By the time you get to about row 15 in a series of buttons, one row will completely overlay the row below it.
*** This bug has been marked as a duplicate of 96343 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
I really have my doupts about this being a dup of that. That seems to be 96321 possibly. While this is definatly related, its about submit button movement, not the overlap of tables. leaving as dup for now.
I am fairly confident that it is a dup (and didn't bother to apply the patch in bug 96343 to verify) because by setting cellspacing=0 in the attachment, the problem goes away.
You need to log in before you can comment on or make changes to this bug.