Closed
Bug 22765
Opened 25 years ago
Closed 25 years ago
form inputs are incorrectly painting at left edge in floated tables
Categories
(Core :: Layout: Form Controls, defect, P2)
Core
Layout: Form Controls
Tracking
()
People
(Reporter: kennedyh, Assigned: troy)
References
()
Details
Attachments
(1 file)
while working on creating a simplified test case for bug 22063,
i came across this (i have no idea if they're related).
text inputs appear to be resizing themselves when they are within nested tables.
go to
http://onlyzool.engin.umich.edu/table_test.html
click in the top field to give it focus, then click in the bottom field
to give it focus.
watch the left side of the form while you do this.
the form elements flash out to the full width of the enclosing table,
and then become active.
the effect is only seen within the table, as visible at
http://onlyzool.engin.umich.edu/table_test2.html
(i.e. it doesn't affect forms or form elements outside of the outermost
enclosing table)
Reporter | ||
Comment 1•25 years ago
|
||
ack.
i suck.
This is with M12 on WinNT4 as well as my Solaris 2.6 build of M12.
Updated•25 years ago
|
Assignee: karnaze → rods
Comment 2•25 years ago
|
||
Rod, did your optimization fix this.
Updated•25 years ago
|
Assignee: rods → karnaze
Comment 3•25 years ago
|
||
Chris, no it didn't fix it and I am going to be assigning the that other bug
over to you. So this bug is a duplicate of that bug. I let you choose which bug
you want to fix. reassigning back to you.
Updated•25 years ago
|
Assignee: karnaze → buster
Comment 4•25 years ago
|
||
Steve, I talked to Don and Rod and they said you might know what is going on.
For test.html I put a printf statement inside of nsGfxTextControlFrame::Paint
and discovered that when the bottom text field got focus for the 1st time the
top text field's paint method was not being called yet its text was being
painted in the wrong location. Don had me step into nsRenderingContextWin::
CopyOffScreenBits and we couldn't see that a translation was taking place. The
problem only occurs when the bottom text field gets focus for the 1st time.
downgrading severity from major to minor. It's just a rendering artifact,
right? The text control momentarily paints incorrectly then corrects itself. I
don't think it ever actually changes size.
Let me know if I've misinterpreted the bug.
Setting to M16.
Reporter | ||
Updated•25 years ago
|
Severity: minor → major
Reporter | ||
Comment 6•25 years ago
|
||
re-upgrading to major.
Rendering artifact or no, this bug makes large forms in tables near-unusable.
Having to switch browsers to fill out a web form sounds major to me...
<shrug>
The URLs I posted are merely annoying, but they are
the simplest test cases I could come up with.
http://onlyzool.engin.umich.edu/table_test3.html
has 4 text fields and a select. give each of the text
fields focus, and then pull down the select.
then imagine a 20-element form.
ok, I'll look into this soon.
First guess: since this only happens in nested tables, I'll bet it has
something to do with the text control repainting itself when given a resize
reflow of NS_UNCONSTRAINEDSIZE. The table code does this to calculate column
widths. A simple test would be to change to tables in the test case to have the
css style property:
table-layout: fixed;
and providing reasonable widths for each column. I'll bet the problem goes away
if you do this (not a solution, of course, just another data point.)
22063 is almost certainly a duplicate of this bug. Increasing priority because
so many people are seeing this.
more info: The problem is with floating tables. Nested tables are irrelevant
to this problem. I'll attach a test case that shows the bug with just a right
floated table and a little text.
Comment 10•25 years ago
|
||
Summary: form inputs are incorrectly resizing in tables → form inputs are incorrectly painting at left edge in floated tables
Comment 11•25 years ago
|
||
changed the summary to reflect what's really going on. The text controls are
painting at the wrong spot during floater repositioning, they are not resizing
at all. So this bug has no impact on reflow performance, only painting
performance.
cc-ing troy who might have some insight, and nisheeth who may someday care.
Comment 12•25 years ago
|
||
talking with troy, he believes this is a problem with the block code not doing
the right thing with the new DidReflow semantics. The block code (or something
in the table code?) is not positioning the contained view on the way down
properly. Rather, it seems to be defaulting to the left edge, then fixing this
mistake on the way up, causing an additional paint. Troy knows how to fix this,
assigning to him.
Clearing milestone so Troy can fit it into his schedule appropriately.
Comment 13•25 years ago
|
||
*** Bug 22063 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
troy, when you fix this you should verify against the test case on bug 22063 as
well.
Comment 15•25 years ago
|
||
*** Bug 22905 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
*** Bug 22691 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 17•25 years ago
|
||
Same floater issue as bug #22684
*** This bug has been marked as a duplicate of 22684 ***
You need to log in
before you can comment on or make changes to this bug.
Description
•