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.
blocking2.0: --- → ?
Version: unspecified → Trunk
Another way to reproduce this bug: 1. Open the testcase in the URL field 2. Resize the window
Summary: Frame borders are sometimes not redrawn correctly after dragging them → Frame borders are sometimes not redrawn correctly after dragging them or resizing the window
blocking2.0: ? → final+
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.)
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [softblocker] → [softblocker][retainedlayers]
They do, but a cursory code inspection looks OK.
Assignee: jmathies → ehsan
This is, in fact, not a regression from retained layers. It also happens on the 2010-07-15 nightly.
No longer blocks: 564991
Whiteboard: [softblocker][retainedlayers] → [softblocker]
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! :-)
blocking2.0: final+ → -
Created attachment 507039 [details] [diff] [review] Patch (v1) 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
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
You need to log in before you can comment on or make changes to this bug.