Impossible to run Modal operator with simultaneously open props dialog (Blender crashes) #93478

New Issue

Andrei Tihonovschi · 2021-11-29T15:44:08+01:00

2021-11-29 15:44:08 +01:00

System Information
Operating system: Linux-5.15.4-x86_64-AMD_Ryzen_3_PRO_4350G_with_Radeon_Graphics-with-glibc2.33 64 Bits
Graphics card: AMD RENOIR (DRM 3.42.0, 5.15.4, LLVM 13.0.0) AMD 4.6 (Core Profile) Mesa 21.2.6

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: 84da05a8b8
2.93.6, 2.93.7, 3.0.0 and 3.1.0 all are broken.
Worked: (don't know)

Short description of error
Blender crashes while trying to display operator properties dialog (invoke_props_dialog) and add
the same operator as the modal handler (modal_handler_add(self))
I think it's the same problem as in the (closed) task blender/blender-addons#48196

Exact steps for others to reproduce the error
Try to invoke corresponding operator and then to return {'FINISHED'} or {'CANCELLED'} from the modal() handler.
Then blender crashes after pressing ESC or closing dialog.

Sample code:

import bpy

class TEST(bpy.types.Operator):
    bl_idname = "test.modal"
    bl_label = "test invoke props + modal"

    test: bpy.props.StringProperty(
        name="test",
        description="test",
        default=''
    )
    
    def draw(self, context):
        col = self.layout.column(align=True)
        col.prop(self, "test")

    def invoke(self, context, event):
        context.window_manager.invoke_props_dialog(self)
        context.window_manager.modal_handler_add(self)
        return {'RUNNING_MODAL'}
    
    def execute(self, context):
        return {'FINISHED'}

    def modal(self, context, event):
        if event.type in {'ESC'}:
            return {'CANCELLED'}
        return {'PASS_THROUGH'}

def register():
    bpy.utils.register_class(TEST)


def unregister():
    bpy.utils.unregister_class(TEST)

if __name__ == "__main__":
    register()

I think that impossibility of creating modal operators which can simultaneously have open properties
dialog for on-the-fly corrections lead to endless tries to create custom bgl-rendered UIs which is just
an unneeded overhead.

Please, review the mentioned bug, AFAIK it was already fixed but somehow reappeared upstream...

**System Information** Operating system: Linux-5.15.4-x86_64-AMD_Ryzen_3_PRO_4350G_with_Radeon_Graphics-with-glibc2.33 64 Bits Graphics card: AMD RENOIR (DRM 3.42.0, 5.15.4, LLVM 13.0.0) AMD 4.6 (Core Profile) Mesa 21.2.6 **Blender Version** Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: `84da05a8b8` 2.93.6, 2.93.7, 3.0.0 and 3.1.0 all are broken. Worked: (don't know) **Short description of error** Blender crashes while trying to display operator properties dialog (invoke_props_dialog) and add the same operator as the modal handler (modal_handler_add(self)) I think it's the same problem as in the (closed) task blender/blender-addons#48196 **Exact steps for others to reproduce the error** Try to invoke corresponding operator and then to return {'FINISHED'} or {'CANCELLED'} from the modal() handler. Then blender crashes after pressing ESC or closing dialog. Sample code: ```python import bpy class TEST(bpy.types.Operator): bl_idname = "test.modal" bl_label = "test invoke props + modal" test: bpy.props.StringProperty( name="test", description="test", default='' ) def draw(self, context): col = self.layout.column(align=True) col.prop(self, "test") def invoke(self, context, event): context.window_manager.invoke_props_dialog(self) context.window_manager.modal_handler_add(self) return {'RUNNING_MODAL'} def execute(self, context): return {'FINISHED'} def modal(self, context, event): if event.type in {'ESC'}: return {'CANCELLED'} return {'PASS_THROUGH'} def register(): bpy.utils.register_class(TEST) def unregister(): bpy.utils.unregister_class(TEST) if __name__ == "__main__": register() ``` I think that impossibility of creating modal operators which can simultaneously have open properties dialog for on-the-fly corrections lead to endless tries to create custom bgl-rendered UIs which is just an unneeded overhead. Please, review the mentioned bug, AFAIK it was already fixed but somehow reappeared upstream...

Andrei Tihonovschi commented

2021-11-29 15:44:08 +01:00

Added subscriber: @atgote

Germano Cavalcante commented

2021-12-01 16:21:10 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-12-01 16:21:10 +01:00

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

Germano Cavalcante commented

2021-12-01 16:21:10 +01:00

Thanks for the report, I can confirm the crash with the example operator.
But it doesn't seem to be conventional to use invoke_props_dialog and modal_handler_add in the same operator.
The two modal operations are performed at the same time and both can free the operator, causing the one trying to use the operator later to crash.

I don't know what is the point of running an operator along with a popup, maybe it's better to separate the two things (Menu and operator).

Thanks for the report, I can confirm the crash with the example operator. But it doesn't seem to be conventional to use `invoke_props_dialog` and `modal_handler_add` in the same operator. The two modal operations are performed at the same time and both can free the operator, causing the one trying to use the operator later to crash. I don't know what is the point of running an operator along with a popup, maybe it's better to separate the two things (Menu and operator).

Andrei Tihonovschi commented

2021-12-01 16:41:52 +01:00

Just as an example - choose a "modifier" from Enum field which influences the operator action - and user can check the result before finalizing the operator execution (somewhat like with Undo/Redo dialog)

But the idea behind my search was to use modal handler to improve UX when using the props dialog. That is to have dialog responding to keypresses like add or remove (filter) / UI elements (props).
Something alike searching for an operator with operator search dialog (F3) but a little bit more powerful, allowing not only list-search, but UI-elements 'filter' - different operator/presets buttons for example.
That is - user may enter some keystrokes to filter available actions and then press the operator button or may just find the button in the list and press it without using filtering at all.

Just as an example - choose a "modifier" from Enum field which influences the operator action - and user can check the result before finalizing the operator execution (somewhat like with Undo/Redo dialog) But the idea behind my search was to use modal handler to improve UX when using the props dialog. That is to have dialog responding to keypresses like add or remove (filter) / UI elements (props). Something alike searching for an operator with operator search dialog (F3) but a little bit more powerful, allowing not only list-search, but UI-elements 'filter' - different operator/presets buttons for example. That is - user may enter some keystrokes to filter available actions and then press the operator button or may just find the button in the list and press it without using filtering at all.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Impossible to run Modal operator with simultaneously open props dialog (Blender crashes) #93478