bug#60210: 30.0.50; tab-bar height not recalculated when face changes

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 01 Jan 2023 21:50:56 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 60210@debbugs.gnu.org, juri@linkov.net
> 
> 
> >> The bug is that, in redisplay_tab_bar, WINDOW_PIXEL_HEIGHT (w) uses the 
> >> height of the default face, which is 39 pixels, whereas new_height, 
> >> which is computed with tab_bar_height, uses the font of the tab-bar 
> >> face (variable-pitch in emacs -Q).  On my system, new_height is (with a 
> >> single *scratch* tab) 36 pixels.  Therefore new_height < 
> >> WINDOW_PIXEL_HEIGHT (w), when in fact according to the logic of the 
> >> code we should have new_height == WINDOW_PIXEL_HEIGHT (w).
> >
> > I'm not sure I understand how the above causes the tab bar not to be 
> > displayed, or become empty.  AFAIU, it just means the frame's 
> > change_tab_bar_height_hook will be called.  What did I miss?
> >
> 
> I do not fully understand it either yet.  A simpler recipe, which does not 
> involve changing fonts:
> 
> (set-face-attribute 'tab-bar nil :height 0.5)
> (tab-bar-mode 1)
> 
> This should display a tiny tab-bar, it displays a white bar instead.
> 
> In redisplay_tab_bar, new_height is set to half the height of a canonical 
> line (17 and 34 on my system).  Therefore redisplay_tab_bar returns true. 
> The next redisplay cycle finds that WINDOW_TOTAL_LINES (w) == 0, and does 
> nothing.

Ah, if WINDOW_TOTAL_LINES becomes zero, that will indeed explain the
problem.  We should prevent that from happening as long as the tab bar
is turned on.