I'm sorry but i haven't managed to find a simpler (non GTK) test case. Running this little program results in the output:
** (jsarray:893): DEBUG: TypeError: Result of expression 'a.push' [undefined] is not a function.
Note that the eval in the WebView widget does not produce any console messages.
static gchar *
js_string_to_cstring (JSStringRef jsStr)
gsize len = JSStringGetMaximumUTF8CStringSize (jsStr);
gchar *str = g_malloc (len);
JSStringGetUTF8CString (jsStr, str, len);
static gchar *
js_value_to_cstring (JSContextRef jsCtx, JSValueRef jsVal, JSValueRef *jsExn)
JSStringRef jsStr = JSValueToStringCopy (jsCtx, jsVal, jsExn);
if (NULL == jsStr)
str = js_string_to_cstring (jsStr);
main (int argc, char **argv)
JSContextRef jsCtx = JSGlobalContextCreate (NULL);
JSValueRef jsVal, jsExn = NULL;
gtk_init (&argc, &argv);
webview = WEBKIT_WEB_VIEW (webkit_web_view_new ());
webkit_web_view_execute_script (webview, "a = ; a.push(42);");
gtk_widget_destroy (GTK_WIDGET (webview));
jsStr = JSStringCreateWithUTF8CString ("a = ; a.push(42);");
jsVal = JSEvaluateScript (jsCtx, jsStr, NULL, NULL, 0, &jsExn);
if (NULL == jsVal)
jsVal = jsExn;
str = js_value_to_cstring (jsCtx, jsVal, NULL);
g_debug ("%s", str);
compile-command: "gcc -g -ggdb -O0 -W -Wall \
`pkg-config --cflags --libs webkit-1.0` \
jsarray.c -o jsarray"
Alexey, this feels as though it may be related to some of your recent changes.
I do not immediately see how this can result from my changes, although it sounds possible indeed. David, do you know if this is a recent regression?
(In reply to comment #2)
> I do not immediately see how this can result from my changes, although it
> sounds possible indeed. David, do you know if this is a recent regression?
In my little toy browser it is new. But it appeared around same time I added the code that allows me to eval JS code in any webframe. I'm not 100% sure this is correlated but I doubt it (I commented out all the code I think might be relevant). And... I'm sorry, it's only under VC since a few minutes :\
In my browser it's actually the other way round. The context created with the JS core API is doing fine while the context of the web frames is borken (Array.push isn't the only method missing, it spits out a lot of console messages about missing standard methods).
Created attachment 22386 [details]
Mac version of the test (works as expected)
The problem doesn't happen for me with the test changed to use Mac APIs and r35250. I am not aware of any differences between Mac and Gtk ports that could make the behavior different.
At the moment, WebCore uses its own JSGlobalData object (which holds JS heap, identifier tables etc), while all contexts created with JSGlobalContextCreate() share another instance of JSGlobalData. This means that JS objects cannot be used across WebCore and manually created contexts in any way, but this does not happen in the test anyway. This also means that nothing that happens in WebCore should affect contexts created via JSC API, or vice versa.
Soon, I intend to change JSGlobalContextCreate() to use a private instance of JSGlobalData for each context, and to introduce a new API to create contexts share global data.
(In reply to comment #5)
> This means that JS objects cannot be
> used across WebCore and manually created contexts in any way, but this does not
> happen in the test anyway.
Neither in my app, I just pass around strings and JSEvaluateScript() them.
> Soon, I intend to change JSGlobalContextCreate() to use a private instance of
> JSGlobalData for each context, and to introduce a new API to create contexts
> share global data.
Could you elaborate on that? Would this allow me to pass around JSObjects from
the context I created using JSGlobalContextCreate() and the WebCore contexts?
I'd be *very* interested in this kind of feature. In my (far away from usable) browser I use the JS core API to script the GUI. I'm now at a point where I need/want to pass around data. I'm currently thinking about using GObject signals and strings. This just feels so incredible wrong (and is most probably terrible inefficient)...
If this becomes to far OT I'd be glad to get an answer via mail.
Will answer via e-mail - since this bug is still a total mystery, let's keep the discussion focused on it indeed.
Created attachment 22391 [details]
Another test case that produces a failed assertion.
This test case produces a segfault. Of course it depends on the URI. Hurry before yahoo changes the content.
(In reply to comment #8)
> This test case produces a segfault.
Created attachment 22393 [details]
Backtrace of previous test case
(In reply to comment #8)
> Created an attachment (id=22391) 
> Another test case that produces a segfault.
This seems completely unrelated, and probably a gtk port bug - looks like DOMImplementation::isXMLMIMEType() is called with a null argument.
(In reply to comment #11)
> (In reply to comment #8)
> > Created an attachment (id=22391) 
> > Another test case that produces a segfault.
> This seems completely unrelated, and probably a gtk port bug - looks like
> DOMImplementation::isXMLMIMEType() is called with a null argument.
Doubt it. Everything works fine if I don't create / use the `jsCtx' context (in this example the borken context is the WebViews one, the `a.push' fails as well).
(In reply to comment #13)
> Well, as you can see from the backtrace, the assertion failure in
Hmm, sorry, seems you are right. Does the test work on your mac? I'll file a new bug for GTK then.
I haven't tried rewriting this other test for Mac APIs. It still seems slightly weird, as the server does respond with a valid and usual content-type here (text/html; charset=utf-8), but a little bit of tracing in CURL back-end code should make it clear what is going on.
(In reply to comment #4)
> Created an attachment (id=22386) 
> Mac version of the test (works as expected)
> The problem doesn't happen for me with the test changed to use Mac APIs and
> r35250. I am not aware of any differences between Mac and Gtk ports that could
> make the behavior different.
What's the right way to get some attention from the GTK people? Resubmit or change the ``component''? The bug is still present in r35511.
At this point, it may make sense to close this bug and open two new ones, as there are two different issues discussed here, which is quite confusing. Also, some recent changes may have affected the behavior originally described here (Array.push disappears) a lot. The context created with JSGlobalContextCreate no longer shares underlying data structures with the one used by WebView.
OK, I'll file both under `GTK' then. Hmm, `LATER' sounds like an optimist ``resolution''...