User-Agent: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre First appeared in: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre Probably caused by bug 564991 Reproducible: Always Steps to Reproduce: 1. Open the testcase in the URL field 2. Move/Drag the frames' borders around Actual Results: The borders are sometimes not redrawn properly. Expected Results: The borders are drawn correctly.

Another way to reproduce this bug: 1. Open the testcase in the URL field 2. Resize the window

Does this still happen?

(In reply to comment #3) > Does this still happen? Yes, pretty minor. Best way to get it is to: 1) open test case 2) drag the vertical line out a few inches 3) drag the horizontal line down an inch while pulling the mouse to the right a bit. You'll get a corrupt vertical line sometimes.

Yeah, I can see it now.

I see this on Linux too. I wonder if the display items for the frameset borders are reporting the correct bounds. (I presume they have their own display items, though maybe not.)

They do, but a cursory code inspection looks OK.

This is, in fact, not a regression from retained layers. It also happens on the 2010-07-15 nightly.

OK, here's the source of the bug. When we're scrolling the vertical border to the right, we set mColSizes which is in app units here: <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrameSetFrame.cpp#1470>, and then we set the cols attribute on the content node based on the result. We convert the dimensions into percentage values here: <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrameSetFrame.cpp#630>. At the second stage of the test, when dragging down the horizontal border, we get a reflow on the topmost frameset element, which brings us here: <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrameSetFrame.cpp#988>, which causes us to attempt to calculate the app unit values from the percentage values, which causes the vertical border to "jump" a little bit to the right. The thing to note here is that mDrag.mActive is false, because the drag operation is happening on a child frameset, so we redo the width calculation when we don't really have to. This is actually a very old behavior which has been broken for a long time. Do we *really* want to block 2.0 on this?

No. But we'd take a patch now that you've debugged it! :-)

After playing with this a bit more, I finally have a patch which I'm happy with. This patch effectively defers the calculation of the width/height to the time when we reflow, instead of relying on the drag handler's calculations to be in sync with what we end up doing after reflow. I also wrote a test which triggers this bug before the patch being applied. And as a final bonus, the patch only removes code. ;-)

Comment on attachment 507039 [details] [diff] [review] Patch (v1) Lovely