Re: [Edbrowse-dev] compartments

[Adam Thompson <arthompson1990@gmail.com>]

On Wed, Feb 05, 2014 at 08:55:47AM -0500, Karl Dahlke wrote:
> There are two paths to javascript,
> creating the global object in the first place,
> and then activating js later, which always calls jSyncup
> to get things ready.
> But aha, raii won't work here.
> jSyncup calls and sets everything up and returns.
> Then all the other js functions are called.
> Set the compartment via raii in jSyncup, and when it returns
> your compartment is lost.
This is unfortunate as it'd be a nice simplification.

> We can only simplify things if there is a straight,
> old fashioned "set this compartment" call,
> that does not involve scope or distructors etc.
> I don't know if such a function exists.
> If yes then we can clean things up a lot.
> If no then we can't.

There is but it's being phased out (i.e.
may disappear whenever the mozilla developers get round to deleting it,
with the possibility of such a removal not being documented).
In addition it doesn't check if you've already switched into this compartment
so you could quickly find yourself building up a stack of equal compartment (pointers?
not sure) which just eat memory and can't be freed as they're protected properties
of the js context (I think).
At least I'm assuming that's how things work since you have to leave
compartments in the reverse order to that inwhich you entered them.

I tried to work around the RAII compartment logic,
but the thing exploded when I went back a page for some reason (NULL
compartment property in the context or a different compartment to that of the
global object or something). Anyway the only way to get things working without
a larger rewrite was to just use the recommended (if not particularly nice in
my opinion) RAII way of doing things.

To be honest I'm all for cleaning up these calls,
but I'd rather get all the good things we're doing at the moment stable and
ready for release then work out what kind of rewrite is required to tidy up the
Mozilla update.
Particularly as I think there've been many major bug fixes recently which really should be released relatively soon.
To do this properly we need to have some time when the code is stable
and we can just test for any other major bugs rather than making huge rewrites.
I also need to work out why the debian mozjs24d package causes edbrowse to just
segfault on startup whereas a manually compiled one doesn't (still haven't
heard about the compilation flags).

That being said, my first version of this message caused Edbrowse to segfault
(typing in too longer line I think),
so maybe we need to look into that one as well.

Cheers,
Adam.