[Interface Kit] BMenu 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.

[ttcoder]

Dang, today we've found a new way to trigger this, without even clicking on the widget at all.

dsuden got this sc a few times today when typing text in a BTextControl which I have coded to also interact with a BMenuField::SetValue() et al. Didn't see that crash myself but Dane swears it occurs without clicking on the menufield itself, so logically it can only be menufield.SetValue() which calls the menu tracking (which I consider a bug-on-top-of-this-bug) and the menu tracking thread in turns trips the BView::_CheckLock() assertion.

Tentatively giving this better visibility with a priority bump, though I understand cleaning up the menu code represents dozens or hundreds of hours of work, and no quick fix seems in sight at this point.

[ttcoder]

CheckLock() crash, presumably in our BMenuField (without having clicked it!)

[anevilyak]

(In #11587) Duplicate of #9863.

[donn]

This happens to me in Network Preferences, fresh install of hrev48472, when I select <choose automatically> on the wifi interface to display the list of network names. Same list is not fatal to deskbar network.

[pulkomandy]

This was fixed in hrev48043, at least for the original problem. Network Preferences is still a problem.

[diver]

FileTypes still crashes the same way though.

[pulkomandy]

Fixed Network in hrev48511 (with some flickering).

[pulkomandy]

I could not reproduce the FileTypes crash here at first try. I did now and the fix in hrev48511 should work as well since it's the same backtrace.

[ttcoder]

Looks like you're gonna be dsuden's hero; notifying him to try the new hrev.