pottermm / javachromiumembedded

Automatically exported from code.google.com/p/javachromiumembedded
0 stars 0 forks source link

Focus doesn't go from Swing widgets into CEF page #42

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Build the latest JCEF test app (uses 1750 CEF but this isn't a recent pb)
2. Go to www.google.ca or any other site.
3. Give focus to the Address input text (Swing widget).
4. Press Tab repeatedly. The focus never enters into the web page, it circles 
between the Swing widgets only.

If you manually give focus to an element in the page then press Tab repeatedly, 
the focus cue now circles inside the web page for ever.

What is the expected output? What do you see instead?
Focus should enter the web page when the cef browser is receiving the focus, 
and leave the web page to return to the next swing widget when tabbing away of 
the last element in the page. 

What version of the product are you using? On what operating system?
Latest JCEF based on CEF 1750
Can be reproduced on Windows, Mac, in OSR and non OSR mode.

Original issue reported on code.google.com by christop...@gmail.com on 20 Feb 2014 at 9:11

GoogleCodeExporter commented 9 years ago
Forwarding the focus from the address field into the browser window (by 
pressing tab repeatedly) works already since some revisions ago. But vice versa 
(out from the browser window back to the next swing widget) doesn't work.

Attached you'll find a patch (based on the current rev100) which fixes that 
issue for windows. 
This patch might fix issue 96 as well. At least the last part of that issue is 
fixed:
"Adding a CefFocusHandler and returning true for onSetFocus fixes the problem, 
however clicking inside a browser steals the keyboard focus from the entire 
application forever. Clicking back on any swing component will receive the 
mouse focus, but keyboard event will be sent to the browser.
"

On Mac it still doesn't work to return the focus from the browser widget to 
another swing widget by pressing Tab repeatedly. This is because the native 
method void FocusHandler::OnTakeFocus(CefRefPtr<CefBrowser> browser, bool next) 
is never called on Mac. This might be a chromium or CEF issue and maybe it is 
already fixed in newer CEF versions (?).

Regards, Kai

Original comment by k...@censhare.de on 9 Sep 2014 at 12:32

Attachments:

GoogleCodeExporter commented 9 years ago
@comment #1: Please see the new patch file attached to this comment. It's based 
on revision r101.

Original comment by k...@censhare.de on 15 Sep 2014 at 5:41

Attachments:

GoogleCodeExporter commented 9 years ago
@comment #1: Please see the new patch file attached to this comment. It's based 
on revision r101.

Original comment by k...@censhare.de on 15 Sep 2014 at 8:29

Attachments:

GoogleCodeExporter commented 9 years ago
@#3: Thanks for the patch. Some comments:

1. Line 101:

+#if defined(OS_WIN)
+  if (enable == JNI_FALSE) {
+    HWND browserHandle = browser->GetHost()->GetWindowHandle();
+    if (CefCurrentlyOn(TID_UI))
+      ForwardFocus(browserHandle);
+    else
+      CefPostTask(TID_UI, NewCefRunnableFunction(&ForwardFocus, 
browserHandle));
+  }
+#endif

Shouldn't this be enable == JNI_TRUE instead of JNI_FALSE?

2. Line 30:

+    KeyboardFocusManager km = 
+            KeyboardFocusManager.getCurrentKeyboardFocusManager();

Use 4 space indent for the 2nd+ lines.

Original comment by magreenb...@gmail.com on 18 Sep 2014 at 2:56

GoogleCodeExporter commented 9 years ago
@#1: Filed the OnTakeFocus issue as 
https://code.google.com/p/chromiumembedded/issues/detail?id=1382.

Original comment by magreenb...@gmail.com on 18 Sep 2014 at 2:59

GoogleCodeExporter commented 9 years ago
@#3:
1. Line 101:
I think I've selected a bad name for the function ForwardFocus. I've renamed it 
to "FocusParent" which should be self explaining. So enable == JNI_FALSE is 
right because we only want to pass the focus to the parent parent if 
setFocus(false) was called.

Btw:  (enable == JNI_TRUE) isn't a good comparison because JNI_TRUE is defined 
by "1" but the jboolean enable might have (and does has on windows) a value of 
!= 0 for TRUE and a value of 0 for FALSE. For that reason you'll find many 
(boolValue != JNI_FALSE) instead of (boolValue == JNI_TRUE) statements within 
the code.

2. Line 30:
Is fixed now. Please see attached patch file.

Original comment by k...@censhare.de on 19 Sep 2014 at 4:57

Attachments:

GoogleCodeExporter commented 9 years ago
@#5: Thanks for filing that issue on CEF.

Original comment by k...@censhare.de on 19 Sep 2014 at 4:57

GoogleCodeExporter commented 9 years ago
@#6: Thanks, added in revision 105.

Original comment by magreenb...@gmail.com on 29 Sep 2014 at 4:33

GoogleCodeExporter commented 9 years ago
Issue 121 has been merged into this issue.

Original comment by magreenb...@gmail.com on 29 Sep 2014 at 4:37