[FileTypes] Looper must be locked

[diver]

This is hrev45850.

FileTypes crashes with Looper must be locked message.

Launch FileTypes and click Preferred application menu. Without closing the menu click any unselected item in listview on the left.

[diver]

Backgrounds and MidiPlayer crashes with the same back trace. Probably a variant of #8689.

[jackburton]

Could you try with hrev46285 or later ?

[diver]

Still here in hrev46286.

[jackburton]

Ok I see, the menu should close when you click outside of its window. Might be a regression, since I remember it was working long ago. The crash shouldn't happen anyway, though, even if the menu was opened.

[diver]

BTW, probably the easiest way to reproduce this crash is to use MidiPlayer.

[jackburton]

Replying to jackburton:

Ok I see, the menu should close when you click outside of its window. Might be a regression, since I remember it was working long ago.

Seems the code was removed in commit 85c30aeccb4d4c0ac11c5bf46ff41ed48e5ec630:

Remove extraneous code with respect to telling a menu to close which was breaking various cases where menus coexisted in a window with a view which was using event masks:

• If one invoked the menu via, e.g. a BMenuField, and then tried to choo an item on it, the mouse down would get captured, the menu would be closed, and the mouse event would be thrown away without ever reaching the event mask view.

• Furthermore, since the menu was told to terminate early, it would dec that the user hadn't actually chosen that item (the escape key case), and never actually invoke it.

Fixes the menu fields in the mouse preflet being broken.

[diver]

Ok, so this was done in hrev43166.

[anevilyak]

I'm afraid I don't really have anything to add beyond what the commit message said. As stated, in the case of the mouse preflet, an event mask is used so that the preflet live updates when the user clicks mouse buttons, regardless of whether the preflet has focus or not. However, without the above changeset, attempting to select anything from the menu fields results in a no-op as described, i.e. the menu item never gets invoked. It'd seem some other means would need to be found to fix that issue without causing the current one, but as it is right now, I'd have no idea how to go about that, as I haven't touched the menu code at all in the intervening 2 years, and consequently don't really remember any of it, apart from it being quite convoluted/hairy.

[jackburton]

Maybe it could be solved by reintroducing that code in BWindow::DispatchMessage(), but instead of eating the B_MOUSE_DOWN message by returning, we could use it to close the menu, but then dispatch the message anyway. This way we would basically "emulate" the use of SetMouseEventMask() for BMenu. Worth a try.