When you are laying out bugzilla pages sometimes in the middle of page layout sometimes you will get the flash of a scrollbar in the upper left hand corner before it is sent to its final destination.
The patch I've attached does two things: 1. Doesn't set the visibility on the scrolling view until after the initial reflow takes place. 2. Creates the scrollbars in the view hidden by default. Since they will be properly shown when someone calls ComputeScrollOffsets() this is safe.
Looks good to me. However, you should call nsIViewManager::SetViewVisibility instead of nsIView::SetVisibility, which doesn't necessarily repaint what needs to be repainted. (Yes, it's almost always wrong for layout to call nsIView::SetVisibility, and I'm trying to fix this elsewhere :-).) Modulo that, r=roc+moz
I'm not seeing this anymore. Possibly because of the checkin for bug 112525? bugzilla looks fine - no flashing scrollbars that I see.
Works For Me.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
I lied. It's still around.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This looks like a duplicate of bug 37040... Well, what about the patch if this is still around? The possible duplicate also has a (very old) patch... Is this bug really only for Linux? I thought I saw this also on Win2k... (other bug??) At least today I definitely saw a scrollbar flash in the upper left corner on a bugzilla page. I did not see this very often during the last months. Maybe its reappearance is related to the Paint Timeout reduction (bug 180241)?
I definitely saw this when I was using Win98 on a slower computer.
OS: Linux → All
roc, is this still present after your recent crop of scrollbar fixes?
I think this has gone now.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.