User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5 Using DOM methods to change the style of a float that is located in an element with 'overflow: auto' or 'overflow: scroll' can change the size of that element, causing it to reflow text and possibly add scrollbars. The particular style property being changed seems irrelevant, and setting the style to a value it already has is just as bad. Despite seeming innocuous, I think this reflects some deeper problem that is worth exploring. And I'm three layers deep in bug workarounds, and now this one is standing in my way. Besides, the test case it clear... :) Test case follows. Reproducible: Always Steps to Reproduce:

I'm seeing the slight resize but not the scrollbar issue with linux trunk build 2003-02-17-08.

Boris -- Thanks for looking. The scrollbars only appear if the page is a particular size. That particular size is a little hard to specify, and might be font specific. For me, it happens if I resize the window so that I have 5 lines of text, having respectively 9, 6, 6, 6, and 3 words. Like this: -------------------------------------------------- | * * text text text text text text text text text | |text text text text text text [ float 1 ] | |text text text text text text [ float 2 ] | |text text text text text text | |text text text | -------------------------------------------------- Note that you must always reload after the resize, even if you have not yet used the buttons to do anything with the styles. If you fail to get the scrollbars, either fiddle around with the size (always reloading) or just take my word for it.

Here's another test case that points out the problem a more dramatically. At least, I think it's a test case of the same bug. It might be a very similar bug instead, or perhaps the parent bug of the one I first reported. In this case, the style property is being set on an unrelated element, causing the floats to move around and stomp on other content. I was going to report this as a separate bug, but I'll just leave it with this one unless anyone suggests otherwise.

Perhaps a general incremental reflow bug not related to floats? (Otherwise likely to be dependent on bug 186593.

> Perhaps a general incremental reflow bug not related to floats? I've continued playing around with the second test case, and so far as I can tell, this bug is related to floats. I only see a problem if there are two floats positioned vertically next to one another. The problem is not that a reflow occurs, but that the floats are not positioned the same the second time as they are the first. And the second time is definitely more wrong than the first. > (Otherwise likely to be dependent on bug 186593. You know a lot more about that bug than I do, but based on the summary and discussion in that bug I don't think the two are related. That bug has to do with element widths, but everything I've seen here has to do with vertical positioning. That summary mentions only "right" floats, while this problem is the same for right and left floats. Based on fiddling with the parameters in the "dramatic" test case, I think: 1) The problem relates to multiple vertically consecutive floats. 2) The problem occurs only with "overflow: auto" or "overflow: scroll". Would you like more test cases? What can I do to help someone with this? If I were to start stepping through with gdb, what is the relevant code? (This bug is a roadblock to the project I'm working on---so I'm eager to help to fix it or at least understand it well enough to come up with a workaround)

I think I now have a test case that might provide someone more knowledgeable about the code with a solid working lead. This test case shows that when the floats move, it is downward by the height of the first float, which to me suggests some sort of list index problem in the code (first item is being counted twice). As interesting variations on this test case, it might be useful to know that very different behaviour is seen if the padding of the float is specified as a percentage (try 10%). It's also to me surprising that if the DIV has "overflow: hidden" the floats are hidden. Hope this helps.

I think this is a duplicate of bug 177331, but I'm not sure why background changes were causing reflow at all.

Perhaps bug 171830 caused us to stop reflowing in this case?

This testcase still shows the bug after bug 171830 landed.

This was the same problem as bug 177331 and is now fixed. *** This bug has been marked as a duplicate of 177331 ***