Java Chromium Embedded Framework (JCEF). A simple framework for embedding Chromium-based browsers in other applications using the Java programming language.
Home Page: https://bitbucket.org/chromiumembedded/java-cef
License: Other
Original report by Anonymous.
Original issue 49 created by [email protected] on 2014-03-08T07:58:00.000Z:
Purpose: Extending CefDisplayHandler by additional methods.
This patch relies on the attached patch file of issue comment 48..
If you want to try these code changes, add the patch of issue comment 48. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch, the CefDisplayHandler is extended by the
additional methods
Please see attached patch file for further informations.
Original report by me.
Original issue 23 created by magreenblatt on 2013-12-30T18:59:00.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The selection should work as expected. Instead, the application crashes with the below stack trace (edit run.sh, change the java command-line to "lldb -- /usr/bin/java -cp $CLS_PATH -Djava.library.path=$LIB_PATH MainFrame"):
$ ./run.sh macosx64 Debug
Current executable set to '/usr/bin/java' (x86_64).
(lldb) r
Process 9312 launched: '/usr/bin/java' (x86_64)
Process 9312 stopped
* thread comment 1.: tid = 0x1c03, 0x00007fff5fc01028 dyld`_dyld_start, stop reason = exec
frame comment 0.: 0x00007fff5fc01028 dyld`_dyld_start
dyld`_dyld_start:
-> 0x7fff5fc01028: popq %rdi
0x7fff5fc01029: pushq $0
0x7fff5fc0102b: movq %rsp, %rbp
0x7fff5fc0102e: andq $-16, %rsp
(lldb) c
Process 9312 resuming
initialize on Thread[AWT-EventQueue-0,6,main] with library path ./xcodebuild/Debug/jcef_app.app/Contents/MacOS
Process 9312 stopped
* thread comment 30.: tid = 0x3d03, 0x00000001030adc35, stop reason = signal SIGSEGV
frame comment 0.: 0x00000001030adc35
-> 0x1030adc35: movl 12(%rdx), %edx
0x1030adc38: movl 12(%r12,%rdx,8), %ebx
0x1030adc3d: movl 16(%rsi), %edi
0x1030adc40: movl 12(%r12,%rdi,8), %r8d
(lldb) bt
* thread comment 30.: tid = 0x3d03, 0x00000001030adc35, stop reason = signal SIGSEGV
frame comment 0.: 0x00000001030adc35
frame comment 1.: 0x0000000103006233
frame comment 2.: 0x0000000103006058
frame comment 3.: 0x0000000103006233
frame comment 4.: 0x0000000103006058
frame comment 5.: 0x0000000103006058
frame comment 6.: 0x0000000103006058
frame comment 7.: 0x0000000103006233
frame comment 8.: 0x0000000103006058
frame comment 9.: 0x0000000103006233
frame comment 10.: 0x0000000103006233
frame comment 11.: 0x00000001030004e7
frame comment 12.: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
frame comment 13.: 0x00000001012d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
frame comment 14.: 0x000000010130a605 libjvm.dylib`jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 698
frame comment 15.: 0x00000001012fc2cd libjvm.dylib`jni_CallObjectMethodV + 174
frame comment 16.: 0x0000000101aed42d JavaNativeFoundation`JNFCallObjectMethod + 170
frame comment 17.: 0x000000011649aa64 libosxui.dylib`Java_com_apple_laf_ScreenPopupFactory__1getHeavyWeightPopup + 89
frame comment 18.: 0x0000000103012698
frame comment 19.: 0x0000000103006233
frame comment 20.: 0x0000000103006233
frame comment 21.: 0x0000000103006233
frame comment 22.: 0x0000000103006233
frame comment 23.: 0x0000000103006058
frame comment 24.: 0x0000000103006058
frame comment 25.: 0x0000000103006058
frame comment 26.: 0x0000000103006706
frame comment 27.: 0x0000000103006058
frame comment 28.: 0x0000000103006058
frame comment 29.: 0x0000000103006058
frame comment 30.: 0x0000000103006058
frame comment 31.: 0x0000000103006706
frame comment 32.: 0x0000000103006058
frame comment 33.: 0x0000000103006058
frame comment 34.: 0x0000000103006058
frame comment 35.: 0x0000000103006058
frame comment 36.: 0x0000000103006058
frame comment 37.: 0x0000000103006058
frame comment 38.: 0x0000000103006058
frame comment 39.: 0x0000000103006058
frame comment 40.: 0x0000000103006350
frame comment 41.: 0x0000000103006350
frame comment 42.: 0x0000000103006058
frame comment 43.: 0x0000000103006058
frame comment 44.: 0x0000000103006058
frame comment 45.: 0x0000000103006058
frame comment 46.: 0x0000000103006058
frame comment 47.: 0x0000000103006233
frame comment 48.: 0x00000001030004e7
frame comment 49.: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
frame comment 50.: 0x00000001012d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
frame comment 51.: 0x000000010132a444 libjvm.dylib`JVM_DoPrivileged + 1041
frame comment 52.: 0x0000000103012698
frame comment 53.: 0x0000000103006233
frame comment 54.: 0x0000000103006233
frame comment 55.: 0x00000001030068e1
frame comment 56.: 0x0000000103006233
frame comment 57.: 0x00000001030004e7
frame comment 58.: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
frame comment 59.: 0x00000001012d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
frame comment 60.: 0x000000010132a444 libjvm.dylib`JVM_DoPrivileged + 1041
frame comment 61.: 0x0000000103012698
frame comment 62.: 0x0000000103006233
frame comment 63.: 0x00000001030068e1
frame comment 64.: 0x0000000103006058
frame comment 65.: 0x0000000103006058
frame comment 66.: 0x0000000103006058
frame comment 67.: 0x0000000103006058
frame comment 68.: 0x0000000103006058
frame comment 69.: 0x0000000103006058
frame comment 70.: 0x00000001030004e7
frame comment 71.: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
frame comment 72.: 0x00000001012d72a7 libjvm.dylib`JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 283
frame comment 73.: 0x00000001012d73e4 libjvm.dylib`JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
frame comment 74.: 0x00000001013263ca libjvm.dylib`thread_entry(JavaThread*, Thread*) + 173
frame comment 75.: 0x00000001014efb47 libjvm.dylib`JavaThread::thread_main_inner() + 155
frame comment 76.: 0x00000001014f124f libjvm.dylib`JavaThread::run() + 419
frame comment 77.: 0x000000010141b1c6 libjvm.dylib`java_start(Thread*) + 294
frame comment 78.: 0x00007fff845e8742 libsystem_c.dylib`_pthread_start + 327
frame comment 79.: 0x00007fff845d5181 libsystem_c.dylib`thread_start + 13
Original report by Anonymous.
Original issue 45 created by [email protected] on 2014-03-08T07:52:32.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
There is a possible NPE while evaluating the java library path.
In some situations "String[] found" can be null because
dir.list() returns null if the pathname does not denote a directory,
or if an I/O error occurs.
What version of the product are you using? On what operating system?
rev.31
Please provide any additional information below.
Attached you'll find a simple patch file which fixes this problem
Original report by Anonymous.
Original issue 35 created by christophe.cornu on 2014-01-27T20:41:45.000Z:
What steps will reproduce the problem?
What version of the product are you using? On what operating system?
3.1650.1552_windows64. Tested on Windows 7.
What could explain this behavior? A CEF callback that JCEF doesn't currently handle? A dll that is optional for rendering but not loaded? Any tip welcome...
Original report by Anonymous.
Original issue 27 created by [email protected] on 2014-01-15T10:25:59.000Z:
What steps will reproduce the problem?
e.g. if you have Java7u40:
export GYP_DEFINES="jcef_platform=macosx64 jdk_directory=/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home target_arch=x64"
What is the expected output? What do you see instead?
Build fails because jcef.gyp points to the wrong java library and java header paths
Please provide any additional information below.
Attached you'll find a patch file which
(a) fixes the jcef.gyp to the Java7 target
(b) adds definition for JNIEXPORT to util.h due its missing within java7u40 and prior versions
(b) moves the tests application "MainFrame" to package "tests" to comply to java
(c) fixed the script files to call tests.MainFrame instead of MainFrame
Please correct the wiki page BranchesAndBuildings within the point "export GY_DEFINES" corresponding
Original report by Anonymous.
Original issue 26 created by leichtenfels on 2014-01-13T09:26:16.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Mouse wheel up scrolls down, wheel down scrolls up. Behaviour is inverted. Also, scroll delta is far too low. Scrolling using the wheel should behave as in native browsers.
What version of the product are you using? On what operating system?
Windows 7 x64
JDK 7u45 x64
JCEF trunk as of 2014-01-13
Please provide any additional information below.
Original report by Anonymous.
Original issue 47 created by [email protected] on 2014-03-08T07:54:21.000Z:
Purpose: Change CefHandler to act like CefClient from CEF.
This patch relies on the attached patch file of issue #.
If you want to try these code changes, add the patch of issue # first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
This issue is divided into two patch files (3a and 3b).
With the first patch (3a), the interface CefHandler is renamed into CefClientHandler.
With the second patch (3b), the interface CefClientHandler is changed to an abstract class
which inherhits from CefNative (a new interface - see patch file for details).
Its previous methods are moved to the new handler interface
CefClientHandler is extended by the new methods
For LifeSpanHandler an adapter class is provided which methods are empty.
CefClient is extended by the methods
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 52 created by [email protected] on 2014-03-08T08:00:32.000Z:
Purpose: Renaming CefContext to CefApp, make it to the JCEF
entry point by using the singleton pattern. Extending jcef
by CefAppHandler and CefCommandLine for handling command line args in java.
This patch relies on the attached patch file of issue comment 51..
If you want to try these code changes, add the patch of issue comment 51. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
This issue is divided into two patch files (8a and 8b).
With the first patch (8a), the class CefContext is renamed into CefApp.
With the second patch (8b), the class CefApp is changed to be
accessible by using the singleton pattern. All methods, previously
marked as static, are standard class methods.
To handle commandline attributes in java the method
CefApp is inherited from CefAppHandlerAdapter which provides a
default implementation of the commandline processing.
Beside this, the methods isLinux(), isWindows() and isMacintosh()
are moved to their own class "OS".
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 51 created by [email protected] on 2014-03-08T07:59:25.000Z:
Purpose: Extending CefBrowser by additional methods.
This patch relies on the attached patch file of issue comment 50..
If you want to try these code changes, add the patch of issue comment 50. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch, the CefBrowser is extended by the
additional methods
Known issue: showDevTools() and closeDevTools() doesn't work properly.
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 31 created by [email protected] on 2014-01-15T10:34:21.000Z:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
Due OSR with manual message-loop handling is too slow, I've added the possibility to use On-Screen-Rendering for OS X systems.
What version of the product are you using? On what operating system?
Please provide any additional information below.
Therefore the Chromium API is told to be CALayer based because a CALayer has to be used within Java 7 to embed external content into Java.
In consequence of this, I've changed the behavior of CefContext.initialize, which must not be called out of windowOpened() because it will block
in non OSR mode. Reason for that is, that "CefRunMessageLoop" is called within it (using the main thread of the app).
For details, please see the source code changes.
Benefits of Non-OSR:
Much Much faster (a good performance test: http://ie.microsoft.com/testdrive/performance/fishbowl/)
The Issues comment 15., comment 16., comment 22., comment 23. ,comment 24., comment 26. doesn't occur
Current pitfall:
The app crashes on exit (I think this is a "called on wrong thread" issue or something like that)
Original report by Anonymous.
Original issue 38 created by christophe.cornu on 2014-02-05T19:08:29.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The GLCanvas is drawn in the bottom left corner, it doesnt follow the Border layout info.
Please provide any additional information below.
The version of JOGL used by JCEF is 2.0.2.
Get the latest JOGL version (2.1.4 in my case).
Rerun. The GLCanvas is drawn in the right place, even when resizing the frame.
Note. To display the version of JOGL use this:
System.out.println("JOGL version: "+ Package.getPackage("javax.media.opengl").getImplementationVersion());
Note. I downloaded JOGL from http://jogamp.org/deployment/jogamp-current/archive/
I suspect the latest JOGL version contains the fix for this pb
https://jogamp.org/bugzilla/show\_bug.cgi?id=816
Original report by Anonymous.
Original issue 50 created by [email protected] on 2014-03-08T07:58:46.000Z:
Purpose: Extending CefLifeSpanHandler by additional methods.
This patch relies on the attached patch file of issue comment 49..
If you want to try these code changes, add the patch of issue comment 49. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch, the CefLifeSpanHandler is extended by the
additional methods
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 32 created by [email protected] on 2014-01-22T13:51:24.000Z:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
After adding windowed rendering support to Mac, I've added it to Windows, too.
Please see Issue comment 31. for details of the Mac implementation.
What version of the product are you using? On what operating system?
Please provide any additional information below.
Please note: This patch relies on the attached patch file of issue comment 31..
If you want to try these code changes, add the patch of issue comment 31. first and afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
Original report by Anonymous.
Original issue 29 created by [email protected] on 2014-01-15T10:29:28.000Z:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Within the attached patch file you'll find an extension for the MainFrame test app which allows to store bookmarks (during a browser session).
Original report by me.
Original issue 55 created by magreenblatt on 2014-03-12T09:50:27.000Z:
This is a meta-issue for tracking the overall JCEF refactoring effort.
Overall plan document: https://docs.google.com/document/d/1CFihrGcU504yv2Xogt3Pll9L2b9E8MVYmwpQlCT17Do/edit?usp=sharing
Step 1 document (issue #45 - issue #54):
https://docs.google.com/document/d/1NcrgjCugOpYFvb-HtVsP5xrVYsvEtda7uPhn\_bPdRsY/edit?usp=sharing
Original report by Anonymous.
Original issue 53 created by [email protected] on 2014-03-08T08:01:15.000Z:
Purpose: Changing CefClient to handle with 1..* browser instances
and CefApp to handle with 1..* CefClient instances.
This patch relies on the attached patch file of issue comment 52..
If you want to try these code changes, add the patch of issue comment 52. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
This patch moves the most complexity of using JCEF, into jcef itself.
That means there is no need to deal with CefMessageHandler or other
things within the users application.
The native methods createBrowser and getWindowHandle are move to CefBrowser itself.
Beside this the window redered version and the OSR version of the browser
is split up into two independet classes (CefBrowserOsr and CefBrowserWr) which
inherit from CefBrower_N (now an abstract class instead of an interface).
An instance of one of those browsers is created by using CefBrowserFactory out of
CefClient (method createBrowser). The native part of the browser is created
by using CefCreateBrowser instead of CefCreateBrowserSync. Consequently attaching
the native CefBrowser instance to the java instance is done in the native code
by the CefLifeSpanHandler (method OnAfterCreated).
After applying this patch, you can use jcef for example on this simple way:
public static void main(String [] args) {
CefApp app = CefApp.getInstance(args);
CefClient client = app.createClient();
// optional add handlers
client.addDisplayHandler(new DisplayHandlerAdapter() {
@ Override
//whatever you're intrested in
});
// add additional handlers, if required
CefBrowser browser = client.createBrowser("http://some.where", osrEnabled, transparent);
Component ui = browser.getUIComponent();
// do whatever with the ui.
// ...
}
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 19 created by Scyntherei on 2013-12-24T05:47:51.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Working sample project using chromium embedded.
What version of the product are you using? On what operating system?
Windows 7 Home Premium x64
jdk7u45
jcef 3.1650.1501.9 win64 preview
Please provide any additional information below.
Basically I just tried to download and run the sample project included with the binary download. What happens is the program will open and draw the window and jcef will load google.com in, but the browser remains blank. I only knew that it successfully loaded the page by right clicking > view source.
I'm only a casual java developer, I only have need for it every so often so I could just be doing something horribly wrong.
My theory is that perhaps my opengl version is too high or something. I have using an Nvidia GTX 780 as my gpu which has support for opengl 4.4. I've never done anything opengl related in java, so I don't know exactly what this here stack trace is trying to tell me. :)
Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Not a GL2 implementation
at jogamp.opengl.gl4.GL4bcImpl.getGL2(GL4bcImpl.java:37127)
at org.cef.CefClient$1.display(CefClient.java:112)
at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:588)
at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:572)
at javax.media.opengl.awt.GLCanvas$7.run(GLCanvas.java:1054)
at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1034)
at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:909)
at javax.media.opengl.awt.GLCanvas$8.run(GLCanvas.java:1065)
at javax.media.opengl.Threading.invoke(Threading.java:193)
at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:483)
at javax.media.opengl.awt.GLCanvas.paint(GLCanvas.java:537)
at sun.awt.RepaintArea.paintComponent(RepaintArea.java:264)
at sun.awt.RepaintArea.paint(RepaintArea.java:240)
at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:347)
at java.awt.Component.dispatchEventImpl(Component.java:4937)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:708)
at java.awt.EventQueue$4.run(EventQueue.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Original report by Anonymous.
Original issue 42 created by christophe.cornu on 2014-02-20T21:11:07.000Z:
What steps will reproduce the problem?
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 report by me.
Original issue 15 created by magreenblatt on 2013-10-31T21:11:50.000Z:
Windows 64-bit
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The application should remain responsive and clicking outside of the context menu should dismiss it. Instead, the context menu must be dismissed by selecting a menu item.
Original report by Anonymous.
Original issue 57 created by christophe.cornu on 2014-03-14T17:14:55.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Browser stops drawing. When its Canvas got removed from its hierarchy, AWT destroyed the Canvas native window handle and the child CEF window as well.
What version of the product are you using? On what operating system?
Latest jcef r31. Windows 7.
Please provide any additional information below.
When embedding the browser in an existing Swing app, the browser will commonly be moved to different hierarchies - e.g. when embedded inside a JTabbedPane, reordering tabs is implemented by removing the tab then adding it back. So a native widget has to deal with the possibility of its native parent window being destroyed by AWT and recreated later.
The workaround is to detect when the native Canvas peer is about to be destroyed (Component.removeNotify on our Canvas or our immediate Container parent) and recreated (Component.addNotify on our Canvas or its immediate Container parent). When that happens, park our CEF child window to an invisible window.
Here's what I use for Windows. If you have other thoughts on how to support this, feedback welcome :-)
CefBrowser_N.cpp
JNIEXPORT void JNICALL Java_org_cef_CefBrowser_1N_N_1SetParent
(JNIEnv *env, jobject obj, jobject parent) {
CefRefPtr browser = GetCefFromJNIObject(env, obj);
if(!browser.get())
return;
HWND parentHwnd = GetHwndOfCanvas(parent, env);
HWND hwnd = browser->GetHost()->GetWindowHandle();
SetParent(hwnd, parentHwnd);
}
CefBrowser_N.java
public final native void N_SetParent(Canvas parent);
ChromiumBrowser.java // that's my class that wraps up the CEF client in a consumable AWT widget
public class ChromiumBrowser extends Container {
...
static Frame reparentingHiddenFrame;
static Canvas reparentingHiddenCanvas;
...
cefClient = new CefClient(clientDelegate, false, osr);
Canvas canvas = cefClient.getCanvas();
setLayout(new BorderLayout());
add(canvas, BorderLayout.CENTER);
...
// Create a single hidden realized frame to serve as a placeholder
// for our CEF child windows when AWT destroys their parent peer
reparentingHiddenFrame = new Frame();
reparentingHiddenFrame.setSize(0,0);
reparentingHiddenCanvas = new Canvas();
reparentingHiddenFrame.add(reparentingHiddenCanvas);
reparentingHiddenFrame.addNotify();
public void addNotify() {
super.addNotify();
/\*\*
\* New native canvas peer is alive now.
\*/
/\*\*
\* off-screen-rendering mode simply draws to whatever current window we use. Nothing to do here.
\*/
if (osr)
return;
/\*\*
\* Reparent cef browser window to new parent canvas peer. Do nothing if cef browser
\* has not been created or has been destroyed.
\*/
CefBrowser cefBrowser = cefClient.getBrowser();
if (cefBrowser == null)
return;
setParent(cefClient.getCanvas());
}
public void removeNotify() {
/\*\*
\* Current native canvas peer is about to be destroyed
\*/
/\*\*
\* off-screen-rendering mode simply draws to whatever current window we use. Nothing to do here.
\*/
if (osr)
return;
/\*\*
\* Reparent cef browser window to a temporary parent canvas peer. Do nothing if cef browser
\* has not been created or has been destroyed.
\*/
CefBrowser cefBrowser = cefClient.getBrowser();
if (cefBrowser == null)
return;
/\*\*
\* Park the CEF Window to a different window that is not going to be destroyed
\*/
setParent(reparentingHiddenCanvas);
super.removeNotify();
}
void setParent(Canvas parent) {
CefBrowser cefBrowser = cefClient.getBrowser();
if (cefBrowser == null) {
throw new RuntimeException();
}
CefBrowser\_N cefBrowserN = (CefBrowser\_N)cefBrowser;
cefBrowserN.N\_SetParent(parent);
}
I'm sharing this approach in case you find this helpful. This is for Windows only, not Mac obviously.
With your CEF knowledge, do you know of particular issues of reparenting the CefBrowser->GetHost()->GetWindowHandle() handle to a different window? It seemed fine in my testing with CEF 3.1750.
Original report by me.
Original issue 22 created by magreenblatt on 2013-12-30T18:52:56.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The native context menu should display. Instead, no context menu is displayed.
Please use labels and text to provide additional information.
The GLCanvas.getNativeSurface() method is returning a valid NSView* as verified in Java_org_cef_CefContext_N_1GetWindowHandle. Additional exploration is required to determine why a context menu cannot be parented to this NSView*,
Original report by me.
Original issue 36 created by magreenblatt on 2014-02-03T16:07:50.000Z:
Implement support for routing aynchronous messages between JavaScript running in the renderer process and Java running in the browser process. See https://code.google.com/p/chromiumembedded/issues/detail?id=1183 for the underlying CEF implementation.
Original report by me.
Original issue 16 created by magreenblatt on 2013-10-31T21:13:29.000Z:
Windows 7 64-bit
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The top menu should always display in full. Instead, the top menu is sometimes clipped by the content area.
Original report by Anonymous.
Original issue 59 created by [email protected] on 2014-03-21T13:20:00.000Z:
Please see issue #55 for the overall plan.
Purpose: Added print support
This patch relies on the attached patch file of issue comment 55..
If you want to try these code changes, add the patch of issue comment 55. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch the missing method print() is added to the java class CefBrowser.
Original report by Chandra Koduru (Bitbucket: Chandra Koduru).
Original issue 20 created by kscraja on 2013-12-24T07:28:14.000Z:
I understand that there is no support for win32 versions.
I want to know..
Original report by Anonymous.
Original issue 48 created by [email protected] on 2014-03-08T07:57:12.000Z:
Purpose: Added additional handler CefCloadHandler
This patch relies on the attached patch file of issue comment 47..
If you want to try these code changes, add the patch of issue comment 47. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch, an additional cef handler
For CefLoadHandler an adapter class is provided which methods are empty.
CefClientHandler is extended by the methods
CefClient is extended by the methods
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 37 created by christophe.cornu on 2014-02-03T22:09:51.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
CefContext.cpp doesn't build
What version of the product are you using? On what operating system?
Latest - revision 25
Please provide any additional information below.
It's a typo with regard to the placement of the if defined(OS_MACOSX). There's a mismatch between { and } as a result. See patch though it's probably just as easy to fix it in the editor by hand.
BTW can you confirm you are using LLVM GCC 4.2 and not Apple's one?
Original report by Anonymous.
Original issue 11 created by bharati.gcet on 2013-05-02T06:06:14.000Z:
I want to use Chromium Embedded Framework in linux from where should I start.
Regards
Bharti
Original report by Anonymous.
Original issue 24 created by arnaud.brochard on 2014-01-06T12:56:37.000Z:
What steps will reproduce the problem?
Download and run latest distribution
What is the expected output? What do you see instead?
Expected behavior is a visible and blinking cursor on text fields. But no cursor is visible at all.
What version of the product are you using? On what operating system?
jcef_binary_3.1650.1501.9_windows64_preview
Windows 7 x64
JDK7u45 x64
Also tried with win32, same behavior
Please provide any additional information below.
In debug mode, the onCursorChange method of the MainFrame class is often called, but no cursor is visible
Original report by Anonymous.
Original issue 46 created by [email protected] on 2014-03-08T07:53:27.000Z:
Purpose: Split CefClientDelegate in several handlers to
get a more cef-like implementation.
This patch relies on the attached patch file of issue #.
If you want to try these code changes, add the patch of issue # first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch, the class CefClientDelegate is divided into the handler interfaces
For each of these interfaces an adapter class is provided which methods are empty.
CefClient is extended by the methods
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 12 created by agitechs on 2013-06-13T18:10:40.000Z:
How to become a contributor of this project? or should i create a new project?
Original report by me.
Original issue 21 created by magreenblatt on 2013-12-28T03:05:00.000Z:
What steps will reproduce the problem?
Run the JCEF demo on a MacBook Pro with Retina display
What is the expected output? What do you see instead?
Output rendered via JOGL should be hi-dpi. Instead, the output is not hi-dpi.
Please use labels and text to provide additional information.
Related JOGL issue: https://jogamp.org/bugzilla/show\_bug.cgi?id=741
Original report by Anonymous.
Original issue 60 created by [email protected] on 2014-03-21T13:20:48.000Z:
Please see issue #55 for the overall plan.
Purpose: Added search support
This patch relies on the attached patch file of issue comment 59..
If you want to try these code changes, add the patch of issue comment 59. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
With this patch the missing methods find() and stopFinding() are added to the
java class CefBrowser.
For testing this feature, a simple search dialog is added to the java class
MainFrame.
Original report by me.
Original issue 13 created by magreenblatt on 2013-10-31T21:09:10.000Z:
Add Linux support.
Original report by Anonymous.
Original issue 25 created by rover886 on 2014-01-11T05:04:15.000Z:
I want to develop an application in java which render an website.Can i use JCEF as API for this?
I tried new technology JavaFx of java 7 but it doesn't support plugins like flash etc.
And if i can use JCEF as API to build an java application then how to use API in netbeans?
Original report by Chandra Koduru (Bitbucket: Chandra Koduru).
Original issue 39 created by kscraja on 2014-02-17T12:35:31.000Z:
The sample (MainFrame.java) is based on SWING/AWT. I want to use jcef in SWT/eclipse.
I got it working by patching org.jcef.*.java files to make it work in eclipse/swt app.
I don't want to take that path though. It is un-maintainable.
Hence, request your comments on any other approach to the solution.
Using SWT-AWT bridge is showing blank white screen.
Regards,
Original report by Anonymous.
Original issue 54 created by [email protected] on 2014-03-08T08:12:31.000Z:
Purpose: Reorganize all java classes within a package structure.
This patch relies on the attached patch file of issue comment 53..
If you want to try these code changes, add the patch of issue comment 53. first and
afterwards add the patch file attached to this issue. Otherwise you'll get some patch-errors.
Due the last 9 patches have added several classes and changed existing code,
this patch only reorganizes the classes in the following java packages:
package org.cef
package org.cef.browser
package org.cef.handler
package org.cef.browser.mac
package tests
Please see attached patch file for further informations.
Original report by Anonymous.
Original issue 43 created by [email protected] on 2014-02-23T13:01:43.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The application should not crash while resizing.
What version of the product are you using? On what operating system?
Win 7 and Win XP
Please provide any additional information below.
Original report by Chandra Koduru (Bitbucket: Chandra Koduru).
Original issue 40 created by kscraja on 2014-02-17T12:40:36.000Z:
I am seeing some big changes in the code base.
I would like to know the next release dates(approx).
Since, there is no forum to discuss such matters, I am posting
it as a "issue". Forgive and please delete.
Regards,
Original report by me.
Original issue 18 created by magreenblatt on 2013-11-30T21:14:53.000Z:
The CEF context menu implementation on Linux currently requires that a GtkWidget be passed to CefWindowInfo::SetAsOffScreen(). With Java integration it's possible to get an X11 Window handle but no GTK widget (see Java_org_cef_CefContext_N_1GetWindowHandle in CefContext.cpp). Consequently context menu support in JCEF on Linux must wait until CEF moves from GTK to Aura.
Related CEF issue: https://code.google.com/p/chromiumembedded/issues/detail?id=180
Original report by Anonymous.
Original issue 30 created by [email protected] on 2014-01-15T10:32:11.000Z:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
I've modified the "jcef_app" target within jcef.gyp to create an usable App-Bundle instead of a dummy-bundle.
Therefore I've added the third party tool "appbundler" to the directory "src/third_party/appbundler".
Please add the attached JAR archive to this directory manually because it's not included within the plain-text diff file.
The appbundler is triggered by Apaches ANT which is already available on Mac OS X machines.
The build targets for ANT are defined within the new file "src/build.xml".
So, now if you run "gclient runhooks" and open afterwards the Xcode project, please use the target "All (jcef project)" to build jcef.
This will (a) compile jcef (b) compile java using ANT and (c) create an app-bundle using the appbundler via ANT.
There is no need any more to use the shell-scripts out of "src/tools/".
The application jcef_app.app can be found in src/xcodebuild/Debug/ and can be started by double-clicking it or with the terminal command "open".
Original report by Anonymous.
Original issue 28 created by arnaud.brochard on 2014-01-15T10:28:42.000Z:
What steps will reproduce the problem?
Download and run latest distribution
What is the expected output? What do you see instead?
Expected behavior is working navigation keys : arrows, tab, page down/up, home, etc.
What version of the product are you using? On what operating system?
jcef_binary_3.1650.1562_windows32
Windows 7 x64
JDK6u43
Please provide any additional information below.
Here's my patch to solve this issue. I tested arrow keys, tab, page down/up, home/end, text selection, etc. with success. Feel free to comment !
Original report by Anonymous.
Original issue 34 created by christophe.cornu on 2014-01-24T14:25:10.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Expect to see the web site rendered instead of blank
What version of the product are you using? On what operating system?
jcef_binary_3.1650.1501.9_windows64_preview.7z
Please provide any additional information below.
I understand the remote desktop scenario isn't necessarily high on everyone's agenda. And the goal isn't to have super high performance rendering over a remote session anyway. But note that this pb doesn't affect the native CEF client app nor of course the standalone Chrome browser. It's related to a call JCEF uses from JOGL.
When creating the GL Canvas from within a remote desktop session, MSFT uses an open gl driver that uses software, not hardware support (gl2.getContext().isHardwareRasterizer() is false). This doesn’t support some Open GL 2.0 features, among them support for npot textures – non power of two textures. JCEF gets a buffer from the rendering engine and renders it as an open gl texture of size (width,height) with the call glTexImage2D inside CefRender.onPaint. That call fails when using the emulated open gl MSFT driver. Same issue for glTexSubImage2D.
Here's the code that fails:
gl2.glTexImage2D(gl2.GL_TEXTURE_2D, 0, gl2.GL_RGBA, view_width_, view_height_, 0,
gl2.GL_BGRA, gl2.GL_UNSIGNED_INT_8_8_8_8_REV, buffer);
You can find out by starting MainFrame.java with the flag -Djogl.debug.DebugGL
You'll get this kind of exception:
javax.media.opengl.GLException: Thread[AWT-EventQueue-0,6,main] glGetError() returned the following error codes after a call to glTexImage2D( 0xDE1, 0x0, 0x1907, 0x310, 0x201, 0x0, 0x1907, 0x1401, <java.nio.Buffer> java.nio.DirectByteBuffer[pos=0 lim=1608768 cap=1608768]): GL_INVALID_VALUE ( 1281 0x501),
at javax.media.opengl.DebugGL4bc.writeGLError(DebugGL4bc.java:29412)
at javax.media.opengl.DebugGL4bc.glTexImage2D(DebugGL4bc.java:19877)
at org.cef.CefRenderer.onPaint(CefRenderer.java:253)
at org.cef.CefClient.onPaint(CefClient.java:259)
at org.cef.CefContext.N_DoMessageLoopWork(Native Method)
at org.cef.CefContext.doMessageLoopWork(CefContext.java:57)
at org.cef.MainFrame$1$1.run(MainFrame.java:41)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
This can be reproduced with a pure JOGL example (I can provide it if you wish). I've been searching about these open-gl texture calls and I wrote a horrible hack - turning the ByteBuffer RGBA received from onPaint into a new ByteBuffer RGB with 512x512 and got things to draw over remote desktop - albeit truncated of course.
I would appreciate any tip from a JCEF/CEF/JOGL/Open GL guru here :-)
Original report by Chandra Koduru (Bitbucket: Chandra Koduru).
Original issue 58 created by kscraja on 2014-03-19T08:26:10.000Z:
I am new to both jcef and cef.
I am looking for functions using which I can call javascript functions from jcef and vice-versa.
Before, I venture, I wanted to know..If it is possible at all !.
Please comment.
I went through docs published about the future of jcef. In of them, it is mentioned "CefRegistrar" will do the job.
It might be some time before all such things brought in place.
As of now, even a crude version of such feature will be of help to my work?.
Hence, the doubt.
Original report by Anonymous.
Original issue 44 created by arun.vc.kumar on 2014-03-02T16:23:11.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Application starts and the page loads in the background (checked the logs/println message for the title change function), but the browser frame is not visible.
What version of the product are you using? On what operating system?
jcef_binary_3.1650.1501.9_windows64_preview
Windows 7 x64
JDK7u51 x64
Please provide any additional information below.
Application starts, but the browser is not loaded in the JTabbedPane.
Original report by Anonymous.
Original issue 56 created by christophe.cornu on 2014-03-14T16:52:52.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
AWT/Swing destroys peers every time a widget is removed from its hierarchy. Browser widget should continue to draw fine after being moved to a different container / hierarchy.
What version of the product are you using? On what operating system?
Latest JCEF r31 but this has been a pb from beginning. Both Windows and Mac are affected.
Please provide any additional information below.
Workaround in OSR mode is to reinitialize the GL2 context everytime we get passed a new one.
CefRenderer.java
private Rectangle original_popup_rect_ = new Rectangle(0, 0, 0, 0);
protected void initialize(GL2 gl2) {
protected void onPaint(GL2 gl2,
boolean popup,
Rectangle[] dirtyRects,
ByteBuffer buffer,
int width,
int height) {
Original report by me.
Original issue 14 created by magreenblatt on 2013-10-31T21:09:35.000Z:
Add OS X support
Original report by Anonymous.
Original issue 33 created by [email protected] on 2014-01-24T11:03:31.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The switches/params should be passed to CEF, but this feature isn't implemented yet.
Please provide any additional information below.
So I've created a patch (see attached file) which forwards parameters from Java to CEF. You can pass all kind of params and switches (starting with -, -- or on Windows with /) to CEF now.
Please see attached patch file for details.
Original report by me.
Original issue 17 created by magreenblatt on 2013-10-31T21:16:09.000Z:
Windows 7 64-bit
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The resulting distribution should include CEF and JCEF version number information (for example, in the directory name and README.txt file). Instead, no version number information is included.
Original report by Anonymous.
Original issue 41 created by christophe.cornu on 2014-02-19T15:26:52.000Z:
What steps will reproduce the problem?
Download binary distribution jcef_binary_3.1650.1552.13_macosx64_preview.7z
sh compile.sh, sh run.sh
Browse around, resize main frame repeatedly, give focus in main frame and to other apps, repeat step 3.
What is the expected output? What do you see instead?
Things often crash after 30s in a few mac systems I have here while going through step 3.
What version of the product are you using? On what operating system?
jcef_binary_3.1650.1552.13_macosx64_preview.7z. I also see this pb with the latest jcef source code.
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Mac 10.8.5
Please provide any additional information below.
I'm attaching one of the crash reports. The crashes almost always appear in thread CrBrowserMain, but the trace itself varies from crash to crash. Trying to get the dsym info but no success currently.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.