Blender crashes when dragging Material-Assets into the 3D Viewport #92501

New Issue

Marcel Freyer · 2021-10-26T15:24:06+02:00

Marcel Freyer commented

2021-10-26 15:24:06 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.13

Blender Version
Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-10-25 23:16, hash: 32cc9ff037
Worked: version: 3.0.0 Alpha, branch: master, commit date: 2021-10-23 20:02, hash: 8c21667f3c
Caused by e8027ec2a0

Short description of error

Blender will crash instantly, as soon as I drag the material asset from the asset browser over the boundry of the 3D viewport.
The crash happens exactly when the dragged material icon preview reaches the border to the 3d viewport, but not other editors / panels. If i drag it over other editors, blender doesn't crash.

Exact steps for others to reproduce the error

Open the asset browser on the left side of the 3d viewport;
Grab a material-asset from the asset browser and try to drag it to the right into the 3d viewport;
Blender will crash instantly wenn crossing the dividing line between the two panels.

Material Asset dragging crash - Marcel Freyer.blend

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.13 **Blender Version** Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-10-25 23:16, hash: `32cc9ff037` Worked: version: 3.0.0 Alpha, branch: master, commit date: 2021-10-23 20:02, hash: `8c21667f3c` Caused by e8027ec2a0 **Short description of error** Blender will crash instantly, as soon as I drag the material asset from the asset browser over the boundry of the 3D viewport. The crash happens exactly when the dragged material icon preview reaches the border to the 3d viewport, but not other editors / panels. If i drag it over other editors, blender doesn't crash. **Exact steps for others to reproduce the error** - Open the asset browser on the left side of the 3d viewport; - Grab a material-asset from the asset browser and try to drag it to the right into the 3d viewport; - Blender will crash instantly wenn crossing the dividing line between the two panels. ![Point of Crash.png](https://archive.blender.org/developer/F11523381/Point_of_Crash.png) ![Point of Crash marked.png](https://archive.blender.org/developer/F11523453/Point_of_Crash_marked.png) ![2021-10-26 15_21_46-Blender.png](https://archive.blender.org/developer/F11523497/2021-10-26_15_21_46-Blender.png) [Material Asset dragging crash - Marcel Freyer.blend](https://archive.blender.org/developer/F11523353/Material_Asset_dragging_crash_-_Marcel_Freyer.blend)

Marcel Freyer commented

2021-10-26 15:24:06 +02:00

Added subscriber: @WorldBuilder

blender-admin commented

2021-10-26 15:24:06 +02:00

#92690 was marked as duplicate of this issue

Julian Eisel commented

2021-10-26 18:13:45 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Martijn Versteegh commented

2021-10-27 00:36:43 +02:00

Added subscriber: @Baardaap

Martijn Versteegh commented

2021-10-27 00:36:43 +02:00

I bisected it to commit e8027ec2a0

UI Drag Drop: allow customizable drawing

I bisected it to commit e8027ec2a0cac4b0e92d51a64ccc40fd3f190a20 UI Drag Drop: allow customizable drawing

Martijn Versteegh commented

2021-10-27 00:38:15 +02:00

I don't have any time to look into it further (and I don't know anything about this code) I just bisected it because I had my bisecting setup ready to go.

Pratik Borhade commented

2021-11-01 07:15:05 +01:00

Added subscribers: @Alumx, @PratikPB2123, @deadpin

Dalai Felinto commented

2021-11-02 17:37:05 +01:00

Added subscriber: @dfelinto

Germano Cavalcante was assigned by Dalai Felinto

2021-11-02 17:37:05 +01:00

Dalai Felinto commented

2021-11-02 17:37:05 +01:00

Hi Germano, can you look at this? The issue was added in your commit.

Julian Eisel commented

2021-11-02 18:44:56 +01:00

Added subscribers: @mano-wii, @JulianEisel

Germano Cavalcante was unassigned by Julian Eisel

2021-11-02 18:44:56 +01:00

Julian Eisel self-assigned this 2021-11-02 18:44:56 +01:00

Julian Eisel commented

2021-11-02 18:44:56 +01:00

What happens is that the tooltip text is now received while drawing the drag feedback. But there is a mismatch between the context we use for this, and the context we use for polling if the drop-box and operator are available. So the polling may succeed, and then the tooltip callback executes logic with the rightful assumption that a poll was done in the current context, with context that doesn't actually match the polling.

Fixing the bug itself isn't that difficult. We could go back to generating the tooltip text from where we also execute the polling. Or we store the area & region from context during polling and restore that when drawing. However, we also have a custom draw-callback now, that may assume (also rightfully I think) a context matching the poll context. So I think we should properly restore context.
I'd propose this:

