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)

defect

Tracking

()

VERIFIED DUPLICATE of bug 22684

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)
ack. i suck. This is with M12 on WinNT4 as well as my Solaris 2.6 build of M12.
Assignee: karnaze → rods
Rod, did your optimization fix this.
Assignee: rods → karnaze
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.
Assignee: karnaze → buster
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.
Severity: major → minor
Status: NEW → ASSIGNED
Target Milestone: M16
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.
Severity: minor → major
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.
Target Milestone: M16 → M13
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.)
Priority: P3 → P2
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.
Summary: form inputs are incorrectly resizing in tables → form inputs are incorrectly painting at left edge in floated tables
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.
Assignee: buster → troy
Status: ASSIGNED → NEW
Target Milestone: M13
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.
*** Bug 22063 has been marked as a duplicate of this bug. ***
troy, when you fix this you should verify against the test case on bug 22063 as well.
Blocks: 22497
Status: NEW → ASSIGNED
*** Bug 22905 has been marked as a duplicate of this bug. ***
*** Bug 22691 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Same floater issue as bug #22684 *** This bug has been marked as a duplicate of 22684 ***
Verified dupe of 22684
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: