Bug 15010 - REGRESSION (r25000-r25065): Table rendering broken by a recent nightly
Summary: REGRESSION (r25000-r25065): Table rendering broken by a recent nightly
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://community.nethosted.co.uk/
Keywords: InRadar, NeedsReduction, Regression
Depends on:
Blocks:
 
Reported: 2007-08-19 12:25 PDT by Andrew
Modified: 2007-08-21 11:07 PDT (History)
1 user (show)

See Also:


Attachments
Partial reduction (851 bytes, text/html)
2007-08-19 13:02 PDT, mitz
no flags Details
Use floating point arithmetic for max widths and add a cap (17.94 KB, patch)
2007-08-21 07:19 PDT, mitz
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew 2007-08-19 12:25:22 PDT
If you visit the site it should be pretty clear what the problem is, it appears the table is not being rendered to it's complete length. It renders incorrectly in r25145 I believe, but can't be 100% sure, that this regression was introduced in the last week or so.
Comment 1 mitz 2007-08-19 12:29:29 PDT
This could be a result of <http://trac.webkit.org/projects/webkit/changeset/25011>.
Comment 2 mitz 2007-08-19 13:02:26 PDT
Created attachment 16024 [details]
Partial reduction

When the browser window is sufficiently wide, the innermost table suddenly collapses.
Comment 3 mitz 2007-08-19 14:26:02 PDT
The problem is that as a result of r25011, there are some huge max widths involved in various computations in AutoTableLayout.cpp and when computing integer ratios such as

available * m_layoutStruct[i].effMaxWidth / totalAuto

or

maxNonPercent * 100 * percentScaleFactor / max(remainingPercent, epsilon)

the intermediate products overflow and you get negative numbers. Not sure exactly how to fix it.
Comment 4 Geoffrey Garen 2007-08-20 16:00:25 PDT
Silly idea: perform the division before the multiplication?

Another silly idea: enforce a "max max width?"
Comment 5 Geoffrey Garen 2007-08-20 16:00:47 PDT
<rdar://problem/5423956>
Comment 6 mitz 2007-08-20 16:17:08 PDT
(In reply to comment #4)
> Silly idea: perform the division before the multiplication?

That will introduce huge errors in many cases due to rounding.

> Another silly idea: enforce a "max max width?"

Possible, but may reintroduce the bug fixed by r25011.

I also thought of 
- using a 'long long' for the intermediate product, but I don't know if that's guaranteed to work (that is, allow for bigger values) in all platforms;
- using floating-point math to compute the scaling factors.
Comment 7 Darin Adler 2007-08-20 16:33:11 PDT
(In reply to comment #0)
> If you visit the site

What site?
Comment 8 Matt Lilek 2007-08-20 16:49:12 PDT
(In reply to comment #7)
> (In reply to comment #0)
> > If you visit the site
> 
> What site?
> 

I believe <http://community.nethosted.co.uk/>.  For some reason it was cleared from the URL field.
Comment 9 Maciej Stachowiak 2007-08-20 22:14:27 PDT
floating point math would probably give the best rounding behavior. And it would be easy to check for overflowing the range of an int once at the end.
Comment 10 mitz 2007-08-21 07:19:16 PDT
Created attachment 16052 [details]
Use floating point arithmetic for max widths and add a cap
Comment 11 Darin Adler 2007-08-21 10:35:49 PDT
Comment on attachment 16052 [details]
Use floating point arithmetic for max widths and add a cap

r=me
Comment 12 Adele Peterson 2007-08-21 11:07:27 PDT
Committed revision 25171.