bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget script dialog

[Lars Ingebrigtsen <larsi@gnus.org>]

Po Lu <luangruo@yahoo.com> writes:

> That's weird, because video works here.  Does it work in another
> WebKitGTK based browser, like Epiphany, on your Debian system?  Thanks.

I tried Epiphany now, and it works there.  That is, it plays the mp4
very slowly, but it does play it.  In the xwidget, it just puts up the
controls, and then nothing happens.  (This happens with `M-x
xwidget-webkit-browse-url', too, so it's not just this way of creating
the xwidgets that's stopping the mp4s from working.)

> Unfortunately I don't know enough about macOS to solve the problem here.
>
> But try removing this snippet of x_draw_xwidget_glyph_string:

Yes, indeed, that fixed it, so I now have basic <video> support working
in eww.  😹  But only on Macos.

>   /* On X11, this keeps generating expose events.  */
> #ifndef USE_GTK
>   /* Resize xwidget webkit if its container window size is changed in
>      some ways, for example, a buffer became hidden in small split
>      window, then it can appear front in merged whole window.  */
>   if (EQ (xww->type, Qwebkit)
>       && (xww->width != text_area_width || xww->height != text_area_height))
>     {
>       Lisp_Object xwl;
>       XSETXWIDGET (xwl, xww);
>       Fxwidget_resize (xwl,
>                        make_int (text_area_width),
>                        make_int (text_area_height));
>     }
> #endif

I'm not that familiar with the xwidget.c code...  but that's just always
maximalising the widget to be as big as the Emacs window?  That can't be
correct, surely.  Should I just remove it?  It doesn't seem to lead to
any regressions in xwidget-webkit-browse-url, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no