[Edbrowse-dev] startwindow.js changes

[Edbrowse-dev] startwindow.js changes

[Adam Thompson]

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

Hi all,

Building on the good work that's been happening over the last couple of days,
I've been going through startwindow.js and have made a few changes to hopefully
bring what we do in line with the DOM standard a bit more.
I've pushed what I've done and really hope I've not broken anything (it seems
to work in my testing, but there's all sorts of odd js out there).

Basically I've removed the autolinking of elements from document.createElement,
made it return an Element rather than Object in the default case,
and enabled support for storing any tag under the document.tag$$map container
(though I'm not sure how to expose the arrays to js properly other than by
document.getElementsByTagName). There're a few more changes,
see the commit for details.

Cheers,
Adam.

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

[Edbrowse-dev] startwindow.js changes

[Karl Dahlke]

Well it did break something in jsrt, though small.

You removed the lines that link the new elements into the arrays
of said elements, and honestly I don't know what the correct behavior is here.
When I create a script, should it be in the list of scripts?
I don't know.
The last function document.script$$pending() assumes that a script created
will be in this list, and then looks through this list for scripts pending,
for a script to run that hasn't been run.
If a created script should not be put on the list document.scripts,
then we have to put this one somewhere, in some kind of queue,
so it can be run.

jsrt exercised this feature by creating one final script which, when run,
put one line at the end of jsrt.browse.
The line use to say {Last Link}.
That line is not there any more, because the last script never runs,
because it is not placed in document.scripts.
We may need to do a little research to see how it *should* behave.
Either these elements get put in their corresponding lists automatically,
or if not then we need to implement a run queue for created scripts.

Karl Dahlke

Re: [Edbrowse-dev] startwindow.js changes

[Adam Thompson]

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

On Tue, Jan 13, 2015 at 04:10:52PM -0500, Karl Dahlke wrote:
> Well it did break something in jsrt, though small.
> 
> You removed the lines that link the new elements into the arrays
> of said elements, and honestly I don't know what the correct behavior is here.
> When I create a script, should it be in the list of scripts?
> I don't know.
> The last function document.script$$pending() assumes that a script created
> will be in this list, and then looks through this list for scripts pending,
> for a script to run that hasn't been run.
> If a created script should not be put on the list document.scripts,
> then we have to put this one somewhere, in some kind of queue,
> so it can be run.
> 
> jsrt exercised this feature by creating one final script which, when run,
> put one line at the end of jsrt.browse.
> The line use to say {Last Link}.
> That line is not there any more, because the last script never runs,
> because it is not placed in document.scripts.
> We may need to do a little research to see how it *should* behave.
> Either these elements get put in their corresponding lists automatically,
> or if not then we need to implement a run queue for created scripts.

Sorry, I did wonder if I'd break something by doing this.
I'm fairly confident in saying that elements *shouldn't* be put in these lists
automatically since the function returns the created element to javascript
which then inserts it into the DOM in the correct position, i.e.
in the case of mouse.com, the created script should really appear before any
other scripts in the document and thus at the start of the scripts array.
As for what we do about running these scripts,
the logic seems to involve reparsing the DOM once the current script has
finished execution (I presume) and running the new script elements at that stage.
Since we don't do this at the moment, a separate run queue is probably needed,
along with some form of functionality in our DOM insertion functions
(appendChild, insertBefore etc) to put elements in the correct place in these arrays.
Tbh, I suspect we can probably put together the relevant functionality in
startwindow.js to reparse the DOM and generate the arrays from the js side,
though this obviously doesn't help the rendering at all.

Also, as per comments in startwindow.js,
apparently we're supposed to return something called a node list object rather
than an array from getElement* functions.
No idea what one of these is yet, more future research I think.

Cheers,
Adam.

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

Re: [Edbrowse-dev] startwindow.js changes

[Adam Thompson]

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

On Tue, Jan 13, 2015 at 11:21:18PM +0000, Adam Thompson wrote:
> On Tue, Jan 13, 2015 at 04:10:52PM -0500, Karl Dahlke wrote:
> > Well it did break something in jsrt, though small.
> > 
> > You removed the lines that link the new elements into the arrays
> > of said elements, and honestly I don't know what the correct behavior is here.
> > When I create a script, should it be in the list of scripts?
> > I don't know.
> > The last function document.script$$pending() assumes that a script created
> > will be in this list, and then looks through this list for scripts pending,
> > for a script to run that hasn't been run.
> > If a created script should not be put on the list document.scripts,
> > then we have to put this one somewhere, in some kind of queue,
> > so it can be run.
> > 
> > jsrt exercised this feature by creating one final script which, when run,
> > put one line at the end of jsrt.browse.
> > The line use to say {Last Link}.
> > That line is not there any more, because the last script never runs,
> > because it is not placed in document.scripts.
> > We may need to do a little research to see how it *should* behave.
> > Either these elements get put in their corresponding lists automatically,
> > or if not then we need to implement a run queue for created scripts.

Ok, as a temporary fix, I've implemented document.script$$queue,
where scripts are pushed (like they used to be with document.scripts) upon creation.
This fixes the jsrt test at least.
Though, looking at how you're supposed to create elements with js,
this test looks broken in that it assumes a script is going to be ran which is
never explicitly inserted into the DOM (createElement does just that,
creates a DOM object).

Cheers,
Adam.

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

[Edbrowse-dev] startwindow.js changes

[Karl Dahlke]

> the function returns the created element to javascript
> which then inserts it into the DOM in the correct position,

Yes, but that's just part of it.
Each tag/element is  put in the tree in its correct position,
and also put in the list.
It is linked in two places.
That's how it works when produced by html.
<form> creates a form object, which is somewhere in the dom tree,
and *also* in the list of forms.
I guessed, not much more than a guess, that that is how it works
for elements created dynamically.
An element e is placed somewhere in dom, as directed by javascrtip,
and also put on the list of said elements,
that part perhaps happening automatically.
So I made the second part happen automatically, again being just a guess.
Maybe the only way to know if my guess is right is to write some javascrtip,
createElement,
and alert document.list.length, and run it in a commercial browser
and see what it says.
We may be doing more and more of this;
it's just hard to find descriptions of how this stuff really works
on the internet.

Karl Dahlke

Re: [Edbrowse-dev] startwindow.js changes

[Adam Thompson]

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

On Tue, Jan 13, 2015 at 06:42:29PM -0500, Karl Dahlke wrote:
> > the function returns the created element to javascript
> > which then inserts it into the DOM in the correct position,
> 
> Yes, but that's just part of it.
> Each tag/element is  put in the tree in its correct position,
> and also put in the list.
> It is linked in two places.
> That's how it works when produced by html.
> <form> creates a form object, which is somewhere in the dom tree,
> and *also* in the list of forms.
> I guessed, not much more than a guess, that that is how it works
> for elements created dynamically.
> An element e is placed somewhere in dom, as directed by javascrtip,
> and also put on the list of said elements,
> that part perhaps happening automatically.
> So I made the second part happen automatically, again being just a guess.
> Maybe the only way to know if my guess is right is to write some javascrtip,
> createElement,
> and alert document.list.length, and run it in a commercial browser

No, the w3c has a very complete DOM spec,
and if you look on w3schools.com you'll find not just a complete DOM reference
but also javascript examples, including non-standard extensions and some notes
on different browsers.
There's actually a *lot* of information on how this stuff *should* work and how
different browsers do things, no need for massive amounts of guess work if we
pick our resources correctly. Of course there'll be the odd browser-specific
thing we may think about incorperating,
but for the core DOM stuff and most of the stuff things like jquery expect,
there're standards and code examples.
I've even seen implementation notes and things about the guts of DOM.

As for inserting elements into lists,
when parsing html appending elements to the appropriate lists works because the
element's place in the DOM is dictated by the document.
However, in javascript, all document.createElement does is give you the correct
object, it doesn't link the element into the document in any way.
That's the job of the script creating the element.
For example if I have the following html:
<html>
<body>
<div>
first div
</div>
<div>
second div
</div>
<div>
third div
</div>
</body>
</html>

And use javascript to add a div saying "test div" between the 2nd and 3rd divs, then I'd expect it to appear at index 2 in document.divs as if it was created by html.
However, in our implementation it'd actually appear at index 3 in document.divs, but be at index 2 in the $kids$ array of the body node.
Also, from reading the w3schools DOM reference,
it appears that all DOM element nodes (i.e.
html, head, body, div etc) should inherit from Element,
and that we should have text nodes for text,
attribute nodes for tag attributes and even comment nodes for comments.

Cheers,
Adam.

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