Closed Bug 579767 Opened 9 years ago Closed 9 years ago

Frame borders are sometimes not redrawn correctly after dragging them or resizing the window

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b11
Tracking Status
blocking2.0 --- -

People

(Reporter: andreasjunghw, Assigned: ehsan)

References

()

Details

(Keywords: polish, regression)

Attachments

(2 files)

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.
Blocks: 564991
blocking2.0: --- → ?
Keywords: regression
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
Assignee: nobody → jmathies
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: polish
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.
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]
Whiteboard: [softblocker] → [softblocker][retainedlayers]
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.
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+ → -
Attached patch Patch (v1)Splinter Review
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.  ;-)
Attachment #507039 - Flags: review?(roc)
Attachment #507039 - Flags: approval2.0?
Comment on attachment 507039 [details] [diff] [review]
Patch (v1)

Lovely
Attachment #507039 - Flags: review?(roc)
Attachment #507039 - Flags: review+
Attachment #507039 - Flags: approval2.0?
Attachment #507039 - Flags: approval2.0+
http://hg.mozilla.org/mozilla-central/rev/6e590b267675
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
You need to log in before you can comment on or make changes to this bug.