Skip to main content

About the new feature of JDIC Browser

5 replies [Last post]
sdossantos
Offline
Joined: 2006-02-17
Points: 0

Hello,
I would like to know if you envisaged to add new functionality to the browser such as the invocation of Javascript since a java method like callJavaScript(String functionName, String[ ] functionArgs) or the possibility to load HTML Content to the browser since a java method like loadHtmlContent(String newContent)

In my opinion this new feature can be useful for the browser usage.

Sincerely,
S�bastien DOS-SANTOS

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
georgez
Offline
Joined: 2003-08-19
Points: 0

Hi,

There are no such planed new functionalities at the moment. Currently, the Browser component supports HTML pages containing Javascript, but no API for invocation of Javascript.

As to loading HTML content, I feel there is a workaround: generate a temp .html file with the HTML content, and display it.

-George.

obijohn
Offline
Joined: 2005-02-18
Points: 0

Hi George, the ability to load raw HTML instead of only via a URL is more interesting than you might think.

Saving to a temp file and loading it via a URL would work except that the HTML likely has relative paths to images and the like. These would break...

So if I scoop some HTML via my own code and want to render it via a Browser w/o having to parse and mod the HTML on the fly, I'd need a feature as was requested.

Without this, the Browser would be dimished to doing no more than rendering static HTML, like a way to launch into documentation. It would be very difficult to use in a dynamic HTML type mode.

Hope this makes sense.
John

klm
Offline
Joined: 2004-07-16
Points: 0

> Saving to a temp file and loading it via a URL would
> work except that the HTML likely has relative paths
> to images and the like. These would break...

Use base href at the beginning of the document to resolve relative URLs.

The temp file approach works, but for it to be completely feasible, Java must be able to do HTTP through the browser -- for the browser to handle cookies, HTTP authentication, HTTPS, etc. Otherwise the host Java program and the embedded browser are essentially two completely separate HTTP clients that have to do everything twice and under different infrastructures (passwords, certificates).

HTTP delegation to browser is vital even without HTML modification on the fly. For example, we need to make SOAP requests to the server that we're browsing in the embedded browser, and the authentication is cookie-based with an HTML login page (Yahoo style). There is no other way to log in except by displaying the login page from the server -- in the embedded browser. The user logs in, the browser remembers the cookies, but alas we still can't make our SOAP requests from Java, because Java's HTTP handler knows nothing about these cookies.

obijohn
Offline
Joined: 2005-02-18
Points: 0

Hi and thanks for your response.

For our needs, it looks best to have WebBrowser actually do the http work.

However, we would need access to the actual HTML that comes down that is rendered. I see a WebBrowserEvent but it looks like the data field of that event class is just the URL.

Do you have any thoughts about getting at the actual HTML from the native browser?

Thanks!
John

klm
Offline
Joined: 2004-07-16
Points: 0

What would best suit your needs API-wise depends on what you need to accomplish.

If you want to be able to modify an already rendered page (e.g. based on user input in the host Java app), then you would be better off with DOM access, something like Mozilla Webclient is supposed to provide. I am saying "supposed", because as of now it's in the midst of a catchup with recent Mozilla releases. I think DOM access was mentioned at some point as one of the future goals for JDIC under consideration.

If you want to modify the HTML *before* it gets rendered, then you probably want to download the page yourself (with HTTP done through the browser), do whatever you need to do with it independent of the browser, save it to disk, and make the browser load it from disk (or do the more fancy footwork of streaming it to the browser).

If it's the latter, the HTTP API could theoretically be WebBrowserEvents, but a much cleaner way for JDIC to do this is to provide browser-based protocol handlers (http, https, ftp), so that the Java code may use regular java.net.* and java.io.* API for HTTP exchange through the browser transparently. That would be major new functionality for JDIC, and JDIC's underlying IPC protocol between the VM and the Mozilla executable does not really support this type of exchange right now: currently it's based on newline-terminated ISO-8859-1 strings, while this requires passing arbitrary binary data. As you can imagine, a change at the protocol and message exchange API level would imply changes in quite a few other places on both Java and C++ sides. So I wouldn't expect this to happen any time soon, if ever.

On my spare time, I am playing with just this kind of protocol changes -- a header {message length in bytes, message type} followed by message-specific data. I am going to offer it for review once it's at a state that the existing JDIC functionality works with it. Depending on the feedback I get, it may make sense to continue the work on JDIC, or abandon it and forget about it, and just wait for Webclient to rise back from the ashes and help them out with testing and fixes.

The thing with Webclient is that there is no IPC -- Mozilla (as well as IE) is loaded in-process into the VM. This has its pluses (easier+faster Java-C++ communication) and minuses (trickier UI library work, potentially more problematic platform porting, impossible to recover from a browser crash), but I tend to think the pluses outweigh the minuses when it starts working -- and that's the big question:). JDIC has daytime developers committed to it, while Webclient doesn't have that kind of backing.