chromiumembedded / cef

Chromium Embedded Framework (CEF). A simple framework for embedding Chromium-based browsers in other applications.
https://bitbucket.org/chromiumembedded/cef/
Other
3.36k stars 467 forks source link

Multiple major keyboard focus issues on Linux (branches 2883, 2840, 2785) #2026

Open magreenblatt opened 8 years ago

magreenblatt commented 8 years ago

Original report by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


  1. [cefclient] Branch 2883 regression. Type something in address bar and click on the browser widget and try to type - keyboard doesn't work in browser. This worked fine in branch 2840 and stopped working in branch 2883.

  2. [cefclient] Branches 2883, 2840, 2785. Click on address bar - a type cursor indicator is missing. There should be a vertical cursor blinking indicating at which position in text I'm typing. Looks to me CEF browser never releases focus entirely - a proof for that seems to be the focus bug in Issue 4) [third party] - CEF steals keyboard focus from native widget when just hovering over CEF browser (no click).

  3. [third party: wxWidgets, Tkinter] Branches 2785, 2840 and 2883. When using third party GUI frameworks like wxWidgets and Tkinter, native widgets can't take keyboard focus. There was a workaround found by calling gtk_window_present(1), but it still doesn't resolve the issue entirely. Keyboard focus on a native widget works only when mouse is over the native widget. When native widget has keyboard focus and I move mouse cursor to CEF browser widget (just hover, no click), then native widget loses keyboard focus, and neither CEF browser and nor native widget have keyboard focus at that time. More details reported in this topic on the CEF Forum: https://magpcss.org/ceforum/viewtopic.php?f=6&t=14568

  4. [third party: Tkinter]. Branch 2883 regression - this focus bug doesn't occur in branch 2840. When native widget has keyboard focus and I move mouse out of that widget and hover of CEF browser widget then CEF steals keyboard focus automatically. I don't click on CEF browser, only hover with mouse over it. When I move mouse back over native widget, then CEF browser still has keyboard focus. This might be related to Issue 2) [cefclient] and Issue 3) [third party] - looks like native widget never has focus entirely.

  5. [third party: PyGTK] Branch 2883. Issue with gtk2.py example in CEF Python. It is a very basic GTK example that has a menu and a VBox widget in which CEF browser is embedded. I'm launching example and CEF browser is loading, when I start clicking with a mouse inside widget and/or typing, while it loads, then later keyboard doesn't work. The CEF browser has focus, I can select text with mouse, I can click on google search input and a blinking type cursor indicator appears, but I can't type anything. I tried to reproduce this issue in my other cefpython examples (hello world, tkinter) and in cefclient/cefsimple, but the issue doesn't occur there. Looks like this focus issue is specific to that GTK / VBox layout in that gtk2.py example. If I don't do any clicks/typing during loading then the issue doesn't occur.

Testing on Ubuntu 14.04 64-bit with latest CEF commits in branches 2883, 2840 and 2785.

magreenblatt commented 8 years ago

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


Added link to a topic on the CEF Forum that describes Issue 3) in more details.

magreenblatt commented 8 years ago

If someone wants to debug this the likely places to start are libcef/browser/native/window_x11.cc in CEF and ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc in Chromium.

See also issue #1679 and issue #1417 for previous attempts to fix focus-related issues on Linux.

magreenblatt commented 7 years ago

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


I haven't yet had time to debug this further. I managed to find simple workarounds in most of examples in cefpython (by calling setfocus in OnLoadStart once on initial loading and in CefFocusHandler.OnGotFocus).

However the focus issues seem to occur also on Mac and the same fixes that worked on Linux, don't work on Mac. So far I've been testing CEF with Qt toolkit on Mac and CEF is always eating keyboard focus from other controls. I see that cefclient on Mac doesn't have a navigation bar, so seems like CEF on Mac has no tests for how it behaves with other controls.

magreenblatt commented 7 years ago

cefclient on macOS should have an address bar and navigation buttons. Maybe there's something wrong with your local build? Can you try the "Sample Application" from http://opensource.spotify.com/cefbuilds/index.html?

magreenblatt commented 7 years ago

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


cefclient Issue 1) described in first post combined with a Javascript Alert which occurs on pages which log messages (the alert notifies about messages being written to console.log) makes it impossible to use cefclient on some pages. Here are the steps to reproduce:

  1. Load url https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

  2. At the end of that page, just above the "Reference" section click the "Test the online live demo" link

  3. The new page loads and you can see javascript alert. After closing that alert browser becomes broken - you can't type anything in the form on the page.

magreenblatt commented 7 years ago

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


Focus issues still reproducible in branch 3029.

magreenblatt commented 7 years ago

Original comment by Vagabundo1234 (Bitbucket: Vagabundo1234).


I'm having this issue on windows with CEFpython3 (version 57.0) with Tk.

If the CEF window grabs the keyboard my app cant get it back unless I cwicth to another application window and then back to my tk app again. Then I can use keyboard for tk widgets, until the CEF window grabs the keyboard again.

magreenblatt commented 6 years ago

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


Just stumbled upon a few commits by Jiří Janoušek that fix focus issues in a GTK app. Posting here as reference, as it might be useful:

  1. https://github.com/tiliado/cef/commit/b1d9e48101279ae08fd35a2e18c7dd0d34245ef9
  2. https://github.com/tiliado/cef/commit/231480ea855ccc081a4f4e6874b5ed50faa7bd9a
  3. https://github.com/tiliado/cef/commit/e2295256cfe5aead0572214070296161ec11f137

