ptykvin / javachromiumembedded Goto Github PK

This issue is an enhancement of JCEF (patch 3 of 10) 
----------------------------------------------------
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
- CefLifeSpanHandler
and the new handlers introduced by patch 1 (see issue #)
- CefDisplayHandler
- CefRenderHandler
- CefMessageRouterHandler
- CefFocusHandler

CefClientHandler is extended by the new methods
- CTOR (forwarded to JNI)
- DTOR (forwarded to JNI)
- abstract method getDisplayHandler() (called by JNI)
- abstract method getFocusHandler() (called by JNI)
- abstract method getLifeSpanHandler() (called by JNI)
- abstract method getMessageRouterHandler() (called by JNI)
- abstract method getRenderHandler() (called by JNI)
- protected method removeDisplayHandler() (forwarded to JNI)
- protected method removeFocusHandler() (forwarded to JNI)
- protected method removeLifeSpanHandler() (forwarded to JNI)
- protected method removeMessageRouterHandler() (forwarded to JNI)
- protected method removeRenderHandler() (forwarded to JNI)

For LifeSpanHandler an adapter class is provided which methods are empty. 
- CefLifeSpanHandlerAdapter
This class exists as convenience for creating handler objects.

CefClient is extended by the methods
- addLifeSpanHandler(CefLifeSpanHandler handler)
- removeLifeSpanHandler()
to add and remove the handler implementation to the client.

Please see attached patch file for further informations.

How to become a contributor of this project? or should i create a new project?

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

What steps will reproduce the problem?
1. Run the JCEF sample application.
2. Right click in the view.

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*,

What steps will reproduce the problem?
1. Get the latest JCEF and build it on Mac
2. Edit MainFrame.java so the controls appear at the bottom of the frame 
instead of the top.
    ///contentPanel.add(createControlPanel(), BorderLayout.NORTH);
    contentPanel.add(createControlPanel(), BorderLayout.SOUTH);
3. Run MainFrame (on Mac) with osr enabled

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

I want to use Chromium Embedded Framework in linux from where should I start.

Regards
Bharti

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".

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 !

Doesn't this project support linux?

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

What steps will reproduce the problem?
1. Execute the run.bat (with properly setted JDK_BIN)
2. I get the UnsatisfiedLinkError.

What do you see?
java.lang.UnsatisfiedLinkError: win32\libcef.dll: Can't load IA 32-bit .dll on 
a AMD 64-bit platform


What version of the product are you using? On what operating system?
windows 7, x64
jdk1.7.0_04



Any ideas how to solve this problem?

Windows 7 64-bit

What steps will reproduce the problem?
1. Run the make_distrib.bat script
2. Examine the resulting binary distribution

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.

This issue is an enhancement of JCEF (patch 4 of 10) 
----------------------------------------------------
Purpose: Added additional handler CefCloadHandler

This patch relies on the attached patch file of issue #47. 
If you want to try these code changes, add the patch of issue #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 
- CefLoadHandler 
is forwarded to jcef as well.

For CefLoadHandler an adapter class is provided which methods are empty. 
- CefLoadHandlerAdapter
This class exists as convenience for creating handler objects.

CefClientHandler is extended by the methods
- abstract method getLoadHandler() (called by JNI)
- protected method removeLoadHandler() (forwarded to JNI)

CefClient is extended by the methods
- addLoadHandler(CefLoadHandler handler)
- removeLoadHandler()
to add and remove the handler implementation to the client.

Please see attached patch file for further informations.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x43fb0000, pid=2804, tid=2164
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode, sharing windows-x86 
)
# Problematic frame:
# C  0x43fb0000
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x02b5a400):  VMThread [stack: 0x02c40000,0x02c90000] [id=2164]

siginfo: ExceptionCode=0xc0000005, reading address 0x43fb0000

Registers:
EAX=0x0e0c8378, EBX=0x00000000, ECX=0x0e04e3e0, EDX=0x43fb0000
ESP=0x02c8f578, EBP=0x0000000f, ESI=0x00000001, EDI=0x0e04e3e0
EIP=0x43fb0000, EFLAGS=0x00010202

