Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 12245 [details]
Simple sample app to reproduce
More precisely, when trying to use any of the members of the JSValue class, it reports various errors - selector not found / NotSupportedException etc.
When debugging, it seems the jsValue.Class.Name values at runtime of the JSValue objects verify that the native objects are indeed not JSValue objects, but __NSCFNumber and __NSDictionaryM (see attached example).
The attached example shows a test case which should reproduce the problem.
Any clues how to solve/work around this? This seems like a bug in the way the the Xamarin middleware wraps the calls.
By the way I created similar code in Swift which worked right out of the box.
This is how my custom object is implemented:
interface IMyCustomObject : IJSExport
void Hello(JSValue val);
void CallMeBack (JSValue callbackFunc);
public class MyCustomObject : NSObject, IMyCustomObject
public void Hello (JSValue val)
//This will print out __NSCFNumber
Debug.WriteLine ("Class of val: " + val.Class.Name);
//This will fail, saying there is no selector isNumber
Debug.WriteLine("Is a number");
Debug.WriteLine("Is not a number");
public void CallMeBack (JSValue callbackFunc)
//This will print out __NSDictionaryM
Debug.WriteLine ("Class of callbackFunc: " + callbackFunc.Class.Name);
And this is how it's called:
var jsContext = new JSContext ();
var customObject = new MyCustomObject ();
jsContext.GlobalObject.SetProperty (customObject, "customObject");
To make a guess, I would not be too surprised if a corresponding Xcode app might hit the same problem. If any user seeing this issue would like to help investigate that possibility, you can attach a line-by-line port of the original test case into Objective-C (or Swift). That would improve the chances that the bug will receive additional attention soon. I will set the bug status to NEEDINFO to indicate that that additional test case would be helpful. Thanks!
## Possible workaround
In the mean time, my quick tests showed that the following change seemed to produce the desired outcome.
> if (val.IsNumber)
> if (JSValue.From(val, new JSContext()).IsNumber)
*** Bug 32982 has been marked as a duplicate of this bug. ***
This is a bug in our code (how we export protocols to ObjC).
Thank you for the replies, Rolf and Brendan, and for the possible workaround. I will try that out.
Rolf does this mean you would like to see my port of this in Swift, or have you already found the cause of the bug?
Brendan, as I mentioned in the original post, I already tried implementing this in Swift, and it works as expected.
Is there any status on how soon this will be fixed?
Again, thank you for your help.
@Christian, I know what the problem is, no need for more information (for now at least).
Also note that another workaround is to use JSContext.CurrentArguments (see the test project in bug #32982 for an example for Xamarin.Mac, it should be trivially portable to Xamarin.iOS).
The current target to fix this is Xamarin.iOS 9.2 (that's several months away; it's not high priority since there's a workaround available).
@Rolf, thank you very much for your quick reply.
Inspired by Brendan's comment, I just stumbled upon JSContext.CurrentArguments myself, so I was just about to post that workaround for anyone else to see. Good to know this is being addressed, and that there's a workaround I can use for now.
Thank you for your help.
Here's a direct link to the code in the test case I provided on the other bug so you don't need to download the whole project zip file:
Essentially just remove the parameters and adjust the export selector on your IJSExport methods, and access the JS invocation arguments via JSContext.CurrentArguments. You can similarly access the current "this" object and callee object, which can be especially useful.
re-numbering (target still C7)
I am successfully able to reproduce this issue with XI 220.127.116.11, on running the attached sample, it gives error "unrecognized selector sent to instance 0x796bbdd0" in application output.
However with C7 XI 18.104.22.1688 this issue is working fine and on running attached sample, it does not give any error in Application output.
So I am closing this issue.
WEB JS: TypeError: customObject.Hello is not a function. (In 'customObject.Hello(10)', 'customObject.Hello' is undefined)
=== Xamarin Studio Business ===
Version 5.10.3 (build 51)
Installation UUID: 96790184-5699-4b29-a047-9f4c96df4250
Mono 4.4.0 (mono-4.4.0-branch/0f5fdf2)
GTK+ 2.24.23 (Raleigh theme)
Package version: 404000168
=== Xamarin.Profiler ===
=== Apple Developer Tools ===
Xcode 7.3.1 (10188.1)
=== Xamarin.Mac ===
Version: 22.214.171.1248 (Xamarin Business)
=== Xamarin.Android ===
=== Xamarin Android Player ===
=== Xamarin.iOS ===
Version: 126.96.36.1998 (Xamarin Business)
Build date: 2016-05-13 17:19:05-0400
=== Build Information ===
Release ID: 510030051
Git revision: f3c0d982165f785772d125f02668370d929014fb
Build date: 2016-03-24 18:51:31-04
Xamarin addins: ee5cfd3ecb6b20de47c1d25efb9a9abc101e8ce7
Build lane: monodevelop-lion-cycle6-c6sr3
=== Operating System ===
Mac OS X 10.11.1
Darwin sodsoftdeiMac-2.local 15.0.0 Darwin Kernel Version 15.0.0
Sat Sep 19 15:53:46 PDT 2015
@liugx: please open a new bug report and attach a project we can use to reproduce any issues you're having.