Scrollbars are not fully and consistently drawn, painted

VERIFIED FIXED

Status

VERIFIED FIXED
13 years ago
13 years ago

People

(Reporter: bugzilla, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
xul:scroll (up/down arrows on the scrollbar) and sometimes xul:slider are not re-drawn, painted.
Sometimes, I'd say that the scrollbar XUL components are drawn but drawn rather late. So, when switching to a tab which may not have entirely finished loading will have the display behavior of rendering incomplete scrollbars and having "phantom" elements from other tab.

I have not found a way to reproduce this bug consistently, reliably. Sometimes, switching to another tab or loading a group of tab will trigger the bug.

The good news is that I did not notice such problem occuring in 20060306 and 20060307 nightly builds. Also, bug 329917 is certainly somewhat confirming that there is some kind of layout problem involving painting the interface. 

Seamonkey 1.5a rv:1.9a1 build 2006030808 under XP Pro SP2 here.
(Reporter)

Comment 1

13 years ago
Created attachment 214594 [details]
Screenshot of XUL slider not refreshed but redrawn over previous one

Here's my interpretation of this screenshot, taken while using build 2006030808.

The new XUL:slider is not entirely redrawn, painted; we can still see the previous XUL:slider. As we move the XUL:thumb, the XUL:slider is being redrawn appropriately. The "previous" XUL:slider is/origins from another tab.
(Reporter)

Comment 2

13 years ago
After several tries, I'm able to enumerate conditions under which the bug can be reproduced.

1- load a few urls into a group of tab
2- then switch from a loading tab into another loading tab
3- scroll down (dragging the XUL:slider or clicking the down XUL:scroll) while the tab is still being drawn, frames being constructed
4- switch back to previous tab

Actual results: parts of the scrollbar (slider or thumb or scroll) will not be redrawn, will not be painted appropriately, according to the current tab. Some area of the scrollbar will be transparent, otherwise will show the painting areas of the scrollbar of the previous tab and not the correct paint of the scrollbar of the current tab.

CONFIRMING

There maybe other ways to reproduce the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

13 years ago
> http://forums.mozillazine.org/viewtopic.php?p=2134634#2134634
> http://forums.mozillazine.org/viewtopic.php?p=2136786#2136786

http://img223.imageshack.us/img223/2827/scroll9wn.jpg
 
Thank you for bringing this up, pal. The up/down arrows (triangles) at top/bottom of scrollbar are called/programmatically referred as xul:scroll.

Because bug 329917 has been fixed today, we should check if this bug is still happening in tomorrow's build.

Cheers!

Comment 5

13 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060309 Firefox/1.6a1 ID:2006030919 (non-cairo/hourly)

seems to be fixed with/by checkin of bug#329917.
(Reporter)

Comment 6

13 years ago
> seems to be fixed with/by checkin of bug#329917.

Resolving as FIXED due to checking in bug 329917 

Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-02-09, SeaMonkey trunk on Windows XP.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.