bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort

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

On Sun, 10 Dec 2023 23:28:30 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The backtrace seems to say that there was some X error:
>>
>>   X protocol error: GLXBadWindow on protocol request 151
>>   Serial no: 4286
>>   Failing resource ID (if any): 0x3c001c5
>>   Minor code: 32
>>
>> I guess we now need to understand what window triggered the "bad
>> window" error and why?
>
> I've commented on precisely the same bug in the past; if someone can
> unearth that bug number, this bug ought to be merged with it.

Nothing to merge, it was this very bug:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg02680.html

> It boils down to how the WebKitGTK developers have elected to cease
> supporting off-screen windows, by presuming that every window holding a
> WebView widget is an X server window eligible for an OpenGL context.
> Emacs requires placing these widgets within offscreen windows managed by
> GTK, for each xwidget might be displayed in multiple distinct windows,
> and its contents must be captured and reproduced within all of them if
> that be the case.
>
> To put this another way, WebKitGTK doesn't support displaying a single
> widget more than once anymore.  There is another library designed for
> such use-cases as that of Emacs, based on the same WebKit library as
> WebKitGTK, by the name of WPE.  The solution to this bug, in my
> estimation, is rewriting xwidgets for that library... any volunteers?

But again, xwidget-webkit-browse-url does work with -q -xrm
"emacs.synchronous: true" but only when running emacs under gdb.  So if
someone can figure out why and how, I'd think it must be possible to get
it to work when running emacs by itself.

Steve Berman