Opened 12 months ago
Closed 11 months ago
#18707 closed bug (fixed)
IOM crashes (possibly BListView::MouseMoved())
Reported by: | humdinger | Owned by: | jscipione |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta5 |
Component: | Kits/Interface Kit | Version: | R1/Development |
Keywords: | Cc: | jscipione | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev57439, 64bit.
Today I experienced many crashes with Icon-O-Matic. A week or so ago I worked with IOM for long stretches of time without any crashes. As the first crash appeared to be similar to #18702, I suspected that the fix to WebKit mentioned by PulkoMandy, may not be limited to WebKit. But I got a few different crashes as well (see attached debug reports). It seems to revolve around BListView's MouseMoved().
The recent commit "BListView: Update selection on mouse down and mouse up" could be a candidate...
Attachments (4)
Change History (16)
by , 12 months ago
Attachment: | Icon-O-Matic-6235-debug-08-12-2023-17-35-11.report added |
---|
by , 12 months ago
Attachment: | Icon-O-Matic-6556-debug-08-12-2023-17-44-11.report added |
---|
by , 12 months ago
Attachment: | Icon-O-Matic-6631-debug-08-12-2023-17-45-08.report added |
---|
by , 12 months ago
Attachment: | Icon-O-Matic-6816-debug-08-12-2023-17-49-44.report added |
---|
comment:1 by , 12 months ago
Cc: | added |
---|
comment:2 by , 12 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Priority: | normal → blocker |
comment:3 by , 12 months ago
This has to be caused by hrev57439 but where are the non-draggable single selection list views in Icon-O-Matic? All the ones I can see have draggable items in them, and thus shouldn't be triggering auto-scroll.
comment:5 by , 11 months ago
Can't we revert that change, while we look for a fix? This causes lots of troubles
comment:6 by , 11 months ago
I suppose we could but I am still unable to reproduce the crash on my end. I suspect that Icon-O-Matic is implementing its own version of auto-scroll and that is interfering with the one in list view.
What perplexes me is that these list views are all draggable and I should be handling that case in list view and skipping the auto-scroll.
It seems like Icon-O-Matic is always the app that these kinds of issues pop up in. Likewise for my BTextView changes I needed to create a special case for Icon-O-Matic.
comment:7 by , 11 months ago
Owner: | changed from | to
---|---|
Status: | new → in-progress |
comment:8 by , 11 months ago
I can reproduce.
Steps to reproduce bug:
- Open Icon-O-Matic
- Create enough Empty Shape objects so that the list is scrollable.
- Drag a Shape
Icon-O-Matic will immediately crash.
DragSortableList::InitiateDrag() => SimpleListView::MakeDragMessage() => ShapeListView::ArchiveSelection() => crash
First crash report (6325) and third (6631) has to do with improper use of GetMouse() in Icon-O-Matic while scrolling. It specifically says "You shouldn't use this function to track the mouse" in the BeBook under BView::GetMouse(). I believe this may be a bug in Icon-O-Matic, and I'm not sure how this relates to hrev57439 at this point.
comment:9 by , 11 months ago
https://review.haiku-os.org/c/haiku/+/7215/1
My solution to solving these crashes is to update BListView to turn scrolling on for draggable multi-select views like the Shapes list, take the auto-scrolling code out of Icon-O-Matic, and scroll using BListView instead. The drawing of alternating background color, and the red drop indicator has been preserved.
GetMouse() calls have been removed from the auto-scrolling code as it can be problematic.
A more thorough fix would included exposing enough scrolling information from BListView to apps so that they could implement their own scrolling properly.
comment:11 by , 11 months ago
Hold on, I should have said that hrev57476 fixes _some_ of the crashes in Icon-O-Matic, there are still some more fixed by https://review.haiku-os.org/c/haiku/+/7215 and WonderBrush unfortunaly still crashes in other places as well.
comment:12 by , 11 months ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
Other patch merged in hrev57495.
Appears ScrollTo is calling MouseMoved which results in a loop. Looks like a regression from behavioral change indeed. CC jscipione.