The emacs package used to have support for xwidgets. However, it was discovered that the library necessary for this feature, webkit2gtk, above a certain version, would make Emacs crash. Because the maximum version which Emacs would accept to build with was below the version that nixpkgs has packaged for webkit2gtk, this feature has been disabled in nixpkgs.
However, recently upstream Emacs has re-enabled webkit2gtk above the threshold version, fixing the crashes. Hence, I think there is no reason to hold back the xwidgets feature. As a proof of concept, I have built the latest emacs (using the emacs overlay), with the xwidgets feature turned on and the broken flag overridden. Here is a screenshot of it, used with typst preview:
Hi, I am one of Nixpkgs Emacs maintainers and I am aware of that commit. Actually, it is me who tells you that commit in the matrix room.
I did plan to remove the xwidgets restriction from Nixpkgs. However, in my experiments, it did not seem to work: it just showed a blank screen after I evaluated (xwidget-webkit-browse-url "http://httpforever.com/"):
Yes, that happened to me too. Pressing g, then RET seems to make it work. Iâm not sure why it doesnât work âout of the boxâ, but this shouldnât be blocking for nixpkgs.
I have further experimented with xwidgets and page loading, and arrived at the following conclusion: during the first 4/5 seconds, calls to xwidget-webkit-goto-uri (which is the low-level function that interfaces with the C library) wonât âgo throughâ, in that nothing happens when they are called. Adding a 5 second timer works consistently for me:
I have explained the situation on the Emacs devel mailing list, as I donât really know how to debug the C side of this: I am not at all familiar with the C part of Emacsâ codebase, but by looking at the implementation of xwidget-webkit-goto-uri, I have the impression that it pretty much just forwards the call to the webkit gtk library, so if I had to guess Iâd say the issue is in that library.
Currently nixpkgs doesnât seem to have the latest version of webkit gtk, maybe updating that would solve the issue?
I also asked the question on the matrix chan of webkit gtk (#webkitgtk:matrix.org if you want to join), but they donât seem to have an answer yet either.
After discussing about it with the Emacs developer who worked on xwidgets (Dirk-Jan Binnema), it appears that the issue is opening the about:blank page on widget creation, on PGTK builds. Hence, the following patch works:
--- a/src/xwidget.c
+++ b/src/xwidget.c
@@ -362,8 +362,12 @@
"download-started",
G_CALLBACK (webkit_download_cb), xw);
+#if !defined HAVE_PGTK
+ /* when using pgtk, the about:blank workaround is not needed
+ would in fact make the initial load fail. */
webkit_web_view_load_uri (WEBKIT_WEB_VIEW (xw->widget_osr),
"about:blank");
+#endif
/* webkitgtk uses GSubprocess which sets sigaction causing
Emacs to not catch SIGCHLD with its usual handle setup in
'catch_child_signal'. This resets the SIGCHLD sigaction. */
I have tested it locally and it works for me. Iâm unsure what I should do with this patch: Dirk said they didnât apply this path upstream because they donât know whether this will break with older webgtk versions. I see several possibilities:
I could open a PR to add this patch in nixpkgs, while waiting for upstream fix, but this might break some configurations other than mine, which I cannot test
I could add this patch somewhere in the documentation, so that if someone else has this issue they can easily fix it, but otherwise we donât break anyoneâs setup
I could wait for the upstream fix to happen, which should happen in the near future, as this is a known bug fix to a known bug.
@linj do you have insight on what might be the most useful thing to do?
Itâs an upstream bug. When in doubt, donât patch upstream bugs downstream if theyâre not security relevant; nixpkgs is not the place to maintain upstream projects.
You could add it as a hint somewhere in the wiki, but I donât think thatâs actually useful; itâs an emacs bug and has nothing to do with nix/NixOS. Anyone else running into this should find your emails on the emacs mailing list, thatâs where emacs bugs are detailed (or this thread via a search engine).
Personally I would just patch it downstream in my config if I wanted it fixed now, though tbh given you have an easy enough workaround itâs probably easier to just hit g for now, not worth having to recompile emacs on every update.
Iâm happy that I have the choice, now. I guess Iâll use the patched version whenever I need to play around with xwidgets (as doing development with a bugged version is somewhat painful), and the workaround version for my everyday life.
After discussing about it with the Emacs developer who worked on xwidgets (Dirk-Jan Binnema)
To me, Emacs developers means people who have write access to Emacs git repo or authored many Emacs patches. I would consider Dirk-Jan Binnema an Emacs contributor, not an Emacs developer.
Iâm unsure what I should do with this patch
Letâs give the discussion some more time to allow Emacs developers familiar with that part to chime in. After a fix is installed in upstream Emacs, we can consider cherry-picking the fix. In the meantime, this post can serve as some documentation. Of course, it is also helpful to add something to the wiki.
