bug#60817: 28.2; `x-focus-frame' causes spurious input events causes edebug not showing intermediate results

[Farblos via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On 2023-01-15  07:23, Eli Zaretskii wrote:

> AFAIU, input-pending-p should filter out focus events, so I don't
> think I understand why you see this.  Can you try this in Emacs 29 or
> the master branch of the Emacs Git repository, so we make sure this
> problem was not fixed already?  If it still happens in those newer
> versions, maybe you can step with GDB through get_input_pending, when
> it's called from input-pending-p, and through readable_events called
> by get_input_pending, and see why focus events aren't filtered out?

I used printf debugging and, admittedly, even back in Emacs 27 for now, 
since I have the Debian toolchain ready for that.  I reduced the test 
case to this:

(defun testcase ()
   (interactive)
   (message "pre: %S" (input-pending-p))
   (x-focus-frame (selected-frame))
   (sleep-for 0.5)
   (message "pst: %S" (input-pending-p)))

The error ("pst: t") reproduces only after touching some part of the 
modeline that provides a tooltip.

And the offending event that causes `input-pending-p' to become t is 
*not* a focus event (I can see indeed these getting filtered in 
readable_events) but rather a HELP_EVENT.  So as soon as one has touched 
the modeline, the call to `x-focus-frame' produces these HELP_EVENTS.

Does that ring a bell?  Any new directions where I should look at?

I'll try setting up a build environment for a newer Emacs when I find 
the time to do so.