Closed Bug 28811 Opened 20 years ago Closed 19 years ago

Bad rendering after clicking on inputline in table

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sarsonj, Assigned: buster)

References

()

Details

(Keywords: testcase, Whiteboard: nsbeta3+)

Attachments

(3 files)

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.
Sorry, but I don't see any problems when clicking on the links on the page.

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

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.
Summary: Bad rendering after clicking on link in table → Bad rendering after clicking on inputline in table
confirming bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding incremental reflow keywords to comment.
Status: NEW → ASSIGNED
Keywords: makingtest
Testcase made, this seems to be a pretty simple bug (compared to most of the 
others). I'm using build M15, win98.
Keywords: makingtesttestcase
Attached file testcase
An incremental reflow problem.
Target Milestone: --- → M16
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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. 
The patch for bug 41306 was checked in, reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reassigning to Buster.
Assignee: karnaze → buster
Status: REOPENED → NEW
setting to M19.
Status: NEW → ASSIGNED
Target Milestone: M16 → M19
Priority: P3 → P1
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.
Keywords: nsbeta3
OS: Linux → All
Hardware: PC → All
Whiteboard: [fix in hand]
diffs attached.  rick, review and approval?
see the first attachment for a trivial test case.
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.
Adding nsbeta3+ to status whiteboard.
Whiteboard: [fix in hand] → [fix in hand] nsbeta3+
fix checked in.  r=karnaze
really marking fixed
Status: ASSIGNED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
Whiteboard: [fix in hand] nsbeta3+ → nsbeta3+
Using 9/12 builds across platform, verified bug fixed. Clicking on input line, 
no rolling is apparent.
Status: RESOLVED → VERIFIED
Some testcases added to reftest as part of bug 163504.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.