bug#59351: 29.0.50; [PATCH] Fix mouse click position to menu bar entry

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: luangruo@yahoo.com,  59351@debbugs.gnu.org
> Date: Wed, 23 Nov 2022 17:43:39 +0100
> 
> This last step goes into this compute_line_metrics call.  Everything
> seems fine up to xdisp.c:22886.  Before this conditional, I have the
> following values:
> 
> --8<---------------cut here---------------start------------->8---
> row->y = 0
> row->height = 31
> row->visible_height = 31
> max_y = 13
> --8<---------------cut here---------------end--------------->8---
> 
> And so after it, row->visible_height becomes 13.  So maybe that is why
> the menu bar is not update to have more height here.  WDYT?

Why do you think row->visible_height plays any role in this?  Maybe I'm
missing something, but it looks like it has nothing to do with the
non-resizing of the menu bar.  It looks like we never actually supported
this situation.  Think about it: in the no-toolkit build, the menu bar is
just a window.  A special kind of window, but a window nonetheless.  And
when a font changes, the dimensions of the window only change if we force
that, it isn't automatic.  If we don't force resizing, we keep the window at
its dimensions and redisplay the text inside, so fewer or more lines of text
will be visible in the window.

And that is what happens here: we just take note that the menu bar will be
partially visible, but don't do anything to resize the menu-bar window.

What I think we need to do is something like this:

  /* Compute the total height of the lines.  */
  compute_line_metrics (&it);
  if (FRAME_WINDOW_P (it.f))
    {
      struct glyph_row *row = it.glyph_row;
      if (row->y + row->height > WINDOW_BOX_HEIGHT_NO_MODE_LINE (w))
        {
          FRAME_MENU_BAR_HEIGHT (it.f) = it.row->height;
          it.f->fonts_changed = true;
        }
    }

I hope that setting the frame's fonts_changed flag will cause Emacs resize
the menu-bar window.  You should see a call to adjust_frame_glyphs from
redisplay_internal; if that doesn't happen, perhaps we should force such a
call right after display_menu_bar returns.  Can you try this?