| How to make Browser.setText to show the XHTML? [message #490115] |
Wed, 07 October 2009 08:29  |
Eclipse User |
|
|
|
I'm trying to show some SVG image inlined into the XHTML using the SWT.MOZILLA Browser.
It is impossible to do using Browser.setText because org.eclipse.swt.browser.Mozilla uses hardcoded text/html content type in the setText method.
text/html in Mozilla doesn't understand XHTML so the SVG tags are just ignored.
My question is how can I make org.eclipse.swt.browser.Mozilla to draw XHTML when I use setText method?
Known possible solution is to use XPCOM and create the setText method substitution which will use application/xhtml+xml content type. So I will be appreciated if somebody give me the snippet how to set content into the nsIWebBrowser from Java String.
I did try to look at the org.eclipse.swt.browser.Mozilla code but there was too complicated way to did that. Is there simplest way?
P.S. The way to store on the disk or so the page and then use Browser.setUrl is not acceptable for me.
Thanks in advance.
|
|
|
|
|
| Re: How to make Browser.setText to show the XHTML? [message #490427 is a reply to message #490215] |
Thu, 08 October 2009 11:43  |
| Eclipse User |
|
|
|
I see, it looks like a JavaXPCOM bug in xulrunner-1.8.1.3. The snippet in
the bug report works for me with xulrunner 1.9.0 and 1.9.1, but I see
problems with 1.8.1.3 as well. I can make it work with 1.8.1.3 by changing
the progress listener to the code below, its only problem is that it could
have a problem on 64-bit. If you don't care about running on 64-bit then
this should work for you. Alternatively, if you don't mind using xulrunner
1.9.x instead of 1.8.1.3 then you can revert to the JavaXPCOM-only solution
in the bug report. If neither of these apply then pick one ;-).
browser.addProgressListener(new ProgressAdapter() {
public void completed(ProgressEvent event) {
nsIServiceManager serviceManager =
Mozilla.getInstance().getServiceManager();
nsIIOService ioService =
(nsIIOService)serviceManager.getService("9ac9e770-18bc-11d3-9337-00104ba0fd4
0", nsIIOService.NS_IIOSERVICE_IID);
nsIURI uri = ioService.newURI("file:///", null, null);
nsIWebBrowser webBrowser = (nsIWebBrowser)browser.getWebBrowser();
nsIWebBrowserStream stream =
(nsIWebBrowserStream)webBrowser.queryInterface(nsIWebBrowser Stream.NS_IWEBBR
OWSERSTREAM_IID);
stream.openStream(uri, "application/xhtml+xml");
byte[] data = null;
try {
data = content.getBytes ("UTF-8"); //$NON-NLS-1$
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
/*
* JavaXPCOM in xulrunner 1.8.1.3 is not converting the byte[]
properly in the
* nsIWebBrowserStream.appendToStream() call. The workaround is to
revert to
* C++-level XPCOM for this call. JavaXPCOM converts this call
properly as of
* xulrunner 1.9.
*/
int /*long*/ ptr = C.malloc (data.length);
XPCOM.memmove (ptr, data, data.length);
int pageSize = 8192;
int pageCount = data.length / pageSize + 1;
int /*long*/ current = ptr;
long streamHandle = Mozilla.getInstance().wrapJavaObject(stream,
nsIWebBrowserStream.NS_IWEBBROWSERSTREAM_IID);
/*
* Note: the following line casts streamHandle to (int), which can
cause a
* pointer truncation on 64-bit.
*/
org.eclipse.swt.internal.mozilla.nsIWebBrowserStream
xpcomWebBrowserStream = new
org.eclipse.swt.internal.mozilla.nsIWebBrowserStream((int)/* 64*/streamHandle
);
for (int i = 0; i < pageCount; i++) {
int length = i == pageCount - 1 ? data.length % pageSize :
pageSize;
if (length > 0) {
int rc = xpcomWebBrowserStream.AppendToStream (current,
length);
if (rc != XPCOM.NS_OK) {
System.out.println("XPCOM Error: " +
Integer.toHexString(rc));
break;
}
}
current += pageSize;
}
stream.closeStream ();
C.free (ptr);
}
});
HTH,
Grant
"Alexander Ilyin" <a_ilyin@yahoo.com> wrote in message
news:haj1eo$71h$1@build.eclipse.org...
> Thank you for your answers.
>
> Its really should satisfy my needs. Something what I looking for. Thank
you.
>
> Just one problem. Your snippet does not work for me. :(
>
> Some problems with a stream. Mozilla gets data somewhere else. So I see
just a garbage or application even unexpectedly terminates.
>
> I just copy-past your snippet (Use another class name and package). Setup
the build path and add at the start of the main:
> System.setProperty("org.eclipse.swt.browser.XULRunnerPath", "path to the
xulrunner");
>
> XUL stuff(xullrunner and java xpcom plug-ins) I got from:
>
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releas es/1.8.1.3/contrib/eclipse/
>
> Using Eclipse 3.5
>
> What I did miss?
>
|
|
|
|
| Re: How to make Browser.setText to show the XHTML? [message #490634 is a reply to message #490616] |
Fri, 09 October 2009 10:08 |
| Eclipse User |
|
|
|
Actually XULRunner (including 1.8.1.3) does work well as a 64-bit app on
linux, but not on other OSs. It's not considered "official" because
mozilla.org does not produce/test 64-bit builds, but the linux distros all
do for inclusion in their 64-bit releases, and 64-bit swt uses them
successfully.
The last snippet had a problem in 64-bit because the creation of the swt
nsIWebBrowserStream had to use the result of the wrapJavaObject() call. The
constructor of SWT's internal nsIWebBrowserStream class changes between
swt's 32-bit and 64-bit releases (it takes an int in 32-bit and a long in
64-bit). JavaXPCOM's wrapJavaObject() method always returns a long, so to
use it with 32-bit swt it needs to be cast to an int, which is fine since
the truncated bits will all be 0's. However this is not safe with 64-bit
swt since the truncated bits may not be 0's, so in this case you want to
just pass the long value as-is to the constructor. But then this won't
compile with 32-bit swt because a nsIWebBrowserStream constructor that takes
a long does not exist there.
Grant
"Alexander Ilyin" <a_ilyin@yahoo.com> wrote in message
news:hana5b$q66$1@build.eclipse.org...
> Thank you very much for your helping.
>
> I like the option with 1.9.x branch if it will work. Best solution.
> Just waiting when Mozilla close this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=507575
>
> Anyway there is detailed description how to get 1.9.x. So it's real way
to resolve this issue.
>
> Regarding 64-bit... I will be very happy one day when I will be able to
run Mozilla in 64-bit mode :) Right now it is not yet possible.
> So this is not a problem for 1.8.1.3 because it never be 64-bit aware.
>
> Thank you for your great answers.
|
|
|
Powered by
FUDForum. Page generated in 0.03760 seconds
Home
Right now it is not yet possible.