Closed Bug 44148 Opened 21 years ago Closed 21 years ago

Adding and removing textfield to/from table cell breaks cell borders


(Core :: Layout, defect, P3)






(Reporter: taras.tielkes, Assigned: karnaze)



(Keywords: testcase, Whiteboard: [nsbeta3-])


(1 file)

Using HTML DOM1 to programmaticaly add, and later remove a textfield from a
table cell shows that the table borders are (unnecessarily?) repainted is a
wrong way.

Most of the times the RIGHT cell border is moved a pixel, or a couple of pixels
to the right direction. This seems not the reaction to a reflow, as the
erroneous repaint occurs when you REMOVE the textfield, not when you add it.

Also, the textfield is much smaller that the table cell.

Behaviour can be seen in all the latest builds on Windows, and sometimes also
occurs when you select a part of a table, and then remove your selection.

I will attach a testcase that shows this behaviour. The testcase has a small
HTML table, and two form buttons. Press the first button to add a textfield to
the table cell, then press the second button to remove it again. This behaviour
can be observer with both strict DTDs as without. Using a strict DTD and setting
the environment variable ENABLE_STRICT=true makes no difference.
Keywords: testcase
I'm guessing this is a table layout bug for karnaze; cc rods if karnaze is out.
Assignee: clayton → karnaze
Also seen on Linux, changing plaf/OS to All/All.
OS: Windows NT → All
Hardware: PC → All
Not enough of the table area is being invalidated. Accepting the bug.
Target Milestone: --- → M19
This is a pretty serious layout bug.

Any chance this one can get a higher priority (nsbeta3?) tag?
Keywords: nsbeta3
PDT: this sample uses basic DOM1 to insert a textfield in a table. When removing
the textfield, almost all tables break. , I'm having a lot of issues with this one. When you have
time to take a look, I'll be willing to provide a lot of testing and QA. Give a
yell if I can help.
I'm downgrading this to nsbeta3- because it only seems to fail with collapsing 
borders (CSS2). 
Depends on: 41262
Whiteboard: nsbeta3-
adding brackets, although i disagree w/ the status.
Whiteboard: nsbeta3- → [nsbeta3-]
Moving m1.0.
Target Milestone: --- → mozilla1.0
Looks fine in a 4/4/2K1 build.

Don't know if it really depends on 41262, but it seems to work now.
Shall I mark WORKSFORME?
Marking worksforme based on comments.
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.