[Edbrowse-dev] mouse.com

[Edbrowse-dev] mouse.com

[Karl Dahlke]

I stumbled upon mouse.com, which redirects to
http://ww1.mouse.com
This is js that I can read, it hasn't been crapped on,
so I'm trying to figure out what I am doing wrong.
Look at lines 47 and 48.
It creates a new script object through document.createElement(), and I do that,
I think edbrowse is ok so far, but, when I create that object
I also link it into the scripts array automatically,
but maybe I'm not suppose to do that because the next line, line 48,
looks like it might be trying to link it into the array of scripts.
Maybe I should remove that action from startwindow.js.
Then it uses things like parentNode and insertBefore, that I don't have implemented yet.
So this may be a good test case.
If I can figure out what it is trying to do,
and how it is suppose to work, then I can move edbrowse in that direction.
At this point you might be saying,
"You can't do that incrementally, you have to start over and
design the DOM correctly from scratch."
Well that may be true, but that's going to be a while,
and I just wonder if there's something I can do here and now to get this to
behave as it should.
Adam I may need your help here on how it is suppose to work,
what I might be able to do as an increment,
and what will have to wait for a larger redesign.
I did, by the way, implement some parentNodes,
but only in the html,
it is not clear what parentNode should point to when the object is created by
createElement().

Karl Dahlke

Re: [Edbrowse-dev] mouse.com

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]

On Mon, Jan 12, 2015 at 09:48:09AM -0500, Karl Dahlke wrote:
> I stumbled upon mouse.com, which redirects to
> http://ww1.mouse.com
> This is js that I can read, it hasn't been crapped on,
> so I'm trying to figure out what I am doing wrong.
> Look at lines 47 and 48.
> It creates a new script object through document.createElement(), and I do that,
> I think edbrowse is ok so far, but, when I create that object
> I also link it into the scripts array automatically,
> but maybe I'm not suppose to do that because the next line, line 48,
> looks like it might be trying to link it into the array of scripts.
> Maybe I should remove that action from startwindow.js.

I think you're correct that, in the case of createElement we shouldn't link
anything automatically. In fact, I think this isn't linking it into the scripts array,
but rather into the DOM before any other scripts
on the same level as the first existing script.
> Then it uses things like parentNode and insertBefore, that I don't have implemented yet.
> So this may be a good test case.
> If I can figure out what it is trying to do,
> and how it is suppose to work, then I can move edbrowse in that direction.

Yeah, I'm also seeing some json (further on)
and something which looks like google analytics (and thus some form of ajax)
around that area.
I'll need to have a closer look to really work out what it's supposed to be
doing with the json stuff though.

> At this point you might be saying,
> "You can't do that incrementally, you have to start over and
> design the DOM correctly from scratch."
> Well that may be true, but that's going to be a while,
> and I just wonder if there's something I can do here and now to get this to
> behave as it should.
> Adam I may need your help here on how it is suppose to work,
> what I might be able to do as an increment,
> and what will have to wait for a larger redesign.
> I did, by the way, implement some parentNodes,
> but only in the html,
> it is not clear what parentNode should point to when the object is created by
> createElement().

It should point to nothing automatically;
at this point it's the job of js to insert the created element where it's
supposed to go in the tree. So we need to have support for inserting and then
acting upon the element as if it were part of the original html,
including putting it into the appropriate array (scripts in this case)
at the correct position (the first element in this case).
I think we're almost there with most of this.
To be more specific, in this case, I think we should be creating the script
object, inserting it into the DOM before any other scripts (see note above
about where) then adding it to the scripts array in that position (so first in this case).
How we do that currently I'm not sure,
as the only way I can think to do it is to recreate the arrays whenever the DOM
is altered, since it's not unreasonable to expect that some scripts may rely on
their DOM alteration being imediately present.
It depends on how we've implemented the "arrays"
internally (I've not looked at this).
If they're actual dynamic arrays then we'll need to realloc and move things
around, but if they're linked lists then we should be able to find the
appropriate position in the list and insert the new element,
which'd be better for performance.
to make things a bit more generic than this case,
we then need to support re-rendering of the altered DOM once we've finished
with js (which I think we partially do now,
though we may need to increase this support).
Out of interest, how closely coupled is the parsing and rendering code at the
minute, since that'll really effect how large the increments need to be.
I've had a look through html.c, but I've not had time to really dig into it too much.

That being said, all of the above I think can probably be done incrementally.
What will require more work is the async attribute (I assume that means to "run
this script asynchronously"), and whatever ajax and network stuff is going on
behind the scenes (there's some google analytics code in there).

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]