Bugzilla – Full Text Bug Listing
| Summary: | Chromium browser doesn't tell the system that it did get focus. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Johan Compagner <jcompagner> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, guillez, jfaltermeier, Lars.Vogel, niraj.modi |
| Version: | 4.17 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 566608, 569095 | ||
|
Description
Johan Compagner
i have a feeling that this in Chromium class:
protected void browserFocus(boolean set) {
//debugPrint("cef focus: " + set);
if (!isDisposed() && browser != 0) {
long parent = (Display.getDefault().getActiveShell() == null) ? 0 : getHandle(chromium.getParent());
if (chromium.getDisplay().getActiveShell() != chromium.getShell()) {
// System.err.println("Ignore do_message_loop_work due inactive shell");
return;
}
ChromiumLib.cefswt_set_focus(browser, set, parent);
}
}
should do something more..
Should tell the eclipse system that this happend (when "set" == true)
i needed to do a bit better patch so that the isFocusControl doesnt always return false but only
when i noticed the browser didn't get focus yet.
The difference between IE and CHROMIUM is really that in chromium the Browser control gets the focus
and in IE its a control WebSite (that is a child of the browser, chromium impl doesn't have children)
The thing is and maybe that is the cause of all this, is that toe "hasFocus" boolean of the Chromium class
is set to true once:
Thread [main] (Suspended (breakpoint at line 1351 in Chromium))
ChromiumImpl(Chromium).on_got_focus(long) line: 1351
Chromium.on_got_focus(long, long) line: 1346
OS.DispatchMessage(MSG) line: not available [native method]
Display.readAndDispatch() line: 3610
PartRenderingEngine$5.run() line: 1157
Realm.runWithDefault(Realm, Runnable) line: 338
PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1046
E4Workbench.createAndRunUI(MApplicationElement) line: 155
Workbench.lambda$3(Display, WorkbenchAdvisor, int[]) line: 644
0000000000000000.run() line: not available
Realm.runWithDefault(Realm, Runnable) line: 338
Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 551
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 153
IDEApplication.start(IApplicationContext) line: 150
EclipseAppHandle.run(Object) line: 203
EclipseAppLauncher.runApplication(Object) line: 134
EclipseAppLauncher.start(Object) line: 104
EclipseStarter.run(Object) line: 401
EclipseStarter.run(String[], Runnable) line: 255
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 564
Main.invokeFramework(String[], URL[]) line: 657
Main.basicRun(String[]) line: 594
Main.run(String[]) line: 1465
Main.main(String[]) line: 1438
and then the chromiumn never thinks it will loose focus.. even if i click somewhere else in Eclipse.
and the Browser relays isFocusControl() to Chromium impl and that returns true based on that boolean
So it never thinks it did loose focus.
And i think that is the key to this problem. Because if i block once now when i see it shouldn't have focus yet:
boolean[] gained = new boolean[] { false };
browser = new Browser(parent, SWT.CHROMIUM)
{
// hack for https://bugs.eclipse.org/bugs/show_bug.cgi?id=567629
// because the internal browser does say "true" but the system didn't really know that that its own view had the focus now
// so the activation of parts and focus is screwed up. if we return false here all the time then SWT will force a focus Control.forceFocus()
@Override
public boolean isFocusControl()
{
System.err.println("is focus control " + gained[0] + "," + super.isFocusControl());
if (!gained[0]) return false;
return super.isFocusControl();
}
@Override
protected void checkSubclass()
{
}
};
browser.addFocusListener(new FocusListener()
{
@Override
public void focusLost(FocusEvent e)
{
gained[0] = false;
}
@Override
public void focusGained(FocusEvent e)
{
gained[0] = true;
}
});
then it works better (without that on the mac it really didn't work, and also under windows that isFocusControl would be constantly called)
It starts working i think because now 1 time in Control.forceFocus() this is called: OS.SetFocus (handle);
But why does the browser implementation constantly think it has the focus, it doesn't looe it again at all?
because at first i thought that i at some point the chromiumn browser needs to call OS.SetFocus (handle); somewhere itself (or let the parent know) when it get focus.
But now i think its the other way around somehow, it never looses focus?
Hi, thanks for the analysis. As you said there is a bug on java code in the focus implementation, but there is also a problem in cef 59 which steals the focus. We are working on contributing an update based on 69. Which as some of the issues fixed. (In reply to Guillermo Zunino from comment #3) > Hi, thanks for the analysis. As you said there is a bug on java code in the > focus implementation, but there is also a problem in cef 59 which steals the > focus. > We are working on contributing an update based on 69. Which as some of the > issues fixed. Hi Guillermo, Let us know if the Chromium upgrade to version 69 or newer, is still planned for 4.18 ? Thanks! (In reply to Niraj Modi from comment #4) > (In reply to Guillermo Zunino from comment #3) > > Hi, thanks for the analysis. As you said there is a bug on java code in the > > focus implementation, but there is also a problem in cef 59 which steals the > > focus. > > We are working on contributing an update based on 69. Which as some of the > > issues fixed. > > Hi Guillermo, > Let us know if the Chromium upgrade to version 69 or newer, is still planned > for 4.18 ? Thanks! We will try to make it for 4.18, but timeline looks very difficult for us. It might have to go to 4.19. In that case we will try to make the small bug fixes at least for 4.18. where do the fixes need to go in? For example a chromium upgrade is really just the CEF packages right (that is not part of eclipse itself) or do we need a newer eclipse also for that? (I guess if patches need to be done in the Chromium class..) (In reply to Guillermo Zunino from comment #5) > (In reply to Niraj Modi from comment #4) > > (In reply to Guillermo Zunino from comment #3) > > > Hi, thanks for the analysis. As you said there is a bug on java code in the > > > focus implementation, but there is also a problem in cef 59 which steals the > > > focus. > > > We are working on contributing an update based on 69. Which as some of the > > > issues fixed. > > > > Hi Guillermo, > > Let us know if the Chromium upgrade to version 69 or newer, is still planned > > for 4.18 ? Thanks! > > We will try to make it for 4.18, but timeline looks very difficult for us. > It might have to go to 4.19. In that case we will try to make the small bug > fixes at least for 4.18. Thanks for the update! sharing the 4.18 timelines for reference: - M3 planned for 20, Nov - RC1 planned for 27, Nov (In reply to Johan Compagner from comment #6) > where do the fixes need to go in? > For example a chromium upgrade is really just the CEF packages right (that > is not part of eclipse itself) > or do we need a newer eclipse also for that? > (I guess if patches need to be done in the Chromium class..) Yes fixes will go in the Chromium classes in SWT 'master' branch(source/binaries). Thanks! (In reply to Guillermo Zunino from comment #5) > We will try to make it for 4.18, but timeline looks very difficult for us. > It might have to go to 4.19. In that case we will try to make the small bug > fixes at least for 4.18. Guillermo, can you share you plans for the update of Chromium? Chromium has been removed via bug 572010 . |