Changing CefClient to handle with 1..* browser instances and CefApp to handle with 1..* CefClient instances. about java-cef HOT 12 CLOSED

Comment 1. originally posted by magreenblatt on 2014-03-12T09:50:31.000Z:

from java-cef.

Comment 2. originally posted by magreenblatt on 2014-03-12T09:53:07.000Z:

from java-cef.

Comment 3. originally posted by magreenblatt on 2014-03-12T09:53:19.000Z:

from java-cef.

Comment 4. originally posted by magreenblatt on 2014-03-28T13:10:28.000Z:

This change appears not to work on Windows:

1. Using off-screen rendering the application crashes on exit with the following error:

[0328/140611:FATAL:context.cc(307)] Check failed: OnInitThread().

This indicates that CefShutdown is being called on the wrong thread (it needs to be called on the same thread as CefInitialize).

2. Using windowed rendering the browser window never loads (application hangs with wait cursor).

from java-cef.

Comment 5. originally posted by magreenblatt on 2014-03-28T13:14:09.000Z:

from java-cef.

Original comment by Anonymous.

Comment 6. originally posted by [email protected] on 2014-04-04T08:37:43.000Z:

Hi Marshall,

2. Using windowed rendering the browser window never loads

The problem is caused by an AWT/Swing deadlock according AWTTreeLock.
See example on http://www.javaspecialists.eu/archive/Issue101.html for a similar
issue.

So I've changed the behavior of the methods

• CefApp.initialize()
• CefApp.doMessageLoopWork()
• CefApp.shutdown()
  to be handled by SwingUtilities.invokeAndWait() respectively SwingUtilities.invokeLater().

On this way I make sure, that the JCEF initialization, the message loop as well
as the shutdown are handled on the same thread. Creation of CefBrowser instances
should already be done on that thread because it's triggered by the native method
call CefBrowserHost::CreateBrowser.

Please see attached patch file for my solution (apply this attached patch file
after you've applied the previous patch file "09_2013-03-07_issue_XX_introduced...").

1. Using off-screen rendering the application crashes on exit

I can't reproduce this problem on my test-system by using OSR mode, but I realized
that it occurs by using the windowed rendering mode.

Unfortunately I can't find the cause for that problem.
Since I'm using invokeAndWait() and invokeLater() as well as
CefBrowserHost::CreateBrowser(), all relevant calls should be performed on the
same thread, shouldn't they? But the problem still occurs...

Maybe I missed something? What's about "context.cc"? Why the error occurs there?
What's its job?

By the way: this issue occurs since the update to the CEF 1750 branch (revision 28).
So if I go back to r27 I did' got such error messages. The first time I've
recognized it on r28.

Do you have any suggestions?

from java-cef.

Comment 7. originally posted by magreenblatt on 2014-04-04T19:54:35.000Z:

@ commentcomment 6.: Thanks for looking into the problem. The assertion in context.cc means that CefShutdown is being called on a different thread than CefInitialize. You can try adding System.out.println("shutdown on " + Thread.currentThread()); before calling N_Shutdown() and compare to the "initialize on ..." output to verify that it's the same thread.

from java-cef.

Original comment by Anonymous.

Comment 8. originally posted by [email protected] on 2014-04-11T12:24:41.000Z:

@ commentcomment 7.:
Hi Marshall,

I've managed to fix both issues. Please see attached patch file for my solution
(apply this attached patch file after you've applied the previous patch file
"09_2013-03-07_issue_XX_introduced...").

So the problem wasn't that shutdown() was called on a wrong thread but rather that it
wasn't called anywhere. Why? Because CefApp.finalize() wasn't called automatically
when the application exited. This caused CEF to call CefShutdown() after the
dispatcher thread was terminated by java and that - in fact - caused the described
crash on exit of the app.

To solve this problem, I've done the following:

• Removed the needless method CefApp.finalize()
• Added the new method CefApp.dispose() (explanation see below)
• Moved handling of initialize(), doMessageLoopWork(), shutdown() to the dispatcher thread (as written in comment comment 6.)
• Performing "destroyAllBrowsers()" just before shutting down
• hook into "removeNotify()" of Canvas and forward it as "parentWindowWillClose()" to CEF
• calling "removeNotify()" on the Canvas each time the browser window is closed/destroyed
• Added parentWindowWillClose() from CEF to JCEF
• Removed runMessageLoop() due it isn't used any more

The new method "dispose()" in CefApp has to be called by MainFrame for an ordeded
shutdown of CEF. That means, that it

1. closes all CefBrowser instances (and informs CEF by calling "ParentWindowWillClose()")
2. closes all CefClient instances
3. stops running the message look
   and after all is cleaned up it
4. calls CefShutdown

Up to now, didn't find a way to trigger dispose() automatically because

• finalize() isn't called at any time due the singleton pattern of CefApp
• shutdown hooks can't be used because they are executed within the dispatcher thread
  but the dispatcher thread is required for shutting down CEF. That ends in a dead lock.

Btw: This patch fixes the crash which occured by terminating the app on Macintosh as well.

I think calling a "dispose()" method before App termination is a suitable way.

from java-cef.

Comment 9. originally posted by magreenblatt on 2014-04-11T16:10:40.000Z:

@ commentcomment 8.: Thanks, I think adding a dispose method is fine. I've committed the combined patches as revision 40.

There's still one shutdown crash on Mac -- if you select "Quit MainFrame" from the top application menu without closing the window first. We can address that in issue comment 41..

from java-cef.

• set state to "open"

from java-cef.

Original changes by Anonymous.

• set attachment to "09_2014-04-11_solved_swing_deadlock_and_crash_on_exit.patch"

from java-cef.

• set state to "resolved"

from java-cef.