GNU bug report logs - #51674
29.0.50; [PATCH] Fix hang when displaying xwidget script dialog

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51674 in the body.
You can then email your comments to 51674 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Fix hang when displaying xwidget script dialog
Date: Mon, 08 Nov 2021 10:10:44 +0800

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

Thanks!

[0001-Fix-hang-when-displaying-xwidget-script-dialog.patch (text/x-patch, attachment)]

Message #8 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 06:24:41 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Thanks!

Thanks; pushed to Emacs 29.

This reminds me of a totally different thing that I was poking at
briefly some years back -- is it possible to use xwidgets "freely" in a
different buffer these days?  Last time I looked at it, it was very much
tied to a specific mode, and only one widget per buffer.

My use case here is that I'd love to see eww being able to display video
clips.  xwidget can show <video> elements just fine, but it'd be great
to have them directly in the eww buffer (and perhaps several playing at
the same time, etc).

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

Message #13 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 13:38:53 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> This reminds me of a totally different thing that I was poking at
> briefly some years back -- is it possible to use xwidgets "freely" in a
> different buffer these days?  Last time I looked at it, it was very much
> tied to a specific mode, and only one widget per buffer.

You can show multiple widgets in one buffer today, which wasn't the
situation a couple of years back.

> My use case here is that I'd love to see eww being able to display video
> clips.  xwidget can show <video> elements just fine, but it'd be great
> to have them directly in the eww buffer (and perhaps several playing at
> the same time, etc).

It should work, but take care that the _same_ xwidget is never displayed
on-screen in more than one place at any given time.  If it is, then one
of the xwidget views will not display.

This is a known problem that I'm trying to resolve, it will probably be
a temporary limitation.  Thanks.

Message #16 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 06:40:45 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> You can show multiple widgets in one buffer today, which wasn't the
> situation a couple of years back.

Great!  What's the function to insert an xwidget at point in a buffer?

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

Message #19 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 13:45:04 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Great!  What's the function to insert an xwidget at point in a buffer?

`xwidget-insert', but I get the feeling it's an API intended to be
private to xwidget-webkit-mode.  I don't know, as I wasn't the author
of most of the user facing xwidget-webkit-mode code.

What I would do instead is to use `make-xwidget' to create an xwidget,
and then to make it the display property of a piece of text, like one
would an image spec.

Thanks.

Message #22 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 07:25:43 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> What I would do instead is to use `make-xwidget' to create an xwidget,
> and then to make it the display property of a piece of text, like one
> would an image spec.

Thanks; this works, sort of:

(progn
  (require 'xwidget)
  (setq widget (make-xwidget 'webkit
			     "Video"
			     700
			     500
			     nil
			     (current-buffer)
			     (xwidget-webkit-current-session)))
  (insert
   (propertize
    "[video]"
    'display (list 'xwidget :xwidget widget)))
  (xwidget-put widget 'callback #'always))

And then

(xwidget-webkit-goto-uri widget "file:///tmp/vid.html")

