Closed Bug 57483 Opened 24 years ago Closed 24 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: 24 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.