Re: [platform-swt-dev] SWT browser

[Mike Wilson <Mike_Wilson@xxxxxxxxxx>]

The fact that the method is "doubleValue" makes me think it's something related to autoboxing.

McQ.

Grant Gayed---2011/02/11 10:35:54---Hi Dermot,

From:	Grant Gayed/Ottawa/IBM@IBMCA
To:	"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
Date:	2011/02/11 10:35
Subject:	Re: [platform-swt-dev] SWT browser

---

Hi Dermot, 

#1 - I don't see this, but our cases may be different.  Behaviours like this should be consistent across the Browser implementations, so please log a report for this and provide a means of reproducing the error.  You can probably just use http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet128.java?view=co and specify a specific url to navigate to initially. 

#2 - Like Scott said, this is very strange.  If you are able to make a reproducible case of it then please log a bug.  Without a case that can be reproduced here it will be impossible to fix this, as I've never heard of it before. 

#3 - Keyboard focus generally works well in Browsers, but it's possible that the use of AWT in your context is causing some confusion.  Again, please log a report with a snippet that shows the problem. 

#4 and #5 - See http://www.eclipse.org/swt/faq.php#browserapplets to start.  The WebKit-based Browser on OS X disables applets because the Java plug-in's attempt to launch a JVM to run the applet collides with the JVM that's already running SWT/Eclipse, and crashes.  You'll notice in the FAQ that there are some specific contexts where a Browser will display applets, but what differentiates these contexts is that they always launch the JVM for running the applet out-of-process, which avoids the JVM collision that occurs otherwise. 

Regarding Browser.getWebBrowser() returning something from WebKit, this is not something we would do because we don't expose objects without well-defined API.  WebBrowser subclasses utilized by Browser are internal implementation, and do not expose public methods that are not already accessible indirectly via Browser API. 

Grant

"Dermot Doherty" <dermot@xxxxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx

10/02/2011 09:21 PM

Please respond to
"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>

To	"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-swt-dev] SWT browser

Thanks Scott. Yes, lots of good info here.

#4 - SWT WebKit disabling Java - It would be good to look into removing that 
for the Mac Cocoa WebKit implementation and also the Windows WebKit 
implementation. I tested a simple applet on Windows WebKit and Mac WebKit 
and yes, without the Java being enabled, applets do not work. I suspect that 
applets should work, given that applets work in Mac Safari which uses the 
same Cocoa based WebKit. Applets also work in Windows Safari, so technically 
applets should work in the Windows SWT WebKit browser also.

I am not sure if this is possible, but would it be possible to return a 
handle on the WebKit object when calling Browser.getWebBrowser() from a 
WebKit style Browser widget, just as calling Browser.getWebBrowser() returns 
a handle on the JavaXPCOM nsIWebBrowser object when using Mozilla.

Browser.getWebBrowser() returns Object, so that object could be the 
nsiWebBrowser object or the WebKit object depending on the browser style.

Something like this for Mozilla:

       nsIWebBrowser webBrowser = (nsIWebBrowser)browser.getWebBrowser();

and this for WebKit:

       WebKit webBrowser = (WebKit)browser.getWebBrowser();

It would be nice to get a handle on that WebKit object to take advantage of 
more in-depth browser features (like enabling/disabling Java as per a users 
preference).

Dermot

----- Original Message ----- 
From: "Scott Kovatch" <skovatch.swt@xxxxxxxxx>
To: "Eclipse Platform SWT component developers list." 
<platform-swt-dev@xxxxxxxxxxx>
Sent: Thursday, February 10, 2011 6:13 PM
Subject: Re: [platform-swt-dev] SWT browser


>I can answer a few of these, but Grant will likely need to answer some of 
>them.
>
> On Feb 10, 2011, at 3:05 PM, Dermot Doherty wrote:
>
>> 2) Both Mozilla and WebKit on Mac throw a "java.lang.NoSuchMethodError: 
>> doubleValue". It is difficult to pinpoint exactly where this is 
>> occurring, but it seems to happen when I create a new SWT browser 
>> instance.
>> This is not happening on Windows.
>> See the log output below:
>> java.lang.NoSuchMethodError: doubleValue
>> at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
>> at org.eclipse.swt.widgets.Display.applicationSendEvent(Unknown Source)
>> at org.eclipse.swt.widgets.Display.applicationProc(Unknown Source)
>
> Given that it's java.lang.NoSuchMethodError that makes me think we're 
> using reflection somewhere but the object we invoke it on doesn't have 
> that method. But, I don't see any uses that call doubleValue. It's 
> especially odd to see it during objc_msgSendSuper. Check Console.app to 
> see if you're getting any additional information.
>
> If you have a simple test case that can reproduce it, please file a bug.
>
>>  4) SWT WebKit browser on Mac disables Java when embedded in Safari.
>> Explanation: When a SWT WebKit Browser is embedded in a Java applet on 
>> Mac the "Enable Java" preference gets disabled. This is not happening 
>> when the Mozilla engine is used.
>> Is there something in the WebKit implementation that automatically 
>> disables Java that may be getting picked up by Safari which is also using 
>> the same WebKit engine. This only happens for the first SWT WebKit 
>> browser that is embedded. Subsequently embedded SWT WebKit browsers on 
>> the same page do not disable the Java (after manually enabling the Java 
>> in Preferences > Security).
>
> See WebKit.java:
>
> WebPreferences.standardPreferences().setJavaEnabled(false);
>
> But, it's only called once during initialization. I suspect 
> standardPreferences() are per-user, so it makes sense that turning it on 
> again in Java Preferences would enable it again for any additional Browser 
> widgets created.
>
> This is probably a holdover from Carbon. I seem to recall a situation 
> where you could end up embedding Cocoa (WebKit) into Carbon and then 
> somehow putting a Carbon view into the Browser. And you can't mix Carbon 
> and Cocoa that way, so it makes sense to block applets. In Cocoa there may 
> not be a reason to prevent that.
>
>> 5) Do Java Applets run in the SWT WebKit browser?
>
> I don't know that we've ever tried. On the Mac it may work now in Cocoa, 
> but you'd have to rebuild the SWT to try it out.
>
> Hope some of that helps.
>
> -- Scott K.
>
> ------------------
> Scott Kovatch
> IBM
> Eclipse Platform Team
> Pleasanton, CA
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev 

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev