Boris Zbarsky wrote: > Robert O'Callahan wrote: >> Actually I had it backwards; the problem is when the height after the >> first pass is too *large*, then we set the scrollbar maxpos to zero and >> scroll to the top of the listbox. See >> https://bugzilla.mozilla.org/show_bug.cgi?id=301439#c8. If you can avoid >> regressing that testcase, then I'm happy :-). > > Well. That testcase won't regress because it only does one-pass reflow > in the new world. A testcase that _would_ regress is one in which the > font-size is decreased at the same time as the "size" attribute is > increased. Then we'd do a first-pass reflow using the old font size and > the new "size" attribute, figure out that the size of our options has > changed, and do a second reflow at the right (smaller) size. > > Unfortunately, with the new setup we don't know until we're done with > the first reflow whether we'll have to do a second one... I suppose I > could always do two reflows, and the second one would always have to do > _some_ work because it'd need to update the scrollbars. But I'd really > like to avoid that if I can; it seems wasteful.
Yeah, definitely. Maybe you could have the nsSelectsAreaFrame detect whether a second reflow will be needed, before it returns from its reflow near the end of the first pass, and set up suppression from there if necessary. Rob _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
