28811 - Bad rendering after clicking on inputline in table

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P1)

Description

[Jindrich Sarson]

This bug you can see, if you will click on any link on the left side of
http://upcase.inf.upol.cz. After click the cell of table will rool to right and
the link is not loaded, after second click (on the "rolled" cell) is page
loaded. I tesed it on Linux, and this bug I see for more than 2 weeks.

Comment 1

[Tom Mraz]

Sorry, but I don't see any problems when clicking on the links on the page.

Comment 2

[Tom Mraz]

Sorry for the spam, but I've forgot to mention I'm using Linux build 2000022217.

Comment 3

[Jindrich Sarson]

In the latest build (from 02-22-2000) you can see the bug when click 
on "search" inputline in http://upcase.inf.upol.cz. It looks very interesting: 
when the page is reendered - the search inputline is'tn respect style sheet's 
size (like in old Netscape). When you click on search inputline, whole cell of 
table roll to second cell and the size of the inputline will incease - as it is 
defined in style sheet.

Comment 4

[Doron Rosenberg (IBM)]

confirming bug.

Comment 5

[karnaze (gone)]

Adding incremental reflow keywords to comment.

Comment 6

[Tim Stallmann]

Testcase made, this seems to be a pretty simple bug (compared to most of the 
others). I'm using build M15, win98.

Comment 7

[Tim Stallmann]

Attachment: testcase

Comment 8

[karnaze (gone)]

An incremental reflow problem.

Comment 9

[karnaze (gone)]

Fixed.

Comment 10

[karnaze (gone)]

When the patch for bug 41306 is checked in, this bug needs to be reopened and 
assigned to buster. In the test case, during the cell's unconstrained reflow, 
the <input>'s reflow state is correctly not setting a constrained 
mComputedWidth. But during the cell's constrained reflow, the cell's block is 
not reflowing the <input> so that the percentage width can be honored. When the 
user clicks into the text field the incremental reflow gets handled and the 
sizes are the way they should be.

The changes I made to fix this bug originally have been backed out (from the 
reflow state code) in the patch for 41306. My strict interpretation of the CSS 
spec plus consideration for Nav compatibility has caused more bugs to appear. 

Comment 11

[karnaze (gone)]

The patch for bug 41306 was checked in, reopening.

Comment 12

[karnaze (gone)]

Reassigning to Buster.

Comment 13

[buster]

setting to M19.

Comment 14

[buster]

suggest we approve this for nsbeta3.  Without fixing this, any page that has 
inline replaced elements (form controls, images, etc.) that have layout 
characteristics defined in terms of percentages (width, height, border, padding, 
margin, etc.) will lay out incorrectly in many situations.  The error is that 
block reflow tries to optimize which lines need resize reflows, and which can be 
skipped.  We were incorrectly skipping lines that contain elements whose 
layout depends on the containing block's layout.  The solution is for each 
inline frame to scan it's children during reflow and determine if they are 
"percentage-aware" or not.  This is only done for inline replaced elements, and 
for nested inline containers (via a bit.)  Finally, during block reflow each 
line is marked with a bit to skip the optimization if one of it's children is 
percentage-aware.  Block reflow now checks for this bit on the line.

I have the fix for this.  It is low risk, and has no significant performance 
implications.

Comment 15

[buster]

Attachment: zip file that includes diffs (htmldiff tool output, view with mozilla)

Comment 16

[buster]

diffs attached.  rick, review and approval?
see the first attachment for a trivial test case.

Comment 17

[buster]

Attachment: a little bit more of a test case

Comment 18

[buster]

chris k, I need a "+" on this one.  Anybody on the cc-list want to do the 
review?  Diffs are attached, I could talk you through it in a few minutes if 
they aren't self-explanatory.

Comment 19

[karnaze (gone)]

Adding nsbeta3+ to status whiteboard.

Comment 20

[buster]

fix checked in.  r=karnaze

Comment 21

[buster]

really marking fixed

Comment 22

[Christine Hoffman]

Using 9/12 builds across platform, verified bug fixed. Clicking on input line, 
no rolling is apparent.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Some testcases added to reftest as part of bug 163504.