GNU bug report logs - #31371
26.1; [macOS] Menu-bar stops working after search

Previous Next

Full log

View this message in rfc822 format

From: Nick Helm <nick <at> tenpoint.co.nz>
To: Alan Third <alan <at> idiocy.org>
Cc: 31371 <at> debbugs.gnu.org
Subject: bug#31371: 26.1; Menu-bar stops working after search
Date: Sun, 13 May 2018 22:09:06 +1200

[Message part 1 (text/plain, inline)]

I think I've worked out what's going on here. I've attached a patch -
could you give it a try and see if works for you? 

When the user types in the search field, NSMenu looks for matching
candidates by creating events to open each menu, trigger an update and
read the results. If the search field already contains text, this
happens as soon as the Help menu opens, either when the user clicks Help
or mouse drags onto the Help menu. 

The code in ns_check_menu_open and ns_check_pending_open_menu that
postpones mouse clicks (to fetch menus from Lisp) also tries to postpone
these drag and search events. When it releases a delayed click on Help
(even if the event wasn't a click to begin with), the menu reopens and
the process loops.

The attached patch gets around this by never postponing mouse drag or
non-user mouse down events.

[31371.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

On Wed, 09 May 2018 at 09:40:24 +1200, Alan Third wrote:

> I notice all this code is cocoa only, though. Makes me wonder why
> GNUstep is different. (The menus on GNUstep Emacs are awful, though,
> they flicker constantly.)

I think Cocoa uses a delegate method to update single submenus which
(I've read) isn't supported on GNUStep. This means ns_update_menubar has
to recreate every menu on every call (deep_p is always 1). Maybe that
has something to do with it?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.