22765 - form inputs are incorrectly painting at left edge in floated tables

Status: VERIFIED DUPLICATE of bug 22684

(Core :: Layout: Form Controls, defect, P2)

Description

[Hugh Kennedy]

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)

Comment 1

[Hugh Kennedy]

ack.
i suck.

This is with M12 on WinNT4 as well as my Solaris 2.6 build of M12.

Comment 2

[karnaze (gone)]

Rod, did your optimization fix this.

Comment 3

[rods (gone)]

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.

Comment 4

[karnaze (gone)]

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.

Comment 5

[buster]

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.

Comment 6

[Hugh Kennedy]

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.

Comment 7

[buster]

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.)

Comment 8

[buster]

22063 is almost certainly a duplicate of this bug.  Increasing priority because
so many people are seeing this.

Comment 9

[buster]

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

[buster]

Attachment: smaller test case that shows bug with <table align=right>, no nested tables involved

Comment 11

[buster]

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

[buster]

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

[buster]

*** Bug 22063 has been marked as a duplicate of this bug. ***

Comment 14

[buster]

troy, when you fix this you should verify against the test case on bug 22063 as
well.

Comment 15

[rods (gone)]

*** Bug 22905 has been marked as a duplicate of this bug. ***

Comment 16

[rods (gone)]

*** Bug 22691 has been marked as a duplicate of this bug. ***

Comment 17

[troy]

Same floater issue as bug #22684

*** This bug has been marked as a duplicate of 22684 ***

Comment 18

[Neil Marshall]

Verified dupe of 22684