Re: [Edbrowse-dev] many topics

[Adam Thompson <arthompson1990@gmail.com>]

On Mon, Feb 03, 2014 at 08:54:07AM -0500, Karl Dahlke wrote:
> 1. My latest push fixes the form reset bug, which I wrote about last time.
> 

Good to hear.

> 2. JSAutoCompartment, I almost understand what it does,
> but still don't know why it is needed.
> Look at the function JS_DefineProperty in the api, for example.
> It's first argument is the context.
> And all the functions seem to be like that.
> They were before anywaays.
> Every time you tap into the javascript machinery
> you are telling it explicitly the context to use.
> It is the first argument to everything.
> Why then would it have to be set,
> or assigned a compartment, or any such thing?
> If a context were assigned in some global fashion,
> then we wouldn't have to pass it as an argument to every js function
> now would we?
> There's something inconsistent about this design.

As far as I understand it the SpiderMonkey universe works something like this:
First of all the engine is initialised
Then a runtime is created which holds everything else
A runtime can contain multiple contexts, which contain the environments inwhich scripts execute
Each context contains multiple compartments;
objects within one compartment can access objects within another compartment
but by default objects etc exist within the current compartment

In addition, add to this model the concept of a global object.

In edbrowse each window has its own js context.
Each page within that window has its own global object.
This means that each page also has its own compartment,
otherwise it'd get incredibly messy with cross-page global variables etc.
What this means when switching pages is that the context needs to be switched
into the compartment of that page's global object.
This all used to be handled when creating the global object for the page and I
assume some sort of magic happened to make this work when switching back a page.
However the auto-creation of a compartment per global has been removed as has
the magic which made switching the global jwin object switch the current
compartment (or perhaps the compartment model's just become stricter in mozjs 24).
Anyway, in order to avoid keeping an additional list of old compartments
somewhere (compartments have to be switched in and out of in lifo order),
I decided it made more sense (and removed much book keeping)
to just switch to the compartment of the current global (cw->jss->jwin)
object as and when we needed to, thus the ac objects.
Personally I'm not hugely fond of how Mozilla have done this,
but it's their library and seems to primarily be developed to suit however the
latest version of Firefox wants to use js.

> 
> 3. I think things are somewhat stable, and would like to reindent using
> the kernel formatting.
> That is a global change.
> Are you working on something at present, or is the code quiescent?
> Adam I know you said you wanted to make some changes to url.c
> for compiler warnings.
> Is this in process or on hold,
> whence I could make a global change?

It's currently on hold due to university assignments,
so go ahead and make the indentation change.

> 
> 4. I think I know how to restructure the file map,
> so I don't have marching index numbers that eventually run out,
> unless I write another gc module, which I don't want to do.
> There will probably still be a limit on files you can edit,
> but larger, and perhaps architecture dependent, 4 byte pointers and indexes etc,
> and in any case better than where we're at today.
> So I may do that after the re-indent.

Sounds good.
> 
> 5. After all these changes have been made,
> maybe we all play with it for a month or so to look for more bugs,
> then cut a new version.

Yeah, I think once we're happy with the functionality,
I'll do my warning squashing (I think the newer gcc versions are more pedantic
thus the extra warnings).

After that I say we go ahead with the new version as long as everyone's happy
with the state of the code at that point.

Cheers,
Adam.