will play the .mp4 video...  but only on Macos.  On this Debian laptop,
it just shows the controls, and doesn't play the mp4.  Is this due to
platform specific limitations?  (It won't play Youtube, either, with the
normal `xwidget-webkit-browse-url'.)

But on Macos there's a different twist: It doesn't heed the width/height
specs, and always maximises itself to fill the frame.  Which seems like
a bug.

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

Message #25 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 14:29:51 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> (progn
>   (require 'xwidget)
>   (setq widget (make-xwidget 'webkit
> 			     "Video"
> 			     700
> 			     500
> 			     nil
> 			     (current-buffer)
> 			     (xwidget-webkit-current-session)))
>   (insert
>    (propertize
>     "[video]"
>     'display (list 'xwidget :xwidget widget)))
>   (xwidget-put widget 'callback #'always))

> (xwidget-webkit-goto-uri widget "file:///tmp/vid.html")

> will play the .mp4 video...  but only on Macos.  On this Debian laptop,
> it just shows the controls, and doesn't play the mp4.  Is this due to
> platform specific limitations?  (It won't play Youtube, either, with the
> normal `xwidget-webkit-browse-url'.)

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

> But on Macos there's a different twist: It doesn't heed the width/height
> specs, and always maximises itself to fill the frame.  Which seems like
> a bug.

Unfortunately I don't know enough about macOS to solve the problem here.

But try removing this snippet of x_draw_xwidget_glyph_string:


  /* 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

Message #28 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 07:50:54 +0100

Po Lu <luangruo <at> 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

Message #31 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 14:56:43 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> 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.)

Can you test the xwidget support using self-built WebKitGTK with
`-DENABLE_GL=NO' added to your cmake options?

You can follow the instructions here: https://trac.webkit.org/wiki/BuildingGtk.

Afterwards, you can add the path to the library into your
LD_LIBRARY_PATH, and start Emacs that way.

Thanks a lot!

> 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.

Yes, you should remove it.  I suspect that code was originally added to
work around the resizing bug I fixed in bug#51679.  Thanks.

Message #34 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Mon, 08 Nov 2021 08:01:58 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Can you test the xwidget support using self-built WebKitGTK with
> `-DENABLE_GL=NO' added to your cmake options?
>
> You can follow the instructions here: https://trac.webkit.org/wiki/BuildingGtk.
>
> Afterwards, you can add the path to the library into your
> LD_LIBRARY_PATH, and start Emacs that way.
>
> Thanks a lot!

OK; I'll try that (but probably tomorrow).

> Yes, you should remove it.  I suspect that code was originally added to
> work around the resizing bug I fixed in bug#51679.  Thanks.

Ah, I see.  OK, now removed.

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

Message #37 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 12:31:51 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> OK; I'll try that (but probably tomorrow).

BTW, I also see this issue on WebKitGTK 3.34.1 from Fedora, and one of
the developers said it seemed like a regression to him, so I reported a
bug here:

  https://bugs.webkit.org/show_bug.cgi?id=232860

Message #40 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 05:45:04 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Can you test the xwidget support using self-built WebKitGTK with
> `-DENABLE_GL=NO' added to your cmake options?
>
> You can follow the instructions here: https://trac.webkit.org/wiki/BuildingGtk.

It finally finished building.  I built from the development (git)
sources...

> Afterwards, you can add the path to the library into your
> LD_LIBRARY_PATH, and start Emacs that way.
>
> Thanks a lot!

... but the recipe for that doesn't have any instructions on how to
install it.  Should I have used a release tarball instead, perhaps?

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

Message #43 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 05:45:39 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> BTW, I also see this issue on WebKitGTK 3.34.1 from Fedora, and one of
> the developers said it seemed like a regression to him, so I reported a
> bug here:
>
>   https://bugs.webkit.org/show_bug.cgi?id=232860

Ah, OK, then I won't try to debug this further.  😀

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

Message #46 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 12:59:23 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Ah, OK, then I won't try to debug this further.  😀

Yes, and also thanks for all the work you've been doing.  Once the
WebKitGTK problems are resolved, I'm really looking forward to native
video playback in Emacs.

Message #49 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 06:30:22 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Yes, and also thanks for all the work you've been doing.  Once the
> WebKitGTK problems are resolved, I'm really looking forward to native
> video playback in Emacs.

I've now added support for this.  Try

(setq shr-use-xwidgets-for-media t)

and use eww to look at a web page with a <video> tag.  It works!  😀
But not on Debian/bullseye.  ☹️  So I've been testing this on Macos, and
it's totally smooth there, as far as I can tell.  (But I've only tested
on a couple of different pages.)

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

Message #52 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 06:34:29 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> and use eww to look at a web page with a <video> tag.  It works!  😀
> But not on Debian/bullseye.  ☹️  So I've been testing this on Macos, and
> it's totally smooth there, as far as I can tell.  (But I've only tested
> on a couple of different pages.)

It currently creates a temporary file, and I'd like to avoid that.  I
thought about using xwidget-webkit-execute-script to do something like

document.append("<video...>")

but I guess I need to open a "empty" page first?  (I haven't actually
tried.)  Do you have any advice here?

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

Message #55 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 13:46:02 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> It currently creates a temporary file, and I'd like to avoid that.  I
> thought about using xwidget-webkit-execute-script to do something like
>
> document.append("<video...>")
>
> but I guess I need to open a "empty" page first?  (I haven't actually
> tried.)  Do you have any advice here?

I think the cleaner solution would be to introduce a function that wraps
`webkit_web_view_load_html', but since the eww code also has to support
macOS, someone here who knows his way around that system will have to
implement it as well.

Also, the WebKit widget loads "about:blank" by default, as long as
RELATED is nil when passed to make-xwidget (this is necessary due to how
WebKit treats related widgets internally), so you shouldn't have to load
an empty page first.

WDYT?

Message #58 received at 51674 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51674 <at> debbugs.gnu.org
Subject: Re: bug#51674: 29.0.50; [PATCH] Fix hang when displaying xwidget
 script dialog
Date: Tue, 09 Nov 2021 07:10:36 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Also, the WebKit widget loads "about:blank" by default, as long as
> RELATED is nil when passed to make-xwidget (this is necessary due to how
> WebKit treats related widgets internally), so you shouldn't have to load
> an empty page first.

Yup; works perfectly.  😀

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

Previous Next

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