[webkit-gtk] JavaScriptCore GObject Bindings - Memory Management

[tev...@gmail.com]

Hi. I started implementing a JavaScriptCore GObject binding in [1]. This
API provides two main objects: JSCContext, representing JSGlobalContextRef,
and JSCValue, representing JSValueRef. It's a first patch and does't do any
memory management, because I wasn't really aware of how JSC handles
JSValueRefs and stuff.

Asking on JSC list they replied that JSValues are garbage collected and
when you need to keep a reference to it in the heap you should protect
them. [2] This is already done by the bindings: JSValueRefs are protected
on contruction of JSCValue and unprotected on destruction, but JSCValues
were implemented as initially owned and noone's keeping their reference to
unref them when needed.

So in the current state, we are leaking JSCValues and, as JSCValues protect
JSValueRefs, memory is never freed.

JavaScriptCore doesn't have any API to directly free JSValueRefs, so
JSCValues needs to be destructed to unprotect JSValueRefs.

My thought is to Adopt JSCValues when they are created using a private API
in the JSCContext (jscContextAdoptJSCValue(JSCValue*) ?). As JSCValues have
a JSCContext reference, we can call jscContextAdoptJSCValue in JSCValue's
constructed callback. With this private API, JSCContext will get a JSCValue
reference and add it to a HashMap that will map the JSValueRef to the
JSCValue. When added to the HashMap, JSCValue will be owned by the context
and will be freed when the context is unrefed.

What do you think about this idea?

[1] *https://bugs.webkit.org/show_bug.cgi?id=164061
*
[2] https://lists.webkit.org/pipermail/jsc-dev/2016-November/84.html
___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] GObject API for JavaScriptCore

[tev...@gmail.com]

Em ter, 18 de out de 2016 às 15:07, Carlos Garcia Campos <cgar...@igalia.com>
escreveu:

El mar, 18-10-2016 a las 13:29 +0000, tev...@gmail.com escribió:
[...]
> > It doesn't need to be just a wrapper, because to wrap the JSC API
> > you
> > can just use the existing API. As I said, this depends on how we
> > design
> > the value object for example, if we use a different subtype for
> > every
> > value type, we definitely want to use GObjects. I really don't
> > think
> > there's that much overhead in using GObject, compared to boxed
> > types.
> > And it also depends on whether we want to use floating references,
> > especially for the JSCValue it could be interesting to make it
> > initially unowned.
> >
>
> Well... I don't really see a point on having subtypes for every kind
> of value... maybe code maintainability, but I don't think this will
> be hurt if we use only one type for values (yet). Feel free to
> convince me though. And it's a good idea to make JSCValues initially
> unowned.

I'm afraid it works the other way around :-) you have to convince us
that using boxed types is better, or prove that the GObject overhead is
so high that it's worth not using them. We could implement the desired
features for a boxed type (ref counting, floating refs, weak refs,
etc.) but we would be reinventing GObject in the end. Note that we can
have a single JSCValue for everything but still make it a GObject
instead of a boxed type.


 Yes. It really wasn't clear... When I wrote that paragraph, I was already
agreeing with JSCValues being GObjects. I was just not finding a good
reason for subtypes :P GObjects are really needed, mainly because of the
possibility of making them initially unowned and also because of memory
management.

