Crashes when giving part empty name

[haarp]

2.0.0

Repro:

• Have part
• Click on part name once, rename mode becomes active and selects the entire string
• Press del
• Click anywhere to apply the name change

-> PrusaSlicer will crash

Thank you!

PS, I'd also like to say that triggering a rename operation when single-clicking on a part name once is very bad usability. In 99.9% of all times I have another operation but renaming in mind when doing so.

[BeldrothTheGold]

Hello Haarp,

What operating system and version are you using?

### Operating system type + version

Also, I am not able to reproduce this crash on the latest commit on my system (Windows 10).

Also, on my system clicking on the name once only selects an item. I have to click again on the selected item in order to activate remaining.

[BeldrothTheGold]

Here is a quick GIF from my PC.

[haarp]

Hello,

oh sorry, I should've added that. I'm on Gentoo Linux under X11. Gentoo is a rolling release, so there are no versions. I compiled PS myself. Here's the printed BT:

ASSERT INFO:
/var/tmp/portage/media-gfx/prusa-slicer-2.0.0/work/PrusaSlicer-version_2.0.0/src/slic3r/GUI/wxExtensions.cpp(1424): assert "variant.GetType() == "DataViewBitmapText"" failed in operator<<().

BACKTRACE:
[1] operator<<(DataViewBitmapText&, wxVariant const&)
[2] wxDataViewRendererBase::FinishEditing()
[3] wxDataViewRenderer::FinishEditing()
[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[6] wxEvtHandler::TryHereOnly(wxEvent&)
[7] wxEvtHandler::ProcessEventLocally(wxEvent&)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[10] g_closure_invoke
[11] g_signal_emit_valist
[12] g_signal_emit
[13] gtk_window_propagate_key_event
[14] g_closure_invoke
[15] g_signal_emit_valist
[16] g_signal_emit
[17] gtk_main_do_event
[18] g_main_context_dispatch
[19] g_main_loop_run
[20] gtk_main
[21] wxGUIEventLoop::DoRun()
[22] wxEventLoopBase::Run()
[23] wxAppConsoleBase::MainLoop()
[24] wxEntry(int&, wchar_t**)
[25] Slic3r::CLI::run(int, char**)
[26] main
[27] __libc_start_main
[28] _start

And you're right, it only starts renaming on click when the item already was selected. But if it is, a single click will trigger it.

[bubnikv]

What wxWidgets and what GTK did you compile against?

[haarp]

What wxWidgets and what GTK did you compile against?

gtk+-3.24.8
wxGTK-3.0.4

[bubnikv]

Would you try to compile against gtk2? po 17. 6. 2019 v 13:12 odesílatel haarp <notifications@github.com> napsal:

…

What wxWidgets and what GTK did you compile against? gtk+-3.24.8 wxGTK-3.0.4 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2518?email_source=notifications&email_token=ABMPSI2FK2N57FKVLNVIVS3P25WS7A5CNFSM4HYPVZ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX22ZQY#issuecomment-502639811>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMPSI5UEMEY7MCS2BUEIE3P25WS7ANCNFSM4HYPVZ6A> .

[haarp]

Would you try to compile against gtk2?

Yes, I just did by configuring with -DSLIC3R_GTK=2. PS looks different, but still crashes with the same backtrace.

[pmjdebruijn]

I've just been hit by this on git master as well:

ASSERT INFO:
slic3r-prusa-2.3.0~377+gb6cd41d67/src/slic3r/GUI/ExtraRenderers.cpp(32): assert "variant.GetType() == "DataViewBitmapText"" failed in operator<<().

BACKTRACE:
[1] wxDataViewRendererBase::FinishEditing()
[2] wxDataViewRenderer::FinishEditing()
[3] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[4] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[5] wxEvtHandler::TryHereOnly(wxEvent&)
[6] wxEvtHandler::ProcessEventLocally(wxEvent&)
[7] wxEvtHandler::ProcessEvent(wxEvent&)
[8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[9] wxTextCtrl::GTKProcessEvent(wxEvent&) const
[10] wxWindow::GTKHandleFocusOutNoDeferring()
[11] wxWindow::GTKHandleFocusOut()
[12] g_closure_invoke
[13] g_signal_emit_valist
[14] g_signal_emit
[15] gtk_widget_send_focus_change
[16] g_cclosure_marshal_VOID__OBJECTv
[17] g_signal_emit_valist
[18] g_signal_emit
[19] g_signal_emit_valist
[20] g_signal_emit
[21] gtk_widget_grab_focus
[22] g_closure_invoke
[23] g_signal_emit_valist
[24] g_signal_emit
[25] gtk_cell_area_stop_editing
[26] g_signal_emit_valist
[27] g_signal_emit
[28] g_cclosure_marshal_VOID__BOXEDv
[29] g_signal_emit_valist
[30] g_signal_emit
[31] gtk_event_controller_handle_event
[32] g_closure_invoke
[33] g_signal_emit_valist
[34] g_signal_emit
[35] gtk_main_do_event
[36] g_main_context_dispatch
[37] g_main_loop_run
[38] gtk_main
[39] wxGUIEventLoop::DoRun()
[40] wxEventLoopBase::Run()
[41] wxAppConsoleBase::MainLoop()
[42] wxEntry(int&, wchar_t**)
[43] __libc_start_main

It's trivially reproducable on any wxGTK build that doesn't have asserts manually forced off.

[YuSanka]

It's trivially reproducable on any wxGTK build that doesn't have asserts manually forced off.

I have a build with a wxWidgets assertes allowed, but can't reproduce this issue

[pmjdebruijn]

Hey, I just rebuilt using wxGTK 3.1.4-patched, and the issue is indeed no longer reproducible.

So it seems this is a wxGTK 3.0.x specific issue.