Submit buttons in table move (and disrupt table) when clicked

RESOLVED DUPLICATE of bug 96343

Status

()

defect
RESOLVED DUPLICATE of bug 96343
18 years ago
18 years ago

People

(Reporter: neel, Assigned: karnaze)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

656 bytes, text/html
Details
(Reporter)

Description

18 years ago
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.

Comment 1

18 years ago
*** Bug 101217 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
related to bug 96321?

Comment 3

18 years ago
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.

Comment 4

18 years ago
Posted file testcase2

Comment 5

18 years ago
Guess this should atleast be confirmed :)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

18 years ago
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.
(Assignee)

Comment 7

18 years ago

*** This bug has been marked as a duplicate of 96343 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 8

18 years ago
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.
(Assignee)

Comment 9

18 years ago
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.