java-cef | A simple framework | Plugin library
kandi X-RAY | java-cef Summary
kandi X-RAY | java-cef Summary
CEF is a BSD-licensed open source project founded by Marshall Greenblatt in 2008 and based on the Google Chromium project. Unlike the Chromium project itself, which focuses mainly on Google Chrome application development, CEF focuses on facilitating embedded browser use cases in third-party applications. CEF insulates the user from the underlying Chromium and Blink code complexity by offering production-quality stable APIs, release branches tracking specific Chromium releases, and binary distributions. Most features in CEF have default implementations that provide rich functionality while requiring little or no integration work from the user. There are currently over 100 million installed instances of CEF around the world embedded in products from a wide range of companies and industries. A partial list of companies and products using CEF is available on the CEF Wikipedia page. Some use cases for CEF include:. CEF supports a wide range of programming languages and operating systems and can be easily integrated into both new and existing applications. It was designed from the ground up with both performance and ease of use in mind. The base framework includes C and C++ programming interfaces exposed via native libraries that insulate the host application from Chromium and Blink implementation details. It provides close integration between the browser and the host application including support for custom plugins, protocols, JavaScript objects and JavaScript extensions. The host application can optionally control resource loading, navigation, context menus, printing and more, while taking advantage of the same performance and HTML5 technologies available in the Google Chrome Web browser. This project provides a Java Wrapper for CEF (JCEF).
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Create the canvas
- Creates the browser if required
- Renders the view
- Initialize the OpenGL context
- Returns a String representation of this request
- Returns a string representation of this object
- Returns a string representation of the post data
- Called when the canvas is painted
- Called when the view is painted
- Returns the view bounds for the given browser
- Returns the real screen point
- Returns a string representation of the configuration
- Invoked when a termination of a terminal
- Close this window
- Handles a cursor change
- Drop target drop
- Close the dev tools
- Returns the window handler for the given browser
- Processes a Cef command line
- Creates a new client instance
- Do the actual update
- Reform focus on the next window
- Creates a screenshot of the browser
- Returns the window ID of the specified component
- Returns a String representation of the response
- Called when the mouse is dragging
java-cef Key Features
java-cef Examples and Code Snippets
Community Discussions
Trending Discussions on java-cef
QUESTION
I have created an application using JCEF. My application is using the localstorage for saving its settings. The problem I'm seeing, is that each time the application is closed, and restarted, all the data in the localstorage is discarded. I have tested using the CEFSimple app from multiple versions, (see my ticket here https://bitbucket.org/chromiumembedded/java-cef/issues/386/localstorage-is-empty-after-application), and the same problem is reproduced. So I'm suspecting a missing setting somewhere. Does anybody know, what is missing or can confirm this is a bug ?
...ANSWER
Answered 2020-Oct-26 at 17:39I identified the root cause for this issue: the problem happens when setting a relative path in cache_path
inside CefSettings
. When I changed to an absolute path, the issue disapparead.
QUESTION
I recently integrated the Java Chromium Embedded Framework (https://github.com/chromiumembedded/java-cef) in a Netbeans (RCP) Application Project (Java: JDK11).
The Browser Window is shown in a Netbeans TopComponent and generally works just fine.
However I have several rather small, but nasty bugs that I noticed which are always following the same pattern: Whatever code I execute that concerns the jcef browser always only works when I execute it a second time and is all but ignored the first time around. However there are no error messages or logs or any thing like that and the code seems to be executed when I go through it with the debugging tool.
Three examples:
- Implementing a return button:
This just checks whether the CefBrowser instance returnstrue
forbrowser.canGoBack()
. If it returnstrue
a button is activated.
The value starts correctly atfalse
, but it returns true just after the second change of url.(Should obviously happen after the first)
From there on out it works just fine....Unless you go back (with the return button) to the home page. It should then obviously returnfalse
again - Which it doesn't.
Calling a different URL again returnsfalse
forcanGoBack()
(which should then obviously betrue
) and only returnstrue
after the second URL change again.
So the return fromcanGoBack
always shows the return it should have shown from its previous execution, as if lagging behind one time. - Implementing a "go to" function:
This function just takes you to a specified other website than the home page. Again works fine from the 2nd time onwards, but the first time the code is simply ignored. (although I confirmed via Debugger that the code is executed without errors even the first time around) - Implementing a login dialog:
If the browser notices that authentication is required, this opens up a dialog where the user can enter BASIC credentials.
And again the dialog gets opened, the credentials are returned correctly (confirmed via Log), are handed over to the appropriate function and it works for the second try but not the first. (credentials were identical)
Indeed I confirmed via Wireshark, that the first time thatcallback.Continue(ad.getUsername(), ad.getPassword());
is executed, nothing at all is actually send to the server...
Code for the third example:
...ANSWER
Answered 2020-Oct-12 at 09:32I found the answer(s) to the afore mentioned questions. In case someone else will stumble upon similar issues in the future I'm going to shortly summarize what fixed it for me.
Apparently most of the problems I faced arose from threading problems. It seems like when you execute a command on the jcef browser while it's thread is still working on something, your command will not be executed, but there also won't be any error messages or other unwanted behaviour.
Example for the second problem:
When the go(url)
command was executed the browser had not finished loading the initial home page completely yet. That's why the command was ignored.
To fix this I added a simple String variable that will save the URL that someone wants to load until the browser has finished loading the previous page.
Only then will this url be loaded in the browser and consequently be deleted from the variable.
This could of course also be done with something like a list, but I can't think of a scenario where that would be useful.
Checking weither browser is done loading should be done in the overridden method onLoadingStateChange
of the CefLoadHandlerAdapter
.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install java-cef
You can use java-cef like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the java-cef component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page