> > > >  * Error handling: I'm not sure GError is enough to handle js
> > > > exceptions. They can happen at any time and have additional
> > > > information
> > > > like line number, column, etc. that can't be represented by
> > GError.
> > > > The
> > > > Objc API allows to set a callback per context to handle the
> > > > exceptions.
> > > >
> > >
> > > We can use a boxed type here too (simpler) or subclass GError to
> > add
> > > the details...
> >
> > I wouldn't use GError, but a custom exception object (boxed type or
> > whatever), because it's not that we want extra info, but that maybe
> > we
> > don't really need the error code and quark.
> >
> > > > I would start the API with the wrappers needed to setup a js
> > > > context
> > > > and then the JSValueRef wrapper with methods to set an retrieve
> > > > simple
> > > > values (string, bool, number, array, object/dictionary, date),
> > > > leaving
> > > > the handling of custom objects out for now. We could probably
> > use a
> > > > bug
> > > > report or a dedicated thread in this list to decide about this
> > > > specific
> > > > part of the API (whether we want to expose it as a single Value
> > > > type or
> > > > have a different type per value type, whether to use GObjects
> > or
> > > > boxed
> > > > types, whether to make it initially unowned, etc.)
> > > >
> > >
> > > I'll wait for your comments on the namespace and types to open
> > that
> > > bug report. This way, I can upload the initial patch.
> >
> > Ok, note that it's not just me, for public API in WebKitGTK+ we
> > hace a
> > rule that it needs to be approved by two reviewers, so maybe you
> > want
> > to wait ot hear the opinion of other people. Also, I would at least
> > send a proposal here with the types you are going to add and
> > propotypes
> > of methods before spending too much time with the actual
> > implementation, just in case.
>
> So, considering your previous comments, we can do something like this
> for a start:
>
> Objects:
> o JSCContext
> o JSCValue
> o JSCObject
>   * JSCError (JSCArray, JSCDate and other stuff should come here too)

Why is Object special? So, we use a single JSValue for everything
except Object? I think we should be consistent here. I know that's what
the C API does, but this is what I meant when I said that our API
doesn't necessarily need match the C API 1 to 1.

And then JSCError is also a JSCObject? why is this a different object
too? I think it should be named JSCException, btw.

> Methods:
> JSCContext* jsc_context_new();
> JSCObject* jsc_context_get_global_object(JSCContext*);

If we add convenient methods to JSCContext

Re: [webkit-gtk] GObject API for JavaScriptCore

[tev...@gmail.com]

Em seg, 17 de out de 2016 às 14:24, Carlos Garcia Campos <cgar...@igalia.com>
escreveu:

> El lun, 17-10-2016 a las 12:37 +, tev...@gmail.com escribió:
> >
> >
> > Em seg, 17 de out de 2016 às 04:31, Carlos Garcia Campos <cgarcia@iga
> > lia.com> escreveu:
> > > El lun, 10-10-2016 a las 01:19 +, tev...@gmail.com escribió:
> > > > Hello, everyone.
> > >
> > > Hi,
> > >
> > > > Some background first: my name is Estêvão and every now and the I
> > > try
> > > > to contribute to Gnome Web, AKA Epiphany. First time was back in
> > > > 2010. After the migration of Epiphany to WebKit, it stopped
> > > > identifying feed links on pages. I had to dig into JavaScriptCore
> > > to
> > > > call JavaScript functions to check for feed links on pages. DOM
> > > > bindings were only in TODO by then. Now what I need to do is a
> > > little
> > > > bit different, but also involves JavaScriptCore. We need to
> > > bridge
> > > > between JavaScript and C code so that an about page can be able
> > > to
> > > > list URLs to display. I was chocked that up to now JavaScriptCore
> > > is
> > > > untouched. So I started thinking about how could a GObject
> > > binding to
> > > > JSC be implemented.
> > > >
> > > > The proposal:
> > > >
> > > > I'm thinking about creating GObjects to warap JSC objects. For
> > > > instance: GJSCContext wrapping JSContextRef, GJSCObject wrapping
> > > > JSObjectRef and so on.
> > >
> > > We talked during the web engines hackfest about adding a GLib
> > > wrapper
> > > for JSC, not necessarily a 1 to 1 wrapper from JSC object to GLib
> > > objects, though.
> > >
> > > >  I implemented a POC of the API and a simple client to make my
> > > > intentions clearer. It's available on https://github.com/tevaum/j
> > > sc-
> > > > bindings.
> > >
> > > Thanks for working on this!
> > >
> > > > With that *not-so-gobject* partial API the client is able to
> > > bridge
> > > > javascript functions to native C callbacks and to execute
> > > javascript
> > > > code from C. Also the C function returns an array to the
> > > javascript
> > > > code. An example of error handling is also shown.
> > >
> > > I think error handling is a bit different in this case, we probably
> > > need a special way to handle JS exceptions.
> > >
> > > > I think that we have to start simple and add stuff incrementally,
> > > > based on what's already being used/requested by people. Please
> > > take
> > > > your time to dig into the example code provided, ask questions
> > > and
> > > > poit directions, so that we can buld a better WebKitGTK+.
> > >
> > > I agree with the idea of starting simple and going step by step,
> > > but
> > > before designing a new API there are a set of general things we
> > > should
> > > decide, and the most important thing, we should know what we want
> > > this
> > > new API to be used for. I think the API should allow:
> > >
> > >  * Easily run javascript snippets from C code in a web extension.
> > >  * Interact with javascript contexts, retrieve existing JS values
> > > in
> > > the context to the C code, and add values from C to the javascript
> > > context.
> > >  * Easily expose full objects to javascript
> > >
> > > That would cover the main uses cases, replacing the dom bindings
> > > and
> > > injecting custom code to JavaScript.
> > >
> > > Regarding the general things we should decide:
> > >
> > >  * Naming: we don't need a name for the library because it will be
> > > part
> > > of libjavascriptcoregtk (gtk is for gtk port, not because it uses
> > > gtk
> > > at all), but we need to use apublic header and a common prefix for
> > > methods and types. In your POC you are using javascript.h as the
> > > header
> > > name, jscore prefix for methods and GJSC for types. The API should
> > > be
> > > consistent in this regard.
> > >
> > >
> >
> > Yes, I really messed up the namespaces :P What about using
> > javascriptcoregtk.h for the header, JSCoreStuff for the objects and
> > jscore_stuff for the methods? Or maybe jsc-g

Re: [webkit-gtk] GObject API for JavaScriptCore

[tev...@gmail.com]

Em seg, 17 de out de 2016 às 04:31, Carlos Garcia Campos <cgar...@igalia.com>
escreveu:

> El lun, 10-10-2016 a las 01:19 +, tev...@gmail.com escribió:
> > Hello, everyone.
>
> Hi,
>
> > Some background first: my name is Estêvão and every now and the I try
> > to contribute to Gnome Web, AKA Epiphany. First time was back in
> > 2010. After the migration of Epiphany to WebKit, it stopped
> > identifying feed links on pages. I had to dig into JavaScriptCore to
> > call JavaScript functions to check for feed links on pages. DOM
> > bindings were only in TODO by then. Now what I need to do is a little
> > bit different, but also involves JavaScriptCore. We need to bridge
> > between JavaScript and C code so that an about page can be able to
> > list URLs to display. I was chocked that up to now JavaScriptCore is
> > untouched. So I started thinking about how could a GObject binding to
> > JSC be implemented.
> >
> > The proposal:
> >
> > I'm thinking about creating GObjects to warap JSC objects. For
> > instance: GJSCContext wrapping JSContextRef, GJSCObject wrapping
> > JSObjectRef and so on.
>
> We talked during the web engines hackfest about adding a GLib wrapper
> for JSC, not necessarily a 1 to 1 wrapper from JSC object to GLib
> objects, though.
>
> >  I implemented a POC of the API and a simple client to make my
> > intentions clearer. It's available on https://github.com/tevaum/jsc-
> > bindings.
>
> Thanks for working on this!
>
> > With that *not-so-gobject* partial API the client is able to bridge
> > javascript functions to native C callbacks and to execute javascript
> > code from C. Also the C function returns an array to the javascript
> > code. An example of error handling is also shown.
>
> I think error handling is a bit different in this case, we probably
> need a special way to handle JS exceptions.
>
> > I think that we have to start simple and add stuff incrementally,
> > based on what's already being used/requested by people. Please take
> > your time to dig into the example code provided, ask questions and
> > poit directions, so that we can buld a better WebKitGTK+.
>
> I agree with the idea of starting simple and going step by step, but
> before designing a new API there are a set of general things we should
> decide, and the most important thing, we should know what we want this
> new API to be used for. I think the API should allow:
>
>  * Easily run javascript snippets from C code in a web extension.
>  * Interact with javascript contexts, retrieve existing JS values in
> the context to the C code, and add values from C to the javascript
> context.
>  * Easily expose full objects to javascript
>
> That would cover the main uses cases, replacing the dom bindings and
> injecting custom code to JavaScript.
>
> Regarding the general things we should decide:
>
>  * Naming: we don't need a name for the library because it will be part
> of libjavascriptcoregtk (gtk is for gtk port, not because it uses gtk
> at all), but we need to use apublic header and a common prefix for
> methods and types. In your POC you are using javascript.h as the header
> name, jscore prefix for methods and GJSC for types. The API should be
> consistent in this regard.
>
>
Yes, I really messed up the namespaces :P What about using
javascriptcoregtk.h for the header, JSCoreStuff for the objects and
jscore_stuff for the methods? Or maybe jsc-gtk.h JSCStuff for the objects
and jsc_stuff for the methods?


>  * Memory management: this is very important to decide how to declare
> your objects, they could be GObject, boxed types with ref counting,
> etc. Note that javascript objects are garbage collected, so it's very
> important to have mechanisms, to prevent wrapped object from being
> destroyed by the garbage collector if we still have a wrapper alive.
> So, we will probably have to protect all js object when wrapped, which
> means API use will always have to manually unref every single wrapper.
> We might want to make it easier by making out wrappers initially
> unowned, for example. There might be cases in which we want to wrapper
> to be automatically destroyed when the wrapped object is garbage
> collected too. We need to take into account all these cases when
> designing the API.
>

 I think that boxed types are the best, because we can ref-count them but
don't get the overhead of gobject inheritance, remembering it's just a
wrapper...


>  * Error handling: I'm not sure GError is enough to handle js
> exceptions. They can happen at any time and have additional information
> like line number, column, etc. that can't be represented by GError. The
> Objc API

Re: [webkit-gtk] render issue

[tev...@gmail.com]

Hi, Louis.

What version of webkitgtk are you using? And which browser?

On 16:56, Sat, Oct 15, 2016 Louis Garcia  wrote:

> http://www.bmwusa.com/ does not render correctly with webkitgtk. Firefox
> is fine.
> ___
> webkit-gtk mailing list
> webkit-gtk@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
>
___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] GObject API for JavaScriptCore

[tev...@gmail.com]

Hello, everyone.

Some background first: my name is Estêvão and every now and the I try to
contribute to Gnome Web, AKA Epiphany. First time was back in 2010. After
the migration of Epiphany to WebKit, it stopped identifying feed links on
pages. I had to dig into JavaScriptCore to call JavaScript functions to
check for feed links on pages. DOM bindings were only in TODO by then. Now
what I need to do is a little bit different, but also involves
JavaScriptCore. We need to bridge between JavaScript and C code so that an
about page can be able to list URLs to display. I was chocked that up to
now JavaScriptCore is untouched. So I started thinking about how could a
GObject binding to JSC be implemented.

The proposal:

I'm thinking about creating GObjects to warap JSC objects. For instance:
GJSCContext wrapping JSContextRef, GJSCObject wrapping JSObjectRef and so
on. I implemented a POC of the API and a simple client to make my
intentions clearer. It's available on https://github.com/tevaum/jsc-bindings
.

With that *not-so-gobject* partial API the client is able to bridge
javascript functions to native C callbacks and to execute javascript code
from C. Also the C function returns an array to the javascript code. An
example of error handling is also shown.

I think that we have to start simple and add stuff incrementally, based on
what's already being used/requested by people. Please take your time to dig
into the example code provided, ask questions and poit directions, so that
we can buld a better WebKitGTK+.

Thanks!

Estêvão Samuel Procópio Amaral
___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk