[Webkit-unassigned] [Bug 29501] Wrong width calculation in table with fixed layout

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29501





--- Comment #5 from Beth Dakin <bdakin at apple.com>  2009-09-18 14:02:38 PDT ---
Dan and I talked about this a bunch on IRC. Let me summarize here. In my
debugging, I discovered that in this case, we can set the maxPrefWidth to
anything ridiculously large, and we will get the correct result. Basically, the
number is meaningless, it just needs to be Big Enough so it doesn't prevent
calculations later down the line. Logically speaking, it seems like we are
looking for the first container of the fixed table that has a non auto width,
and we want to use that as out arbitrarily-large  size. (I call this solution
firstNonAutoContainer.) However, for some reason this solution was always a few
pixels short for me. Very frustrating!! Here are our options as I see them:

1. Set maxPrefWidth to the value of the biggest container we have. 
2. Set it to some other constant BIG number. 
3. Add a bool or something that answers isMyMaxPrefWidthEvenMeaningful(). 
4. Figure out why firstNonAutoContainer is always a few pixels short. 
5. New approach

I am going to whip up 1, because it will be fast, and it is what I meant for
this patch to be all along. However, Dan pointed out that going with the size
of the view is overly simple. We can always refine this is we decide that one
of the other options is much better.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.