CC'ing Derek Davies, our lead QA on this project
Eeep! This is certainly worth an edt0.9.4 nomination. Ari, I'm assuming that you follow everything in: http://mozilla.org/projects/plugins/scripting-plugins.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
Argh. Ignore my last comment about scripting out- that should have been for bug 118003. This is indeed the simple XP Connect \ scripting in. Sorry.
Could this be a problem with XPConnect itself? CCing appropriate parties.
Are you *certain* that this is the state of the string when it first arrives in your plugin? There is no code in xpconnect that would copy and truncate a 'string' param. I'd be very surprised to learn that the JS engine was doing this. I have to wonder if perhaps your plugin code might have some parsing that could leave the string altered and that you might be examinimg it after this transformation has already happened. Can you say for sure that this is not so? If you are sure that this mangling is not in the plugin itself, then someone is going to have to try to recreate this in the debugger. Here is a trivial testcase using the xpctest code that copies your string from JS->C++->JS. It works fine for me in the xpcshell. const Echo = Components.Constructor("@mozilla.org/js/xpc/test/Echo;1", "nsIEcho"); var echo = new Echo(); var input = "TriggerAnimation(rotate)"; for(var i = 0; i < 50; i++) print(echo.In2OutOneString(input));
I tried to get the plugin installed but it never seems to recognize it. Anything I should additional to the readme.txt? I'll check my xpcom log to see if it's failing in registration or something.
Created attachment 63544 [details] [diff] [review] testcase hack to plugin\samples\4x-scriptable I still can't reproduce this in any testcase. I'm attacing a quick hack to plugin\samples\4x-scriptable that tries to reproduce the conditions you describe. av: Note that the changes to makefile.win are required AFAICT to make the sample compile with or without my other changes. I think you need to update that makefile. From what you say I still suspect that the plugin code is modifying the *const* buffer that is passed in. The JS engine caches this ASCII version of its internal Unicode string. So, if you did cast away const and modify the buffer contents then on the *subsequent* call you would receive the modified buffer contents. You might not see this every time because the JS engine might recycle its buffer now and then and build a new (clean) copy as needed. I again urge you to examine your code and also look at the buffer contents on the way in *and* just before you return control.
Makes sense. I don't see us doing that, but I will try making a copy of what comes in and using that to make sure that the buffer doesn't get touched.
I'm glad to hear that. Marking INVALID.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.