Top of Stack: (sp=0x02c8f578)
0x02c8f578:   10301d9f 00000001 00000010 0e0b1c65
0x02c8f588:   00000000 00000000 00000000 034628c8
0x02c8f598:   02c8f5b4 7c930a36 00000078 034628c8
0x02c8f5a8:   03430000 03462830 03430000 03430000
0x02c8f5b8:   03430178 02c8f688 7c930981 03430608
0x02c8f5c8:   7c93005d 03462838 03462838 00000000
0x02c8f5d8:   0e300000 00000002 03462820 03430178
0x02c8f5e8:   00000000 03462828 00000000 0e06e5f0 

Instructions: (pc=0x43fb0000)
0x43faffe0:   
[error occurred during error reporting (printing registers, top of stack, 
instructions near pc), id 0xc0000005]

Register to memory mapping:

EAX=
[error occurred during error reporting (printing register info), id 0xc0000005]

Stack: [0x02c40000,0x02c90000],  sp=0x02c8f578,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x43fb0000

VM_Operation (0x0381ed70): Exit, mode: safepoint, requested by thread 0x03065000


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x00846800 JavaThread "DestroyJavaVM" [_thread_blocked, id=2912, stack(0x008e0000,0x00930000)]
  0x03065000 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=2616, stack(0x037d0000,0x03820000)]
  0x02ffd000 JavaThread "Thread-4" [_thread_in_native, id=2528, stack(0x03600000,0x03650000)]
  0x03001400 JavaThread "Thread-3" [_thread_in_native, id=3868, stack(0x03590000,0x035e0000)]
  0x02ffc000 JavaThread "Thread-2" [_thread_in_native, id=1940, stack(0x03650000,0x036a0000)]
  0x02c3f000 JavaThread "AWT-Shutdown" [_thread_blocked, id=2648, stack(0x02fa0000,0x02ff0000)]
  0x02c3d800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=2468, stack(0x02f50000,0x02fa0000)]
  0x02baa400 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3844, stack(0x02e20000,0x02e70000)]
  0x02ba7400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=2484, stack(0x02dd0000,0x02e20000)]
  0x02ba2400 JavaThread "Attach Listener" daemon [_thread_blocked, id=3836, stack(0x02d80000,0x02dd0000)]
  0x02bc2400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3244, stack(0x02d30000,0x02d80000)]
  0x02b9b400 JavaThread "Finalizer" daemon [_thread_blocked, id=1072, stack(0x02ce0000,0x02d30000)]
  0x02b96800 JavaThread "Reference Handler" daemon [_thread_blocked, id=2328, stack(0x02c90000,0x02ce0000)]

Other Threads:
=>0x02b5a400 VMThread [stack: 0x02c40000,0x02c90000] [id=2164]

VM state:at safepoint (shutting down)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x008457a8] Threads_lock - owner thread: 0x02b5a400

Heap
 def new generation   total 4928K, used 3745K [0x229e0000, 0x22f30000, 0x27f30000)
  eden space 4416K,  84% used [0x229e0000, 0x22d885a8, 0x22e30000)
  from space 512K,   0% used [0x22e30000, 0x22e30000, 0x22eb0000)
  to   space 512K,   0% used [0x22eb0000, 0x22eb0000, 0x22f30000)
 tenured generation   total 10944K, used 0K [0x27f30000, 0x289e0000, 0x329e0000)
   the space 10944K,   0% used [0x27f30000, 0x27f30000, 0x27f30200, 0x289e0000)
 compacting perm gen  total 12288K, used 647K [0x329e0000, 0x335e0000, 0x369e0000)
   the space 12288K,   5% used [0x329e0000, 0x32a81d68, 0x32a81e00, 0x335e0000)
    ro space 10240K,  51% used [0x369e0000, 0x36f0e338, 0x36f0e400, 0x373e0000)
    rw space 12288K,  55% used [0x373e0000, 0x37a7a070, 0x37a7a200, 0x37fe0000)

Code Cache  [0x00960000, 0x009f0000, 0x02960000)
 total_blobs=257 nmethods=56 adapters=137 free_code_cache=32985024 largest_free_block=0

Dynamic libraries:
0x00400000 - 0x00425000     C:\Program Files\Java\jre6\bin\javaw.exe
0x7c920000 - 0x7c9b6000     C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c91e000     C:\WINDOWS\system32\kernel32.dll
0x77da0000 - 0x77e49000     C:\WINDOWS\system32\ADVAPI32.dll
0x77e50000 - 0x77ee3000     C:\WINDOWS\system32\RPCRT4.dll
0x77fc0000 - 0x77fd1000     C:\WINDOWS\system32\Secur32.dll
0x77d10000 - 0x77da0000     C:\WINDOWS\system32\USER32.dll
0x77ef0000 - 0x77f39000     C:\WINDOWS\system32\GDI32.dll
0x76300000 - 0x7631d000     C:\WINDOWS\system32\IMM32.DLL
0x62c20000 - 0x62c29000     C:\WINDOWS\system32\LPK.DLL
0x73fa0000 - 0x7400b000     C:\WINDOWS\system32\USP10.dll
0x7c340000 - 0x7c396000     C:\Program Files\Java\jre6\bin\msvcr71.dll
0x6d7f0000 - 0x6da9f000     C:\Program Files\Java\jre6\bin\client\jvm.dll
0x76b10000 - 0x76b3a000     C:\WINDOWS\system32\WINMM.dll
0x6d7a0000 - 0x6d7ac000     C:\Program Files\Java\jre6\bin\verify.dll
0x6d320000 - 0x6d33f000     C:\Program Files\Java\jre6\bin\java.dll
0x6d7e0000 - 0x6d7ef000     C:\Program Files\Java\jre6\bin\zip.dll
0x6d000000 - 0x6d14c000     C:\Program Files\Java\jre6\bin\awt.dll
0x72f70000 - 0x72f96000     C:\WINDOWS\system32\WINSPOOL.DRV
0x77be0000 - 0x77c38000     C:\WINDOWS\system32\msvcrt.dll
0x76990000 - 0x76ace000     C:\WINDOWS\system32\ole32.dll
0x77180000 - 0x77283000 
    C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.26
00.6028_x-ww_61e65202\COMCTL32.dll
0x77f40000 - 0x77fb6000     C:\WINDOWS\system32\SHLWAPI.dll
0x5adc0000 - 0x5adf7000     C:\WINDOWS\system32\uxtheme.dll
0x6d230000 - 0x6d27f000     C:\Program Files\Java\jre6\bin\fontmanager.dll
0x74680000 - 0x746cc000     C:\WINDOWS\system32\MSCTF.dll
0x73640000 - 0x7366e000     C:\WINDOWS\system32\msctfime.ime
0x7d590000 - 0x7dd84000     C:\WINDOWS\system32\shell32.dll
0x4ad00000 - 0x4b789000     C:\WINDOWS\system32\icudt42.dll
0x10000000 - 0x10ee8000     C:\WINDOWS\system32\libcef.dll
0x4a410000 - 0x4a469000     C:\WINDOWS\system32\WINHTTP.dll
0x77bd0000 - 0x77bd8000     C:\WINDOWS\system32\VERSION.dll
0x71a20000 - 0x71a37000     C:\WINDOWS\system32\WS2_32.dll
0x71a10000 - 0x71a18000     C:\WINDOWS\system32\WS2HELP.dll
0x76bc0000 - 0x76bcb000     C:\WINDOWS\system32\PSAPI.DLL
0x76320000 - 0x76367000     C:\WINDOWS\system32\COMDLG32.dll
0x765e0000 - 0x76673000     C:\WINDOWS\system32\CRYPT32.dll
0x76db0000 - 0x76dc2000     C:\WINDOWS\system32\MSASN1.dll
0x03540000 - 0x03568000     C:\WINDOWS\system32\CefWrapper.dll
0x5ef10000 - 0x5efdc000     C:\WINDOWS\system32\opengl32.dll
0x68e20000 - 0x68e40000     C:\WINDOWS\system32\GLU32.dll
0x736d0000 - 0x7371b000     C:\WINDOWS\system32\DDRAW.dll
0x73b30000 - 0x73b36000     C:\WINDOWS\system32\DCIMAN32.dll
0x76eb0000 - 0x76eec000     C:\WINDOWS\system32\RASAPI32.DLL
0x76e60000 - 0x76e72000     C:\WINDOWS\system32\rasman.dll
0x5fdd0000 - 0x5fe25000     C:\WINDOWS\system32\NETAPI32.dll
0x76e80000 - 0x76eaf000     C:\WINDOWS\system32\TAPI32.dll
0x76e50000 - 0x76e5e000     C:\WINDOWS\system32\rtutils.dll
0x77c40000 - 0x77c65000     C:\WINDOWS\system32\msv1_0.dll
0x76760000 - 0x7676c000     C:\WINDOWS\system32\cryptdll.dll
0x76d30000 - 0x76d48000     C:\WINDOWS\system32\iphlpapi.dll
0x6d600000 - 0x6d613000     C:\Program Files\Java\jre6\bin\net.dll
0x6d620000 - 0x6d629000     C:\Program Files\Java\jre6\bin\nio.dll
0x6d350000 - 0x6d356000     C:\Program Files\Java\jre6\bin\jawt.dll
0x719c0000 - 0x719fe000     C:\WINDOWS\System32\mswsock.dll
0x76ef0000 - 0x76f17000     C:\WINDOWS\system32\DNSAPI.dll
0x76f90000 - 0x76f96000     C:\WINDOWS\system32\rasadhlp.dll
0x60fd0000 - 0x61025000     C:\WINDOWS\system32\hnetcfg.dll
0x71a00000 - 0x71a08000     C:\WINDOWS\System32\wshtcpip.dll
0x68d60000 - 0x68e01000     C:\WINDOWS\system32\dbghelp.dll

VM Arguments:
jvm_args: -Dfile.encoding=GBK 
java_command: org.limewire.cef.Main
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_31
PATH=C:/Program Files/Java/jre6/bin/client;C:/Program 
Files/Java/jre6/bin;C:/Program Files/Java/jre6/lib/i386;C:\Program 
Files\Intel\iCLS 
Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program 
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program 
Files\Intel\Intel(R) Management Engine Components\IPT;D:\Program 
Files\TortoiseSVN\bin;D:\Program Files\SSH Communications Security\SSH Secure 
Shell;E:\eclipse\eclipse-java-indigo-win32\eclipse;
USERNAME=Administrator
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 42 Stepping 7, GenuineIntel



---------------  S Y S T E M  ---------------

OS: Windows XP Build 2600 Service Pack 3

CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 42 stepping 7, 
cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht

Memory: 4k page, physical 2001464k(661480k free), swap 3939904k(2344580k free)

vm_info: Java HotSpot(TM) Client VM (20.7-b02) for windows-x86 JRE 
(1.6.0_32-b05), built on Apr  5 2012 13:50:34 by "java_re" with MS VC++ 7.1 
(VS2003)

time: Wed Jun 13 10:58:24 2012
elapsed time: 12 seconds

What steps will reproduce the problem?
1. Start the demo with run.bat win64 Release
2. Search for something on Google (page must be larger than viewport)
3. Scroll using the mouse wheel

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.

This issue is an enhancement of JCEF (patch 2 of 10)
----------------------------------------------------
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
- CefDisplayHandler
- CefRenderHandler
- CefMessageRouterHandler
- CefFocusHandler
to get the JCEF implementation closer to its JNI counterpart CEF.

For each of these interfaces an adapter class is provided which methods are 
empty. 
- CefDisplayHandlerAdapter
- CefRenderHandlerAdapter
- CefMessageRouterHandlerAdapter
- CefFocusHandlerAdapter
These classes exists as convenience for creating handler objects.

CefClient is extended by the methods
- addDisplayHandler(CefDisplayHandler handler)
- removeDisplayHandler()
- addFocusHandler(CefFocusHandler handler)
- removeFocusHandler()
- addMessageRouterHandler(CefMessageRouterHandler handler)
- removeMessageRouterHandler()
- addRenderHandler(CefRenderHandler handler)
- removeRenderHandler()
to add and remove the handler implementations to the client.

Please see attached patch file for further informations.

What steps will reproduce the problem?
1. Get the latest (revision 25), compile on Mac

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?

This issue is an enhancement of JCEF (patch 6 of 10) 
----------------------------------------------------
Purpose: Extending CefLifeSpanHandler by additional methods.

This patch relies on the attached patch file of issue #49. 
If you want to try these code changes, add the patch of issue #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 
- onBeforePopup()
- runModal()
- doClose()
- onBeforeClose()

Please see attached patch file for further informations.

see org.eclipse.swt.browser.ProgressListener
why not found in ecf.

What steps will reproduce the problem?
1. Run the sample java-cef-windows.launch
2. Resize the outermost window
3. The browser does not resize

What is the expected output? What do you see instead?
The browser component should also resize.. But it stays as is. Added a 
componentListener and tried to resize the component. The method 
N_SetWindowSize(width, height) is getting invoked in CefBrowser_N.java (setSize 
method), but the component itself does not change its size.

What version of the product are you using? On what operating system?


Please provide any additional information below.

Windows 64-bit

What steps will reproduce the problem?
1. Run the MainFrame application.
2. Right-click to display the context menu.

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.

What steps will reproduce the problem?
1. Download
2. Run compile.bat
3. Run run.bat

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)

Please allow to run CEF in Mac OS X 10.5 PPC with Java 1.6 (SoyLatte).

What steps will reproduce the problem?
1. Start JCEF and append switches or params to the run.[sh|bat] script.

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.

This issue is an enhancement of JCEF (patch 5 of 10) 
----------------------------------------------------
Purpose: Extending CefDisplayHandler by additional methods.

This patch relies on the attached patch file of issue #48. 
If you want to try these code changes, add the patch of issue #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 
- onTooltip()
- onStatusMessage()
- onConsoleMessage()

Please see attached patch file for further informations.

What steps will reproduce the problem?
1. Connect to a Windows box through remote desktop (e.g. Windows 7)
2. Start the JCEF MainFrame sample app from within that remote desktop session
3. App comes up but open gl area is rendered blank

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(<int> 0xDE1, 
<int> 0x0, <int> 0x1907, <int> 0x310, <int> 0x201, <int> 0x0, <int> 0x1907, 
<int> 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 :-)

Hi,
I am at the moment only focused on java and do not have visual studio etc.
Is this project discontinued? Or when will an update to incorporate the latest 
CEF version be expected?

Thanx for your efforts in advance
Maz

I understand that there is no support for win32 versions.

I want to know..
1) Is it impossible or
2) Does it need work to get it on win32.
   If so, where do I start. Any suggestions would help.

Add OS X support

What steps will reproduce the problem?
1. Set jdk_directory within environment variable GYP_DEFINES to the Java7 JDK 
(instead of Java6 framework path)

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" 

2. gclient runhooks
3. open Xcode project and try to build All(jcef project)

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

What steps will reproduce the problem?
1. Run the JCEF sample application on Mac.
2. Select an option from the application or dock menu.

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 #1: tid = 0x1c03, 0x00007fff5fc01028 dyld`_dyld_start, stop reason = 
exec
    frame #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 #30: tid = 0x3d03, 0x00000001030adc35, stop reason = signal SIGSEGV
    frame #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 #30: tid = 0x3d03, 0x00000001030adc35, stop reason = signal SIGSEGV
    frame #0: 0x00000001030adc35
    frame #1: 0x0000000103006233
    frame #2: 0x0000000103006058
    frame #3: 0x0000000103006233
    frame #4: 0x0000000103006058
    frame #5: 0x0000000103006058
    frame #6: 0x0000000103006058
    frame #7: 0x0000000103006233
    frame #8: 0x0000000103006058
    frame #9: 0x0000000103006233
    frame #10: 0x0000000103006233
    frame #11: 0x00000001030004e7
    frame #12: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
    frame #13: 0x00000001012d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
    frame #14: 0x000000010130a605 libjvm.dylib`jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 698
    frame #15: 0x00000001012fc2cd libjvm.dylib`jni_CallObjectMethodV + 174
    frame #16: 0x0000000101aed42d JavaNativeFoundation`JNFCallObjectMethod + 170
    frame #17: 0x000000011649aa64 libosxui.dylib`Java_com_apple_laf_ScreenPopupFactory__1getHeavyWeightPopup + 89
    frame #18: 0x0000000103012698
    frame #19: 0x0000000103006233
    frame #20: 0x0000000103006233
    frame #21: 0x0000000103006233
    frame #22: 0x0000000103006233
    frame #23: 0x0000000103006058
    frame #24: 0x0000000103006058
    frame #25: 0x0000000103006058
    frame #26: 0x0000000103006706
    frame #27: 0x0000000103006058
    frame #28: 0x0000000103006058
    frame #29: 0x0000000103006058
    frame #30: 0x0000000103006058
    frame #31: 0x0000000103006706
    frame #32: 0x0000000103006058
    frame #33: 0x0000000103006058
    frame #34: 0x0000000103006058
    frame #35: 0x0000000103006058
    frame #36: 0x0000000103006058
    frame #37: 0x0000000103006058
    frame #38: 0x0000000103006058
    frame #39: 0x0000000103006058
    frame #40: 0x0000000103006350
    frame #41: 0x0000000103006350
    frame #42: 0x0000000103006058
    frame #43: 0x0000000103006058
    frame #44: 0x0000000103006058
    frame #45: 0x0000000103006058
    frame #46: 0x0000000103006058
    frame #47: 0x0000000103006233
    frame #48: 0x00000001030004e7
    frame #49: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
    frame #50: 0x00000001012d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
    frame #51: 0x000000010132a444 libjvm.dylib`JVM_DoPrivileged + 1041
    frame #52: 0x0000000103012698
    frame #53: 0x0000000103006233
    frame #54: 0x0000000103006233
    frame #55: 0x00000001030068e1
    frame #56: 0x0000000103006233
    frame #57: 0x00000001030004e7
    frame #58: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
    frame #59: 0x00000001012d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
    frame #60: 0x000000010132a444 libjvm.dylib`JVM_DoPrivileged + 1041
    frame #61: 0x0000000103012698
    frame #62: 0x0000000103006233
    frame #63: 0x00000001030068e1
    frame #64: 0x0000000103006058
    frame #65: 0x0000000103006058
    frame #66: 0x0000000103006058
    frame #67: 0x0000000103006058
    frame #68: 0x0000000103006058
    frame #69: 0x0000000103006058
    frame #70: 0x00000001030004e7
    frame #71: 0x00000001012d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
    frame #72: 0x00000001012d72a7 libjvm.dylib`JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 283
    frame #73: 0x00000001012d73e4 libjvm.dylib`JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
    frame #74: 0x00000001013263ca libjvm.dylib`thread_entry(JavaThread*, Thread*) + 173
    frame #75: 0x00000001014efb47 libjvm.dylib`JavaThread::thread_main_inner() + 155
    frame #76: 0x00000001014f124f libjvm.dylib`JavaThread::run() + 419
    frame #77: 0x000000010141b1c6 libjvm.dylib`java_start(Thread*) + 294
    frame #78: 0x00007fff845e8742 libsystem_c.dylib`_pthread_start + 327
    frame #79: 0x00007fff845d5181 libsystem_c.dylib`thread_start + 13

Should support js asynchronous execution.

What steps will reproduce the problem?
1. Run MainFrame.java on Windows. Go to 
http://cssdeck.com/labs/simple-css3-3d-cube
2. Notice only one side of the cube is drawn
3. Start cefclient.exe (CEF) and go to same URL. It draws the full cube 
correctly.

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...

What steps will reproduce the problem?
1. Download binary distribution jcef_binary_3.1650.1552.13_macosx64_preview.7z

2. sh compile.sh, sh run.sh
3. 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. 

This issue is an bugfix for JCEF (patch 1 of 10)
------------------------------------------------

What steps will reproduce the problem?
1. Set some kind of java-library path
2. Start jcef MainFrame app

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

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,

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

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,

Windows 7 64-bit

What steps will reproduce the problem?
1. Run the MainFrame application.
2. Display the top menu.

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.

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.

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?

What steps will reproduce the problem?
1. Download and run latest distribution
2. Use the attached source code to test the browser in JTabbedpane

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.

What steps will reproduce the problem?
1. Run the sample java-cef-windows.launch
2. Click the download button on web site.
3. There is nothing happend,,,

What is the expected output? What do you see instead?
I want to download file,, and open to save file dialog.

What version of the product are you using? On what operating system?
windows7

Please provide any additional information below.

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 #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 #31. 
If you want to try these code changes, add the patch of issue #31 first and 
afterwards add the patch file attached to this issue. Otherwise you'll get some 
patch-errors.

Add Linux support.

What steps will reproduce the problem?
1. Start the Test Application in none offscreen-rendering mode (on windows) 
2. Rapidly resize the frame until it crashes
3. The VM will crash or the AWT thread will become unresponsive and the Java UI 
won't update . 

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.

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.

What steps will reproduce the problem?
Error   1   error C3861: 'GetJavaWindowHandle': identifier not 
found   c:\users\murali\documents\visual studio 
2008\projects\project2\native\src\cefbrowser_n.cpp  161 CefWrapper
What is the expected output? What do you see instead?

what is "GetJavaWindowHandle"...?

What version of the product are you using? On what operating system?


Please provide any additional information below.

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 #15, #16, #22, #23 ,#24, #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)

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).