Bug 20107 - Array.push disappeared
Summary: Array.push disappeared
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-19 06:45 PDT by David Hansen
Modified: 2008-08-01 12:27 PDT (History)
1 user (show)

See Also:


Attachments
Mac version of the test (works as expected) (1.23 KB, text/plain)
2008-07-20 03:21 PDT, Alexey Proskuryakov
no flags Details
Another test case that produces a failed assertion. (1.79 KB, text/plain)
2008-07-20 11:01 PDT, David Hansen
no flags Details
Backtrace of previous test case (5.12 KB, text/plain)
2008-07-20 11:06 PDT, David Hansen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Hansen 2008-07-19 06:45:14 PDT
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:
*/
Comment 1 Mark Rowe (bdash) 2008-07-19 21:34:59 PDT
Alexey, this feels as though it may be related to some of your recent changes.
Comment 2 Alexey Proskuryakov 2008-07-20 02:46:40 PDT
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?
Comment 3 David Hansen 2008-07-20 03:18:50 PDT
(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).
Comment 4 Alexey Proskuryakov 2008-07-20 03:21:33 PDT
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.
Comment 5 Alexey Proskuryakov 2008-07-20 03:28:27 PDT
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.
Comment 6 David Hansen 2008-07-20 04:07:54 PDT
(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.
Comment 7 Alexey Proskuryakov 2008-07-20 05:28:18 PDT
Will answer via e-mail - since this bug is still a total mystery, let's keep the discussion focused on it indeed.
Comment 8 David Hansen 2008-07-20 11:01:08 PDT
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.
Comment 9 David Hansen 2008-07-20 11:04:31 PDT
(In reply to comment #8)
> This test case produces a segfault.

s/segfault/failed ASSERT()/
Comment 10 David Hansen 2008-07-20 11:06:14 PDT
Created attachment 22393 [details]
Backtrace of previous test case
Comment 11 Alexey Proskuryakov 2008-07-20 13:45:42 PDT
(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.
Comment 12 David Hansen 2008-07-20 18:02:44 PDT
(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).
Comment 13 Alexey Proskuryakov 2008-07-21 01:24:23 PDT
Well, as you can see from the backtrace, the assertion failure in jsRegExpExecute doesn't really involve any JavaScript code.
Comment 14 David Hansen 2008-07-21 01:39:02 PDT
(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.
Comment 15 Alexey Proskuryakov 2008-07-21 02:53:36 PDT
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.
Comment 16 David Hansen 2008-08-01 11:57:49 PDT
(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.
Comment 17 Alexey Proskuryakov 2008-08-01 12:20:12 PDT
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.
Comment 18 David Hansen 2008-08-01 12:27:00 PDT
OK, I'll file both under `GTK' then.  Hmm, `LATER' sounds like an optimist ``resolution''...