Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No keyboard input (v72.1 for Linux / Debian 9 Stretch / KDE 5) #269

Open
bmanolov opened this issue Dec 15, 2019 · 15 comments
Open

No keyboard input (v72.1 for Linux / Debian 9 Stretch / KDE 5) #269

bmanolov opened this issue Dec 15, 2019 · 15 comments

Comments

@bmanolov
Copy link

bmanolov commented Dec 15, 2019

Initially posted in the forum


I am testing the linux-v72.0 package without any modifications and it seems that the keyboard input is not working. I cannot type anything in the text fields in forms.php, nor can I scroll long pages using the keyboard (Page Up, Page Down, arrow keys). The developers tools work fine however, so this problem is present only in the main browser window.

Here are my system specifications:

  • Debian GNU/Linux 9 (stretch) (amd64)
  • plasmashell 5.8.6
  • Qt: 5.7.1
  • KDE Frameworks: 5.28.0
  • GTK2: libgtk2.0-0: 2.24.31-2
  • GTK3: libgtk-3-0: 3.22.11-1

Here is a sample debug output from the console.

I have tested all packages from the linux-v70.0 release to see if the bug is present in any of them:

  • phpdesktop-linux-70.0 - ✔️ works (there is keyboard input)
  • phpdesktop-linux-70.1 - ✔️ works (there is keyboard input)
  • phpdesktop-linux-70.2 - ❌ program doesn't start due to a segmentation fault
  • phpdesktop-linux-70.3 - ❌ doesn't work (there is no keyboard input)
  • phpdesktop-linux-72.0 - ❌ doesn't work (there is no keyboard input)

As per Czarek's request I've built the cefclient from cef_binary_3.3626.1883.g00e6af4_linux64 and it is working fine.

@cztomczak
Copy link
Owner

Here is the phpdesktop and cefclient code for creating GTK window. It seems to me that removing the vbox container in GTK 2 might resolve the issue. Please change line 57 to "return window" and rebuild phpdesktop by following the Build on Linux instructions. Use branch "linux72".

@bmanolov
Copy link
Author

Ok, I've changed line 57 and compiled everything but the bug is still present.

diff --git a/src/gtk.cpp b/src/gtk.cpp
index 9e7bafa..356691c 100644
--- a/src/gtk.cpp
+++ b/src/gtk.cpp
@@ -54,7 +54,7 @@ GtkWidget* create_gtk_window(const char* title, const char* icon,
     set_window_icon(GTK_WINDOW(window), icon);
     gtk_widget_show_all(window);
 
-    return vbox;
+    return window;
 }

@cztomczak
Copy link
Owner

Does the issue reproduce on a clean OS? What OS version should I install in virtual machine to reproduce it?

@bmanolov
Copy link
Author

I was able to reproduce the bug on a clean install of Debian 10 in VirtualBox:

@cztomczak
Copy link
Owner

I haven't yet tested it on Debian 10. Just wanted to add that other users report it works fine on Ubuntu 18 which is based on Debian 10 buster. Can you test using different desktop environment on Debian, for example with GNOME?

@bmanolov
Copy link
Author

bmanolov commented Jan 4, 2020

✔️ Yes, I can confirm that there are no issues on Ubuntu 18.


❌ I have just tested it on a vanilla installation of Debian 10 with GNOME 3.30.2 and the results are negative: the keyboard input does not work. It was necessary to install GTK2 as it wasn't preinstalled.

@cztomczak
Copy link
Owner

cztomczak commented Jan 4, 2020

Other things to test:

  1. Register "configure-event" event as in cefclient and call NotifyMoveOrResizeStarted during that event.
  2. Add this line of code ScopedGdkThreadsEnter scoped_gdk_threads; before creating GTK window (declared in util_gtk.cpp / .h) as in cefclient.
  3. Register "size-allocate" event for vbox as in cefclient.
  4. Test cefclient app with the --hide-controls flag.

@bmanolov
Copy link
Author

bmanolov commented Jan 4, 2020

I haven't done the extra tests but I noticed something interesting about the cefclient that I built. On start it seems to be fine - I can type in the search form on the google page and I can scroll with the keyboard. But as soon I click in the address bar only the address bar gets the keyboard input:

  1. I click in the address bar
  2. I click somewhere in the page
  3. I start typing and the input appears in the address bar. Scrolling through the keyboard does not work anymore.

After some random clicking the address bar appears to lose the connection to the keyboard, but I can no longer type in the form field on the google page, nor can I scroll with the keyboard.

And on every 5-10 runs of the cefclient there were cases where the keyboard input was not working completely.

@bmanolov
Copy link
Author

bmanolov commented Jan 4, 2020

I just saw that you already filed a bug report about the issue that I mentioned (or something similar):

https://bitbucket.org/chromiumembedded/cef/issues/2026/multiple-major-keyboard-focus-issues-on

@bmanolov
Copy link
Author

bmanolov commented Jan 5, 2020

I have executed the three steps but the bug was still present. I am not entirely sure though if I've done the things correctly so here are my changes:

Changes 1-3
diff --git a/src/gtk.cpp b/src/gtk.cpp
index 9e7bafa..2b8e68a 100644
--- a/src/gtk.cpp
+++ b/src/gtk.cpp
@@ -3,6 +3,7 @@
 // Project website: https://github.com/cztomczak/phpdesktop
 
 #include "gtk.h"
+#include "util_gtk.h"
 #include "client_handler.h"
 
 #include "include/cef_app.h"
@@ -14,6 +15,9 @@ namespace {
 
 GtkWidget* create_gtk_window(const char* title, const char* icon,
                              bool center, int width, int height) {
+
+    ScopedGdkThreadsEnter scoped_gdk_threads;
+
     // Create window.
     GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
     g_main_window = window;
@@ -28,6 +32,9 @@ GtkWidget* create_gtk_window(const char* title, const char* icon,
     g_signal_connect(G_OBJECT(window), "destroy",
                      G_CALLBACK(window_destroy_signal), NULL);
     
+    g_signal_connect(G_OBJECT(window), "configure-event",
+                   G_CALLBACK(window_configure_event), NULL);
+
     // Default size.
     gtk_window_set_default_size(GTK_WINDOW(window),
             width, height);
@@ -47,6 +54,8 @@ GtkWidget* create_gtk_window(const char* title, const char* icon,
     #else
     GtkWidget* vbox = gtk_vbox_new(0, 0);
     #endif
+    g_signal_connect(vbox, "size-allocate",
+                   G_CALLBACK(window_size_allocate_signal), NULL);
     gtk_container_add(GTK_CONTAINER(window), vbox);
     
     // Show.
@@ -122,6 +131,18 @@ void window_destroy_signal(GtkWidget* widget, gpointer data) {
     CefQuitMessageLoop();
 }
 
+void window_configure_event(GtkWidget* widget, gpointer data) {
+    // LOG(INFO) << "window_focus_out_signal";
+    ClientHandler *handler = ClientHandler::GetInstance();
+    ::Window window_xid = get_window_xid(widget);
+    ::Window browser_xid = find_child_browser(window_xid);
+    CefRefPtr<CefBrowser> browser = handler->FindBrowserByXid(browser_xid);
+    if (browser_xid && browser.get()) {
+        LOG(INFO) << "window_configure_event: NotifyMoveOrResizeStarted";
+        browser->GetHost()->NotifyMoveOrResizeStarted();
+    }
+}
+
 void set_window_icon(GtkWindow* window, const char* icon) {
     GError *err = NULL;
     GdkPixbuf* pixbuf = gdk_pixbuf_new_from_file(icon, &err);
@@ -182,4 +203,4 @@ void fix_default_x11_visual(GtkWidget* widget) {
     }
     g_list_free(visuals);
     #endif
-}
\ No newline at end of file
+}

As for step 4, I have executed the cefclient with the --hide-controls flag and in 40-50% of the cases the keyboard focus bug was present. I couldn't however find a definitive pattern. I must add that the bug manifests itself during normal executions of cefclient too, but not always. It happens on every fifth or so run. The first clue that something is wrong is the missing focus in the google search form, i.e. there is no blinking cursor in the form text field.

@cztomczak
Copy link
Owner

Changes look good. But the problem is elsewhere since you can reproduce the issue in cefclient quite easily when controls are hidden.

The bitbucket issue provides information on resolving focus issues. It requires patching CEF and making changes to app code to handle focus-in-event, focus-out-event and grab-focus signals.

  1. tiliado/cef@b1d9e48#commitcomment-27005338
  2. tiliado/cef@4e18538

This could be applied without the need to patch CEF.

First try to make app changes to focus signals:

  1. Replace "SetFocus" calls with "SendFocusEvent".
  2. Implement "grab-focus" signal and call SendFocusEvent and gtk_widget_grab_focus().

If that doesn't help then instead of SendFocusEvent calls do XSetInputFocus(xdisplay_, xwindow_, RevertToParent, x11::CurrentTime) where xdisplay_ is cef_get_xdisplay() and xwindow_ is find_child_browser(get_window_xid(widget)).

@cztomczak
Copy link
Owner

cztomczak commented Jan 5, 2020

In focus-out-event signal don't call XSetInputFocus nor any other functions.

@cztomczak
Copy link
Owner

Or maybe it is required to call XSetInputFocus(xdisplay, get_window_xid(widget), ...) in "focus-out-event" signal.

@Goutte
Copy link

Goutte commented Sep 11, 2020

Hello !

I also have this issue ; spent the day trying to compile the CFE branch with the fix, to no avail.

Is there a fix in the works for this repo, or are you waiting for the merge upstream ?

@cztomczak
Copy link
Owner

I don't think this is fixed in CEF. You need to change phpdesktop code that handles focus signals. I've mentioned the X11 functions in an earlier comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants