Log for #mozilla: 2003-04-05 (edited)
-------------------------------------
17:53 <@hyatt> jkeiser: how many regression tests does moz have for layout?
17:53 < jkeiser> lessee
17:53  * hyatt is curious how many more tests he has to write for safari before he ends up in the same ballpark
17:53 <@hyatt> safari is up to about 400 i think
17:54 < imajes> how many safari guys do you have?
17:54 <@hyatt> 7 or so
17:54 < biesi> hyatt: curious, are you working off a khtml branch, or on its trunk?
17:54 < jkeiser> hyatt: do you actually run them?  If you do, you are 100% better than we are since pretty much no one runs ours.
17:54 <@hyatt> biesi: branch
17:54 < imajes> jkeiser: oh, you are supposed to run tests?
17:54 <@hyatt> biesi: we work with the khtml guys and pass patches back and forth
17:54 <@hyatt> biesi: they've merged in stuff from us, and we've picked stuff up from them
17:55 <@hyatt> but we can't merge onto their trunk, because they're wide open right now and just breaking shit right and left
17:55 < jkeiser> hyatt: 1861, give or take a couple hundred
17:55 <@hyatt> they have a "fast and loose" policy right after releases that is (IMO) less than ideal
17:55 < biesi> hyatt: ah, I see
17:55 < imajes> hyatt: so there is some truth in saying how gelled small groups are then, as opposed to larger ones :)
17:56 < jkeiser> imajes: we have regression tests for layout that no one uses.  We REALLY need to get them integrated into tinderbox so people can look at the differences and such.
17:56 < imajes> hmm
17:56 < imajes> yes
17:56 <@bz> hyatt: note that 99% of the mozilla regression tests are quirks mode tests for crap
17:56 <@hyatt> imajes: safari could really use more people working on the engine
17:56 < bsmedberg> jkeiser: can you checkin 200709?
17:56 <@bz> hyatt: we have very few real CSS tests in the regression suite
17:56 <@hyatt> bz: so are a lot of safari's.
17:56 <@bz> hyatt: so could moz... ;)
17:56 < imajes> hyatt: can you guys hire more people?
17:56 < jkeiser> bsmedberg: yeah.  I am going to assume it compiles since my tree is in a state of disarray ;)
17:56 < bsmedberg> jkeiser: works for me on win32/linux
17:57 <@hyatt> imajes: i don't know that they understand how big a layotu engine is yet
17:57 <@bz> hyatt: and if running the regression tests were not a stinkin' mess, that would help.  ;)
17:57 < imajes> heh
17:57 < biesi> So in nsStyleStruct.h, is a property [reset] if and only if it's not [inherit]?
17:57  * bz wonders whether this plugin thing plans to fix it....
17:57 <@hyatt> bz: safari's regression test harness kicks ass
17:57 <@bz> biesi: yes
17:57 < biesi> bz: thanks
17:57 <@bz> hyatt: does it not need to open a new window every so often?
17:57 <@hyatt> bz: it runs them without launching the browser or displaying anything, so it's really fast
17:57 < smontagu> bz: that's weird, I don't have all of harish' changes even though I pulled twice since he made them
17:57  * fantasai remembers running regression tests, and running into sooo many false positives
17:57 <@bz> hyatt: that's the #1 annoyance of moz's
17:57 <@hyatt> bz: it only opens a browser window if you have failures
17:57 <@bz> hyatt: that it closes the window and opens a new one multiple times partway through the tests
17:57 <@hyatt> bz: and our tests deliver *no* false positives
17:58 <@hyatt> bz: our frame geometry is perfectly consistent
17:58 <@bz> hyatt: sweet.
17:58  * bz considers switching browsers.... ;)
17:58 <@hyatt> bz: we also dump "layer" (in gecko terms, view) information
17:58 <@hyatt> bz: and we cluster "renderobject" subtrees by "layer"
17:58 <@bz> hyatt: makes sense
17:58 <@hyatt> and dump the layers in sorted zindex order
17:58 <@hyatt> along with their clipping rects for both overflow-clip and clip
17:58 <@hyatt> so the view system gets tested too
17:59 <@hyatt> things we don't test adequately via the regression tests are text-decoration (difficult to dump info for)
17:59 <@hyatt> and border drawing
17:59 <@hyatt> Mac IE apparently has a harness that actually compared bitmaps
18:00 <@hyatt> which is kind of interesting
18:00 <@hyatt> so it will literally detect any difference
18:00 < jkeiser> hyatt: niice.
18:00  * hyatt thinks doing both is cool
18:00 <@hyatt> the mozilla/safari style is much easier to understand
18:00 <@hyatt> when you have an error
18:01 < jkeiser> I don't like the bitmap thing so much (though it detects color errors), but I like the fact that you get consistent results with such a wide range of tests
18:01  * jkeiser thinks it would be a nice idea to have a drive to get ourselves into that state
18:02 <@hyatt> why doesn't moz yield consistent results?
18:02 <@hyatt> is it frame geometry that's inconsistent?
18:02 < jkeiser> I am not sure.  And I am not sure if anyone has investigated.
18:02 < sicking> incremental reflow?
18:02 <@hyatt> it doesn't really make sense that you'd get inconsistent results
18:02 < jkeiser> I can't see why we would have an inconsistent frame geometry--it always *ought* to end up with the same set of frames
18:02 <@hyatt> yeah
18:03 <@bz> hyatt: inconsistent results mean incremental reflow does not match initial areflow....
18:03 <@hyatt> i mean, khtml has the same timing issue of reflowing every so often etc.
18:03 < sicking> tables takes some shortcuts during incremental reflow
18:03 <@bz> right
18:03 <@hyatt> khtml uses a dirty bit system
18:03 <@hyatt> so there's no such thing as incremental reflow
18:03 <@bz> hmm?
18:03 < jkeiser> sicking: meaning that tables are wrong?
18:03 <@hyatt> you just do a reflow and relayout the dirty objects
18:03 < jkeiser> hyatt: explain, this is interesting :)
18:04 < jkeiser> oh, ok
18:04 <@hyatt> jkeiser: it's just like XUL
18:04 < sicking> jkeiser: bascially yes
18:04 <@hyatt> khtml has XUL's layout system
18:04 <@hyatt> you compute min and max intrinsic sizes
18:04 <@bz> jkeiser: meaning that tables take some undecidable situations and may decide differently depending on initial conditions
18:04 <@hyatt> in a separate pass
18:04 <@hyatt> and then you lay things out
18:04 <@hyatt> in another pass
18:04  * bz notes that this is what dbaron wants to move toward in gecko...
18:04 <@hyatt> and when things need reflow you mark objects as dirty
18:04 <@hyatt> it's exactly like XUL
18:05 <@hyatt> (XUL is grosser because it was bolted on to Gecko's HTML reflow model)
18:05 <@hyatt> (but XUL would be this clean if it could be)
18:05 <@hyatt> bz: it makes layotu so much simpler to understand and read
18:05 <@hyatt> bz: when elements have min and max intrinsic sizes
18:05 < sicking> so when does khtml get XUL?
18:05 <@kerz> thank god the roadmap says we're getting rid of xul
18:05 <@hyatt> kerz: lol
18:05 < sicking> or at least box-layout?
18:06 <@hyatt> it would literally take about 2 days to do all of box-layout in KHTML
18:06 < sicking> nice
18:06 <@hyatt> the system is perfectly set up for it
18:06 <@bz> yeah, if it has min/max/pref sizes that's about all you need.
18:07 <@hyatt> bz: tables were a real bitch though 
18:07 <@hyatt> bz: to try to do "intrinsic size" computations with
18:07 <@hyatt> bz: it gets kind of strange
18:07 < jkeiser> It seems like we could get closer to that even within our current arch by separating out max element width computation and some of these other computations into their own methods
18:07 <@hyatt> the maxwidth ends up having to be different depending on what encloses the table
18:07 < jkeiser> And just call them from within Reflow
18:07 < jkeiser> hyatt: erm?  The maxwidth of the table depends on its parent?
18:08  * jkeiser does not grok why
18:08 <@hyatt> jkeiser: auto width tables
18:08 <@hyatt> they have different maxwidths depending on what encloses them
18:08 <@hyatt> it's freaky
18:08  * jkeiser goes to read up on this
18:08 < sicking> nested tables doesn't make any sense
18:08 <@hyatt> yes, it's nonsensical
18:08 <@hyatt> it's "emulate win ie and ns 4"
18:08 < sicking> unfortunatly neither for browserhacker nor webdevelopers
18:09 < sicking> but noone can do anything about it because of "existing content"
18:09  * hyatt reverse engineered the table width distirbution algorithm for auto width tables
18:09 <@hyatt> and now we match WinIE perfectly
18:09 <@bz> jkeiser: dbaron was working on that too (separating out into separate methods)
18:09 < jkeiser> hyatt: an example?  What situation would a table have different maxwidth depending on its container?
18:09 <@hyatt> it was actually fairly simple... just hard to deduce from examples
18:09 < jkeiser> bz: was or is?
18:09 <@hyatt> jkeiser:
18:09 <@bz> hyatt: "you sure?  ;) "
18:09 <@hyatt> here's an example
18:09 <@hyatt> first look at this example:
18:09 <@hyatt> <table>
18:09 < jkeiser> bz: I was thinking of just splitting out max element width as an experiment
18:09 <@hyatt> <tr><td width=50%>a<td>Hello<td width=50%>c</tr></table>
18:09 <@bz> jkeiser: check with him; I dunno what state the work is in
18:10 <@bz> hyatt: how about a more interesting example?
18:10 <@hyatt> that table will fill the width of your browser window basically
18:10 <@hyatt> the above table
18:10 <@hyatt> now take that same table
18:10 <@hyatt> and put it inside
18:10 <@hyatt> <table><tr><td>
18:10 <@hyatt> suddenly it won't.
18:11 <@bz> hyatt: <table width="100"><tr><td width="50%"></td><td width="30"></td><td width="60%></td><td width="50"></tr>
18:11 <@bz> <tr><td colspan="3" width="10%"><td width="70"></tr>
18:11 <@hyatt> now you're getting into overconstrained tables
18:12 <@bz> <tr><td width="20"></td><td colspan="3" width="30%"></tr></table>
18:12 <@hyatt> tables suck
18:12 <@bz> hyatt: yeah, true
18:12 <@hyatt> what sucks about them is that you have to match WinIE or you're "buggy"
18:12 <@bz> hyatt: but in 90% of the cases I've seen out there tables are in fact overconstrained, and incorrectly
18:12 <@bz> yep
18:12 <@hyatt> even though nearly every table on the web is ambiguous
18:12  * bz agrees with hyatt
18:13 <@bz> let's not start on heights of table cells that have colspans...
18:13 < sicking> hyatt: btw, how much effort would it take to map between kthmls element-names (which are just an int iirc) and mozillas atom+namespaceid?
18:13  * sicking ponders what he is actually asking
18:13 <@hyatt> why does that matter, sicking?
18:14 < sicking> hyatt: well.. i've been somewhat looking at porting transformiix to khtml, and the biggest obstacle is (soon) that transformiix uses atoms
18:14 < jkeiser> hyatt: this sounds very much like the css rule for auto width rather than a max element width problem ... basically it says that if you have a percentage width child and the parent is auto, your width becomes auto too
18:15 <@hyatt> only that isn't what happens.
18:15 <@hyatt> there are two types of maxwidths
18:15 < jkeiser> when I just tried it (maybe my browser is bad) then <td>'s suddenly shrunk to auto size
18:15 <@hyatt> there's maxwidths where percentage cells affect the maxwidth (scaled via a multiplier of their intrinsic max width by the percent)
18:15 < jkeiser> when I wrapped the thing in a table
18:15 <@hyatt> and maxwidths where they don't.
18:16 < jkeiser> hmm
18:16 <@hyatt> ok, maybe that is right
18:16 <@hyatt> to call it "auto"
18:16 <@hyatt> hmmm.
18:16 <@hyatt> explain that rule to me again.
18:16 <@hyatt> maybe i can simplify my code.
18:16 < sicking> heh
18:17 < jkeiser> let me find the rule, 1s
18:17 <@hyatt> it's sitll not auto though
18:17 <@hyatt> the percents still affect teh widths of cells
18:18 <@hyatt> take the example i gave above
18:18 <@hyatt> and change the 50s to 100s
18:18 <@hyatt> and you'll see what i mean
18:18 <@hyatt> the overal lwidth of the nested table is the intrinsic max width of the three cells
18:18 <@hyatt> but the first cell gets all teh space!
18:18 <@hyatt> because of its 100%
18:18 <@hyatt> so even though you computed the width of the table as though the percents weren't there
18:18 <@hyatt> the actual layout had to lay out as though they were
18:19 < jkeiser> hyatt: they're the same in Mozilla (/me tests IE)
18:19 <@bz> Phear
18:19 <@bz> Phear the tables
18:19 < jkeiser> hyatt: 50%'s and 100%'s are the same in Mozilla and IE--they are "auto" (shrink to fit)
18:19 < jkeiser> hyatt: at least when we wrap the whole thing in another table
18:20 < sicking> the question is, who do we blame for this mess? Microsoft or netscape?
18:20 < jhermans> and the users still expect the output to be exactly the same in all browsers ...
18:20 < sicking> who copied who?
18:20 <@hyatt> jkeiser: 
18:20 <@hyatt> http://www.mozillazine.org/weblogs/hyatt/archives/tables.html/test.html
18:20 <@hyatt> check that out
18:21 <@bz> sicking: msft copied NS4
18:21 <@hyatt> in the second table.
18:21 <@hyatt> the small one.
18:21 <@hyatt> note how cell a is wider than cell c.
18:21 <@bz> sicking: but then we have pages on which ns4 crashes and msft does "something"
18:21 <@bz> sicking: fun? ;)
18:21 < sicking> bz: it must have been before that
18:21 <@bz> sicking: s/4/3/, maybe
18:21 <@bz> sicking: but table layout did not change much from 3 to 4
18:21 < sicking> bz: yeah, that sounds better
18:21 < sicking> bz: right, and havn't since :)
18:22 <@bz> um
18:22 <@bz> so..............
18:22  * bz looks at cvs blame for this crap
18:23  * jkeiser tries to figure out why hyatt's does that and his doesn't
18:23 <@hyatt> jkeiser: what versio nof mozilla you using?
18:23 <@hyatt> jkeiser: what do you see?
18:24 < jkeiser> hyatt: 1.4 ... yours has extra space in the first cell of the second table, but my testcase doesn't, and I haven't figured out the difference between them yet
18:25 <@bz> hmm
18:25 <@bz> does -moz-user-input inherit?
18:26 <@hyatt> jkeiser: you probably have width=100% on your outer table
18:26 <@hyatt> jkeiser: that would be a guess
18:27 < jkeiser> hyatt: nope.  The problem was the space in yours.  It only does this (in Mozilla) when the second cell takes up two lines.
18:28 <@hyatt> jkeiser: the width of that table is the intrinsic max width of the cells
18:28 <@hyatt> jkeiser: but the first cell will still get all the space
18:28 <@hyatt> jkeiser: try putting a bunch of text inside the second cell.  it's pretty funny.
18:30 <@bz> s/nsAString/nsACString/
18:31 < jkeiser> hyatt: oh, I see.  That is so freaking messed up.
18:31 <@hyatt> jkeiser: yup.
18:32 < jkeiser> hyatt: but why don't a and c get equal share in this again?
18:32 <@hyatt> jkeiser: you only have 100% of space as far as tables are concerned
18:32 <@hyatt> you go from left to right, and once you run out of percents, you're done
18:32 <@hyatt> so the first cell gets 100/100
18:32 < jkeiser> hyatt: oh, I grok.  It doesn't redistribute percentages evenly
18:32 <@hyatt> now you have 0/100 percent remaining
18:33  * hyatt thinks it would have made more sense to normalize
18:33 <@hyatt> but oh well
18:33 <@hyatt> GO NETSCAPE 1.1
18:33 <@hyatt> rofl
18:37 < jkeiser> hyatt: ok, max element width of the <td>'s (and even of the <table>) appears to be calculated the same in all these cases though.  It's just that the <body> reflow isn't asking for 100% width--it's asking for desired size given the body's width.  It's the <table><tr><td> that is asking for the max element width and using it, which is what it's supposed to do.
18:48 < jkeiser> hyatt: it's just that for <table>, desired size can be bigger than max element size :)  Maybe the <table> desired size is the right place for the quirk:
18:48 < jkeiser> (1) take the max element width of all non-percent-width td's;
18:49 < jkeiser> (2) assign percentage width td's the proper widths to make them that percentage width in the finished table;
18:49 < jkeiser> (3) shrink everything properly to make the table fit into the desired size (this is where the first-person-gets-the-space rule occurs);
18:49 < jkeiser> (4) give all td's that desired size
18:49  * jkeiser suspects he just described the algorithm that css prescribes
19:01  * jkeiser wonders how a xul-based layout deals with inline frames
19:02 < jkeiser> no, display: inline
19:02 <@hyatt> jkeiser: inlines in KHTML have no min/max width
19:02 <@hyatt> jkeiser: inline flow elements don't.
19:02 < jkeiser> hyatt: what happens to get them to create multiple boxes?  You ask them for desired size and they do what they need?
19:03 <@hyatt> jkeiser: those boxes are created during layout
19:03  * glazou_sickHome wants hyatt to finally implement the <element> element
19:03 <@hyatt> computing the max width for a block with inline kids is pretty insanely complicated
19:03 <@hyatt> heh
19:04 <@hyatt> because of whitespace
19:04 <@hyatt> pre, nowrap, etc. and possible mixtures
19:04 < glazou_sickHome> hyatt: nice 1st of april blog entry btw
19:04 <@hyatt> thx
19:05 < jkeiser> hyatt: ohhh, the size calculations and layout steps are separate.  I totally had overlooked that.
19:05 <@hyatt> yes.
19:05 < jkeiser> I still wonder how desired size gets calculated without at least a virtual layout step.
19:05 <@hyatt> not sure what you mean.
19:06 <@hyatt> text gets measured sure.
19:06 <@hyatt> it's like a vastly simplified layout
19:06 < jkeiser> yeah, you basically have to do the same measurement twice in cases where the final size turns out to be the same as desired size
19:06 <@hyatt> yes.
19:06 <@hyatt> you do more measuring
19:07 <@hyatt> note that KHTML doesn't compute min/max intrinsic heights
19:07 <@hyatt> just doest his for widths
19:07 <@hyatt> height is all done during layout
19:07 <@hyatt> since margin collapsing has to be done
19:07 <@hyatt> and that involves having to lay out because of floats
19:08 < jkeiser> hmm.  I can see how you could optimize the multiple-measurement if you wanted though.
19:08 <@hyatt> yes.
19:08 < jkeiser> And it is quite simple.
19:08  * jkeiser is more converted
19:08 <@hyatt> it makes the table code especially eas yto understand
19:08 <@hyatt> since you can then cache min/max intrinsic widths for clumns
19:08 <@hyatt> columns
19:09 <@hyatt> some layout operations become very fast
19:09 <@hyatt> e.g., you just lay out columns at their max widths if possible
19:09 <@hyatt> well, it isn't so much faster as jus teasier to read i guess
19:09 < jkeiser> which is a huge plus :)
19:10  * hyatt remembers when evaughan kept arguing passionately with troy about this and getting nowhere
19:10 <@hyatt> and troy kept responding and removing me from the cc list
19:10 <@hyatt> because he wanted to complain at evaughan in private
19:10 <@hyatt> or something
19:10 <@hyatt> it was funny
19:10 < jkeiser> hahaha
19:10 <@hyatt> evaufghan kept putting me back on the ccc list
19:10 <@hyatt> lol
19:11 < jkeiser> hyatt: I don't think there's anyone left who would really passionately defend the current reflow system on its technical merits :)
19:12 <@hyatt> jkeiser: :)
19:12 <@hyatt> safari's layout is much less optimized and easily twice as fast as gecko's
19:12 <@hyatt> i still don't understand that
19:12 <@hyatt> (safari's style system is much slower though)
19:12 <@smfr> no xpcom overhead?
19:12 <@hyatt> (which i do understand)
19:12 <@hyatt> i can't believe it would just be xpcom
19:13 <@hyatt> no, i think it's just thet the layout system in gecko sucks
19:13 < sicking> speed though good arch is infinetly better then speed through optimization
19:13 <@hyatt> the actual Reflow stuff in Gecko and actual layout of objects is just not very well done i think
19:13 <@hyatt> (mostly because of early bad architectural decisions)
19:14 <@hyatt> it's like the only part of gecko that didn't get a rewrite of some kind. :)
19:14 <@hyatt> so the poor thing is old.
19:14 < jkeiser> and it's the part in the most need of one now :)
19:14 <@hyatt> and creaky.
19:14 < sicking> when code gets so complicated that you can't keep track of the whole thing you always end up wasting tons of cycles, which spirals to more complicated code