And this comment: https://github.com/tiliado/cef/commit/b1d9e48101279ae08fd35a2e18c7dd0d34245ef9#commitcomment-27005338

magreenblatt commented 5 years ago

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


Latest patch that fixes X11 focus issues in CEF branch 3538 by Jiří Janoušek: https://github.com/tiliado/cef/commit/f9a1cbe103c693b7a28b7e01b29b27a3857d5a21

magreenblatt commented 5 years ago

Original comment by Steffen Klee (Bitbucket: Steffen Klee).


I can confirm, that applying the focus patch on branch 3809 fixes the focus issues.

magreenblatt commented 4 years ago

Original comment by Benjamin Terrier (Bitbucket: Benjamin Terrier).


Without surprise I have the same issue with Qt.

Any chance of seeing this patch merged ?

magreenblatt commented 4 years ago

Original comment by Alejandro Juan Perez (Bitbucket: Alejandro Juan Perez).


Yes, please merge this patch, it would be very useful

magreenblatt commented 3 years ago

Original comment by K Matt (Bitbucket: K Matt).


The code has changed much since this patch XQueryTree and XSetInputFoucs functions cannot be used. Any help in applying the patch to the recent branch. Though I find equivalent for the above functions, I could not find one for XGetInputFocus

magreenblatt commented 3 years ago

Can someone submit the above fixes as a PR that works with current master? Thanks.

magreenblatt commented 3 years ago

Original comment by Dominik Mayrhofer-Poldlehner (Bitbucket: dmayrhofer, GitHub: dmayrhofer).


Can confirm that this problem still occurs with version 4430.

magreenblatt commented 8 years ago

Original changes by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


magreenblatt commented 7 years ago
JCYang commented 4 months ago

Hi, I've been working on this set of problems lately, for the 6261 branch In our app the set of focus bugs in linux manifest themselves, after a long time debugging, all has been fixed. I'll soon open up a PR based on the latest master branch. Yet now there comes one specific question not strictly related to the bugs but to finally fix the last minor corner case in our app, it seems needed, that is, in CefBrowserHostBase::LoadMainFrameURL(), why we need to OnSetFocus(FOCUS_SOURCE_NAVIGATION) after we just LoadURL() into mainframe? I simply can't get it, LoadURL() just means the user needs to LoadURL(), it does not mean the user also need to put focus to the browser view, right?

My set of patch now consider to get rid of this OnSetFocus(FOCUS_SOURCE_NAVIGATION), it will help. And I don't see significant consequence, so maybe I don't get the ideas?

magreenblatt commented 4 months ago

why we need to OnSetFocus(FOCUS_SOURCE_NAVIGATION) after we just LoadURL() into mainframe?

If you don't want the default focus behavior you should implement CefFocusHandler::OnSetFocus.

JCYang commented 4 months ago

Oh, sorry that I may not declare the subject clear enough. Just implement CefFocusHandler::OnSetFocus() won't change the basis. What I mean is this one

Screenshot 2024-07-06 014308

Because several internal changes are done in this function. implement CefFocusHandler::OnSetFocus() can't veto any of these.

Why we need to set focus after just load one url? Any sound necessity?

magreenblatt commented 4 months ago

Because several internal changes are done in this function.

What do you mean? See the implementation of OnSetFocus.

JCYang commented 3 months ago

Hi, after re-check the OnSetFocus(), I understand that you're right. I can do the customization there. Thanks.

Now when I'm going to land my set of patches in the latest 6533 branch, I encountered build errors without my patches yet, in the final link step of libcef.so, here're the error message

ld.lld: error: undefined symbol: lens::OpenLensRegionSearchInstructions(Browser*, base::OnceCallback<void ()>, base::OnceCallback<void ()>)

referenced by lens_region_search_controller.cc:74 (../../chrome/browser/lens/region_search/lens_region_search_controller.cc:74) region_search/lens_region_search_controller.o:(lens::LensRegionSearchController::Start(content::WebContents*, bool, bool, lens::AmbientSearchEntryPoint)) in archive obj/chrome/browser/lens/region_search/libregion_search.a clang++: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed.

What's wrong? I just use update.sh with '--branch=6533' to update the codes, after that, I run cef/cef_create_projects.sh to generate everything. (yes, without my patches yet). I found that there're test preview 6533 branch binary for linux in https://cef-builds.spotifycdn.com/index.html#linux64 What might be wrong?

JCYang commented 3 months ago

Just some notes about the build failure issue mentioned above for references. 6478 branch can be built successfully. After further investigate the 6533 branch, we need to further patch the the following 3 files chrome/browser/BUILD.gn, chrome/browser/ui/BUILD.gn, chrome/browser/ui/views/side_panel/BUILD.gn make all the "//chrome/browser/lens/region_search" dependency conditional only when 'enable_lens_desktop_google_branded_features'. that is if (enable_lens_desktop_google_branded_features && !is_android) { deps += [ "//chrome/browser/lens/region_search" ] }

the build can be successful now. this is a glitch introduced by recent chromium changes.

JCYang commented 3 months ago

The PR has been setup here https://bitbucket.org/chromiumembedded/cef/pull-requests/787/overview

magreenblatt commented 1 month ago

Related PR: https://bitbucket.org/chromiumembedded/cef/pull-requests/789