Bug 38745 – Java bridge type conversions are incorrect

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Java

[Ben Murdoch]

If you try to pass a JS String over the jni bridge to a char in Java, then we try to convert the string to a number and pass that result to java. This behavior is correct except in the case that the JS String is one character long, in which case we should just pass the character itself without trying to convert to a number.

Patch and layout test to follow.

[Ben Murdoch]

Created attachment 55383 [details]
Patch and layout test.

[Alexey Proskuryakov]

I do not know why the new behavior is correct. There are several incompatible JNI specifications, and incompatible implementations. What are our reasons to make this change?

It's surprising that existing tests aren't affected by this change.

[Ben Murdoch]

(In reply to comment #2)
> I do not know why the new behavior is correct. There are several incompatible
> JNI specifications, and incompatible implementations. What are our reasons to
> make this change?
> 

I noticed the current behavior while working on the V8 JNI bridge for Android - when passing a single character string from JS, Java was getting a garbage value in both JSC and V8. I tried the same test with Firefox, and they seem to use the behavior that this patch would provide. It also seems to follow the spec outlined in http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html for conversion of JS Strings to Java chars. Perhaps there is a different spec that WebKit adopted for these type conversions, I'm not sure.

> It's surprising that existing tests aren't affected by this change.

I must admit I was surprised also. As far as I could tell though, the current tests don't verify the case where a single character is passed into Java from JS, just that a single character can be *returned* to JS, which works fine.

[Alexey Proskuryakov]

I believe that the latest and greatest spec is at <https://jdk6.dev.java.net/plugin2/liveconnect/>. The driver for changes is a need to implement LiveConnect over NPAPI for out of process implementations. Also, current browsers don't match LiveConnect 3 in many cases anyway, so there is a need to converge on sensible and compatible behavior.

> Perhaps there is a different spec that WebKit adopted for these type conversions, I'm not sure.

WebKit behavior is probably close to LiveConnect 2, but with modifications to match other browsers and specs. It's definitely not cast in stone.

[Ben Murdoch]

(In reply to comment #4)
> I believe that the latest and greatest spec is at <https://jdk6.dev.java.net/plugin2/liveconnect/>. The driver for changes is a need to implement LiveConnect over NPAPI for out of process implementations. Also, current browsers don't match LiveConnect 3 in many cases anyway, so there is a need to converge on sensible and compatible behavior.
> 
> > Perhaps there is a different spec that WebKit adopted for these type conversions, I'm not sure.
> 
> WebKit behavior is probably close to LiveConnect 2, but with modifications to match other browsers and specs. It's definitely not cast in stone.

Thanks for the pointer to that doc. I'll remove the review flag while I have a read and investigate what the other browsers do in this case and then I'll report back.

Thanks, Ben

[Steve Block]

After discussion with Ben, I'm broadening this bug to track general conversion problems in the Java bridge

[Steve Block]

One particular example from http://code.google.com/p/android/issues/detail?id=16311 - when a Java Object is passed to a method expecting java.lang.String, we should call toString() on the Object.

[Steve Block]

That last link should have been http://code.google.com/p/android/issues/detail?id=16312

http://code.google.com/p/android/issues/detail?id=16311 describes a related problem when a JavaScript string is passed to a method expecting a Java Object, we should pass a new java.lang.String object.

[Ahmad Saleem]

NPAPI support is removed from Safari 14 onward and it is not supported in Webkit Builds like WebkitGTK as well. I think this can be marked as "RESOLVED WONTFIX". Thanks!

Further, Java plugin support was removed even earlier in Safari 12. Also, Comment 08 is WONTFIX from Google as well. Thanks!

[Ryosuke Niwa]

Yup, won't fix.