ghost form control drawn when scrolling

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
8 years ago
4 years ago

People

(Reporter: tnikkel, Assigned: tnikkel)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(2 attachments)

(Assignee)

Description

8 years ago
Created attachment 472190 [details]
screenshot

Set general.smoothScroll to true. The bug exists without smooth scrolling, but is more intermittent. Login to bugzilla (needed so we get form controls). Visit a bug page, say https://bugzilla.mozilla.org/show_bug.cgi?id=590302 . Scroll down so that status1.9.1 dropdown is out of view. Slowly scroll back up using the arrow keys (other ways of scrolling also work, but arrow keys are more reliable). I get a down arrow button of a drop down drawn near the bottom of the page below the status1.9.1 drop down.

Doesn't happen on Linux or Windows 7.

Regressed on nightlies when retained layers landed.

Seems similar to some other retained layers bugs, but this one is easily reproducible.
(Assignee)

Updated

8 years ago
blocking2.0: --- → ?
Assignee: nobody → roc
blocking2.0: ? → betaN+
(Assignee)

Comment 1

8 years ago
Created attachment 481424 [details]
semi-reduced testcase

Reducing this further would be helpful.
(Assignee)

Comment 2

8 years ago
We update the scroll pos at last paint for a scroll frame when we call BuildDisplayList on it. I wonder if that is too early or too late and causing this bug?
(Assignee)

Comment 3

8 years ago
Delaying it doesn't seem to help.
(Assignee)

Updated

8 years ago
Assignee: roc → tnikkel
(Assignee)

Comment 4

8 years ago
This only happens for the classic theme. The Windows functions we call to draw native widgets for the classic theme (like DrawFrameControl) don't take a dirty or clip rect, just the rect of the widget, so we rely on the clip on the HDC so that we don't draw parts we don't want. This would produce incorrect results with retained layers because we use a circular buffer. Even if I set the clip on the gfxContext to a 0x0 rect before DrawFrameControl is called the control still seems to be drawn. So maybe something is going wrong when cairo_win32_get_dc_with_clip tries to set the clip on the HDC, or maybe DrawFrameControl doesn't respect the clip on the HDC?
cairo_win32_get_dc_with_clip being broken seems more likely than DrawFrameControl not respecting the the clip. However, you should be able to check what the clip is set to before the call to DrawFrameControl and make sure it's sane.
(Assignee)

Comment 6

8 years ago
Is there an easy way check what the clip is on an HDC?
(In reply to comment #6)
> Is there an easy way check what the clip is on an HDC?

Yep. You can use GetClipBox or GetClipRgn.
If the ClipBox is insufficient you probably want to use GetClipRgn and then GetRegionData to get at the rectangles.
(Assignee)

Comment 8

8 years ago
This bug happens quite easily on Linux for me when scrolling a select that has focus. Previously I thought it was Windows classic only.
 Timothy, still able to repro? (I don't have Linux/WinXP for checking).
Flags: needinfo?(tnikkel)
(Assignee)

Comment 10

4 years ago
I don't use Linux or Windows regularly anymore so I can't say.
Flags: needinfo?(tnikkel)
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.