Bug 20107 – Array.push disappeared

• Status: RESOLVED
• Resolution: LATER
• Component: JavaScriptCore

[David Hansen]

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.

#include <gtk/gtk.h>
#include <JavaScriptCore/JavaScript.h>
#include <webkit/webkit.h>

static gchar *
js_string_to_cstring (JSStringRef jsStr)
{
  gsize  len = JSStringGetMaximumUTF8CStringSize (jsStr);
  gchar *str = g_malloc (len);

  JSStringGetUTF8CString (jsStr, str, len);

  return str;
}

static gchar *
js_value_to_cstring (JSContextRef jsCtx, JSValueRef jsVal, JSValueRef *jsExn)
{
  JSStringRef  jsStr = JSValueToStringCopy (jsCtx, jsVal, jsExn);
  gchar       *str;

  if (NULL == jsStr)
    return NULL;

  str = js_string_to_cstring (jsStr);
  JSStringRelease (jsStr);

  return str;
}

int
main (int argc, char **argv)
{
  JSStringRef  jsStr;
  JSContextRef jsCtx        = JSGlobalContextCreate (NULL);
  JSValueRef   jsVal, jsExn = NULL;

  WebKitWebView *webview;

  gchar *str;

  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);

  return 0;
}

/*
  Local Variables:
  compile-command: "gcc -g -ggdb -O0 -W -Wall \
    `pkg-config --cflags --libs webkit-1.0`   \
    jsarray.c -o jsarray"
  End:
*/

[Mark Rowe (bdash)]

Alexey, this feels as though it may be related to some of your recent changes.

[Alexey Proskuryakov]

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?

[David Hansen]

(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).

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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.

[David Hansen]

(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.

[Alexey Proskuryakov]

Will answer via e-mail - since this bug is still a total mystery, let's keep the discussion focused on it indeed.

[David Hansen]

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.

[David Hansen]

(In reply to comment #8)
> This test case produces a segfault.

s/segfault/failed ASSERT()/

[David Hansen]

Created attachment 22393 [details]
Backtrace of previous test case

[Alexey Proskuryakov]

(In reply to comment #8)
> Created an attachment (id=22391) [edit]
> 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.

[David Hansen]

(In reply to comment #11)
> (In reply to comment #8)
> > Created an attachment (id=22391) [edit]
> > 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[42]' fails as well).

[Alexey Proskuryakov]

Well, as you can see from the backtrace, the assertion failure in jsRegExpExecute doesn't really involve any JavaScript code.

[David Hansen]

(In reply to comment #13)
> Well, as you can see from the backtrace, the assertion failure in
> jsRegExpExecute doesn't really involve any JavaScript code.
> 

Hmm, sorry, seems you are right.  Does the test work on your mac?  I'll file a new bug for GTK then.

[Alexey Proskuryakov]

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.

[David Hansen]

(In reply to comment #4)
> Created an attachment (id=22386) [edit]
> 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.

[Alexey Proskuryakov]

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.

[David Hansen]

OK, I'll file both under `GTK' then.  Hmm, `LATER' sounds like an optimist ``resolution''...