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.
Created attachment 10768 [details] Testcase that shows described layout bug with table cells and input fields
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
This is a pretty serious layout bug. Any chance this one can get a higher priority (nsbeta3?) tag?
PDT: this sample uses basic DOM1 to insert a textfield in a table. When removing the textfield, almost all tables break.
firstname.lastname@example.org , 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
adding brackets, although i disagree w/ the status.
Whiteboard: nsbeta3- → [nsbeta3-]
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.