Store the area and region the dropbox and its operator were polled in, similar to wmTooltipState. Restore that context for drawing.
Optionally: Move either the tooltip or the disabled-hint generation to the same place. Currently the disabled hint is set when polling/activating, tooltips are generated when drawing. To move the disabled hint to the drawing would mean executing the operator poll again, like the regular button tooltip code does it.
Either remove wmDropBox.opcontext or ensure it's used to override context when drawing. Checked with Campbell, we seem to agree to remove it. Dropboxes are supposed to check and operate on the context under the mouse cursor anyway.

I have a patch for this, just needs some more cleanup.

What happens is that the tooltip text is now received while drawing the drag feedback. But there is a mismatch between the context we use for this, and the context we use for polling if the drop-box and operator are available. So the polling may succeed, and then the tooltip callback executes logic with the rightful assumption that a poll was done in the current context, with context that doesn't actually match the polling. Fixing the bug itself isn't that difficult. We could go back to generating the tooltip text from where we also execute the polling. Or we store the area & region from context during polling and restore that when drawing. However, we also have a custom draw-callback now, that may assume (also rightfully I think) a context matching the poll context. So I think we should properly restore context. I'd propose this: * Store the area and region the dropbox and its operator were polled in, similar to `wmTooltipState`. Restore that context for drawing. * Optionally: Move either the tooltip or the disabled-hint generation to the same place. Currently the disabled hint is set when polling/activating, tooltips are generated when drawing. To move the disabled hint to the drawing would mean executing the operator poll again, like the regular button tooltip code does it. * Either remove `wmDropBox.opcontext` or ensure it's used to override context when drawing. Checked with Campbell, we seem to agree to remove it. Dropboxes are supposed to check and operate on the context under the mouse cursor anyway. I have a patch for this, just needs some more cleanup.

Germano Cavalcante commented

2021-11-03 14:05:20 +01:00

On the points mentioned, I am tempted to the first point. This area and region could be used for both the tooltip and the operator.
Another point that could be added would be, - look for the correct region in the tooltip callback itself. If I'm not mistaken, only 2 callbacks require the region.
This was the direction chosen for D13076.

On the points mentioned, I am tempted to the first point. This area and region could be used for both the tooltip and the operator. Another point that could be added would be, `- look for the correct region in the tooltip callback itself`. If I'm not mistaken, only 2 callbacks require the region. This was the direction chosen for [D13076](https://archive.blender.org/developer/D13076).

Julian Eisel commented

2021-11-03 15:30:14 +01:00

I don't think we should do workarounds like looking up the region from the operator. The drag/drop system should ensure the correct context. The design of operators is to have them act on context.

I didn't mean my list to represent alternatives, but 3 things we should do together I think. While the first point is enough to fix this issue, it is not enough to ensure the same context for the drawing that used for the polling and operator execution.
P2570 does these things, without removing wmDropBox.opcontext, but using the operator context properly.

So, for the 3.0 branch I'd suggest just this to fix the crash:

Store the area and region the dropbox and its operator were polled in, similar to wmTooltipState. Restore that context for drawing.

Then in master, we can do the following in addition:

Move either the tooltip or the disabled-hint generation so both are in the same place.
Remove wmDropBox.opcontext (i.e. always invoke/execute in area & region context stored from the polling).

I don't think we should do workarounds like looking up the region from the operator. The drag/drop system should ensure the correct context. The design of operators is to have them act on context. I didn't mean my list to represent alternatives, but 3 things we should do together I think. While the first point is enough to fix this issue, it is not enough to ensure the same context for the drawing that used for the polling and operator execution. [P2570](https://archive.blender.org/developer/P2570.txt) does these things, without removing `wmDropBox.opcontext`, but using the operator context properly. ---- So, for the 3.0 branch I'd suggest just this to fix the crash: > Store the area and region the dropbox and its operator were polled in, similar to wmTooltipState. Restore that context for drawing. Then in master, we can do the following in addition: * Move either the tooltip or the disabled-hint generation so both are in the same place. * Remove `wmDropBox.opcontext` (i.e. always invoke/execute in area & region context stored from the polling).

blender-admin commented

2021-11-04 12:10:58 +01:00

This issue was referenced by 80a46955d8

This issue was referenced by 80a46955d8212f01b77215ab12d479d934e305f4

Julian Eisel commented

2021-11-04 12:25:39 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Julian Eisel closed this issue

2021-11-04 12:25:39 +01:00

Thomas Dinges added this to the 3.0 milestone 2023-02-08 15:58:48 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender crashes when dragging Material-Assets into the 3D Viewport #92501