Comment 26 for bug 327863

Created attachment 372174
WIP patch part 2: set visibility:collapse on scrollbars and check for that before letting the theme specify borders for 'em

Ok, here's the patch that attempts to fix this bug. It seems to work, but it's doing enough dodgy stuff that I'm not sure it's the *right* fix. It has a bunch of debugging code in it whose output is meant to be read along with the reflow trace report (GECKO_DISPLAY_REFLOW_RULES_FILE).

The ultimate cause of the problem is that some, but not all, Gtk themes specify a one-pixel widget border for their scrollbars. This is recorded in the reflow state by nsCSSOffsetState::InitOffsets, which is totally ignorant of whether the scrollbar in question has been allotted any space! This causes an assertion in nsPresShell::DoReflow to fire before we even get to calling the frame reflow method ("reflow state computed incorrect width"). It then goes on to derange the desiredSize that comes back from the frame reflow method (even with roc's original suggestion), and boom.

My fix for this is to set visibility:collapse on the anonymous content element associated with the scrollbar, and check that in nsCSSOffsetState::InitOffsets, but as I say, this feels kinda dodgy. But it works on tn's test case. (Reftest run still in progress.) Abusing r/sr to ask both roc and dbaron to look at it ;-) (Obviously any checked in version would remove all the debugging printfs.)