C-v hangs cl-webkit view

[Ambrevar]

With cl-webkit 79ad41996a1bd7fc8e53fe8d168e8f2030603b14, pressing "C-v" in a web view input field hangs the window (it can only be force-killed).

Also see https://github.com/atlas-engineer/next/issues/593.

I can only reproduce this issue on February 2020 Quickdist.

With Guix which hash its own versioning of Common Lisp libraries, the issue does not happen. cl-webkit is at the same commit, however cl-cffi-gtk is at commit 29443c5aaca975709df8025c4649366d882033cb.

Any clue what could be wrong?

If not cl-cffi-gtk, maybe another library?

[Ambrevar]

Friendly ping! ;) Any idea what could be wrong?

[Ferada]

No idea, plus right now I'm not able to load it up successfully, in CCL I get type errors and in SBCL I get complaints because nibbles doesn't load.

[Ambrevar]

To load what?

[Ferada]

next; I can get cl-webkit2 loaded, but I'm guessing that's not enough to reproduce the issue.

[Ambrevar]

Actually yes, cl-webkit2 is enough. If you use the demo that's included in the repo, then C-v.

Can you report the issue you get when building Next?
I'll try to fix it; Next should build quite easily these days.

(It builds but does not start on CCL for some reason -- use SBCL for Next).

[Ferada]

Actually yes, cl-webkit2 is enough. If you use the demo that's included in the repo, then C-v.

Right, if you navigate to a page with a text field first. Yeah, looks like it freezes on SBCL, have you noticed that that only happens though when nothing's in the copy buffer? Like, copying something with C-c first and then pasting seems to not freeze it and it continues to work fine.

In any case, since there's basically nothing in the source of cl-webkit2 I'd be guessing looking at the source of WebKit / WebKitGTK would be more productive.

Trying to find anything via gdb is of course as fruitless as ever, at least that's my experience.

Can you report the issue you get when building Next?

This is what I had to change to make next/gtk load on latest CCL for me, library versions aren't in sync with Quicklisp, so dunno if something's different there:

diff --git a/libraries/hooks/hooks.lisp b/libraries/hooks/hooks.lisp
index 929cc9da..5d87889e 100644
--- a/libraries/hooks/hooks.lisp
+++ b/libraries/hooks/hooks.lisp
@@ -76,7 +76,7 @@ (defclass handler ()
 The handler function.  It can be an anonymous function.")
    (handler-type :initarg :handler-type
                  :accessor handler-type
-                 :type list
+                 :type (or symbol list)
                  :initform nil
                  :documentation "The function type of FN.
 This is purely informative.")
diff --git a/source/browser.lisp b/source/browser.lisp
index ddecc484..f8c8085b 100644
--- a/source/browser.lisp
+++ b/source/browser.lisp
@@ -83,7 +83,7 @@ (defclass-export buffer ()
    (title :accessor title :initarg :title :type string :initform "")
    (last-access :accessor last-access
                 :initform (local-time:now)
-                :type number
+                :type local-time:timestamp
                 :documentation "Timestamp when the buffer was last switched to.")
    (modes :accessor modes :initarg :modes :initform '()
           :documentation "The list of mode instances.")
@@ -96,7 +96,6 @@ (defclass-export buffer ()
     :accessor keymap-scheme-name
     :initarg :keymap-scheme-name
     :initform scheme:cua
-    :type keymap:scheme-name
     :documentation "The keymap scheme that will be used
 for all modes in the current buffer.")
    (override-map :accessor override-map
diff --git a/source/mode.lisp b/source/mode.lisp
index 6c24f7c7..40882dc6 100644
--- a/source/mode.lisp
+++ b/source/mode.lisp
@@ -106,7 +106,7 @@ (define-mode root-mode (t)
                  :documentation "This hook is run when disabling the mode.
 It takes the mode as argument.
 It is run before the destructor.")
-   (keymap-scheme :accessor keymap-scheme :initarg :keymap-scheme :type keymap:scheme
+   (keymap-scheme :accessor keymap-scheme :initarg :keymap-scheme
                   :initform (define-scheme "root"
                               scheme:cua
                               (list
diff --git a/source/renderer-gtk.lisp b/source/renderer-gtk.lisp
index 7686cb96..669d44e3 100644
--- a/source/renderer-gtk.lisp
+++ b/source/renderer-gtk.lisp
@@ -2,22 +2,23 @@

 (in-package :next)

-(defclass-export gtk-browser (browser)
-  (#+darwin
-   (modifiers :accessor modifiers
-              :initform '()
-              :type list
-              :documentation "On macOS some modifiers like Super and Meta are
+(eval-when (:compile-toplevel :load-toplevel :execute)
+  (defclass-export gtk-browser (browser)
+    (#+darwin
+     (modifiers :accessor modifiers
+                :initform '()
+                :type list
+                :documentation "On macOS some modifiers like Super and Meta are
 seen like regular keys.
 To work around this issue, we store them in this list while they are pressed.
 See `push-modifiers', `pop-modifiers' and `key-event-modifiers'.")
-   (modifier-translator :accessor modifier-translator
-                        :initform #'translate-modifiers
-                        :type function
-                        :documentation "Function that returns a list of
+     (modifier-translator :accessor modifier-translator
+                          :initform #'translate-modifiers
+                          :type function
+                          :documentation "Function that returns a list of
 modifiers understood by `keymap:make-key'.  You can customize this slot if you
 want to change the behaviour of modifiers, for instance swap 'control' and
-'meta'.")))
+'meta'."))))

 (setf *browser-class* 'gtk-browser)

diff --git a/source/vi-mode.lisp b/source/vi-mode.lisp
index 0c1878a4..b3548060 100644
--- a/source/vi-mode.lisp
+++ b/source/vi-mode.lisp
@@ -8,7 +8,6 @@ (define-mode vi-normal-mode ()
   "Enable VI-style modal bindings (normal mode)"
   ((previous-keymap-scheme-name
     :accessor previous-keymap-scheme-name
-    :type keymap:scheme-name
     :documentation "The previous keymap scheme that will be used when ending
 vi-normal-mode.")
    (keymap-scheme

Those correspond to:

Class named NEXT:GTK-BROWSER not found.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [CONTINUE] Try finding the class again
 1: [RETRY-COMPILE-FILE] Retry compiling #P"/home/olof/.lisp/site/next/source/renderer-gtk.lisp"
...

Backtrace:
  0: (FIND-CLASS NEXT:GTK-BROWSER T NIL)
  1: (NEXT::BROWSER-TYPE-P NEXT:GTK-BROWSER)
  2: (CCL::%%TYPEP NEXT:GTK-BROWSER #<HAIRY-CTYPE (SATISFIES NEXT::BROWSER-TYPE-P)>)
  3: (TYPEP NEXT:GTK-BROWSER #<HAIRY-CTYPE (SATISFIES NEXT::BROWSER-TYPE-P)> NIL)
...

And the rest was I think just type errors where the slot was defined with a type and the assigned value didn't match.

[Ambrevar]

I can reproduce even after copying something. But on X11 there are multiple copy buffers: primary selection and clipboard. I'm not sure which one triggers the issue.

Note that on my Guix System I can reproduce the issue with the Quicklisp distribution, however I cannot reproduce it with the Guix package of the same Common Lisp libraries (Guix also packages cl-cffi, etc.). All this with the same WebKitGTK library (2.28.0).

[Ferada]

FWIW I have the same WebKitGTK, 2.28.0-0ubuntu.