Closed Bug 57483 Opened 23 years ago Closed 23 years ago

Scrollbar position hosed by insertion/removal above the visible area

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: hyatt, Assigned: hyatt)

References

Details

(Whiteboard: [rtm+]) 

When the tree widget is scrolled and content is inserted above the current
scrolled index, the scrollbar ends up being out of sync with the tree. This is
probably the primary source of FindPreviousRowContent crashes.
Whew.  This is it.  This is the source of most of the tree's sync problems with
the scrollbar.

Nominating for rtm and accepting.
Status: NEW → ASSIGNED
Keywords: rtm
Given that the crash has been plugged, now you'll just end up in a wacky
out-of-sync state.  This state can be recovered from by scrolling up to the top
though.
Blocks: 57139
rtm need info, getting into a whacky state as often as once per minute would be Bad.
Whiteboard: [rtm need info]
Target Milestone: --- → M18
Patch attached to 57139.

Patch attached to 57139.
No longer blocks: 57139
Shouldn't this bug depend on bug 57139, not block 57139?
Depends on: 57139
Summary: Scrollbar position hosed by ContentInserted → Scrollbar position hosed by insertion/removal above the visible area
Marking rtm+, since 57139 is now rtm+.
Whiteboard: [rtm need info] → [rtm+]
Whiteboard: [rtm+] → [rtm+] FIXED ON TRUNK
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: [rtm+] FIXED ON TRUNK → [rtm+]
I've been pumping batches of messages into the tree, in both threaded and 
unthreaded, sorted view I can't get the scrollbar to be out-of-synch in any 
practical scenario.**

(** there are two edge cases noted -- modulo bug 58435 and bug 58990)
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.