[Edbrowse-dev] Error Object

[Edbrowse-dev] Error Object

[Karl Dahlke]

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

My note to Sami, and his reply.

==================================================

We find that debugging our browser is notoriously difficult, partly because it's hard to get our hands on real information.
When an error occurs in javascript, it probably shouldn't, it probably happened because our DOM is incomplete, so we need to track it down.

1. error has file and line number, but js in the wild is often minimized, all contained on one line, perhaps 100K long.
Is it possible to include column number in the error object? Even approximate column number? Like compilers do.

2. Errors are usually x.foobar is undefined. We would like to get our hands on x.
Is there any way, through the error object, or even a Duktape.errCreate function, to get a hold of the parent object wherein the property is not defined?
I would at minimum print its nodeName, and perhaps its location within the document tree.
The source is rarely helpful here; it typically says x.foobar, x a parameter to a function, which was another parameter to a function, which was ... on and on.

==================================================

Right now the lexer doesn't track column number information. That's
been requested a few times, so it's quite likely I'll add that support
to the tokenizer and bytecode emitter so that it can be included in
errors. There's nothing technically difficult about it as such, but
for low memory targets it's important to bit pack the column number
information which needs some work.

Re: x.foobar, the base value is unfortunately not available after
error creation. Both expressions like 'v = x.foobar' and 'v =
x.foobar()' do have access to 'x' when the internal call site creates
and throws the error. So it would be technically possible to include
the base value as a property of the error object before it gets
thrown. That would be an entirely custom feature though, and would
capture the base value (maybe keeping it live for longer than
expected). One option would be to pass in the base value into
Duktape.errCreate using some form of "additional parameters" object,
e.g. equivalent of:

augmented = Duktape.errCreate(err, { baseValue: x });

When using the debugger, it's possible to pause on uncaught error
(DUK_USE_DEBUGGER_PAUSE_UNCAUGHT), at which point you can inspect 'x'
as a local variable. The internal implementation is capable of pausing
also on caught errors, but the debugger protocol doesn't expose this yet.


Karl Dahlke

Re: [Edbrowse-dev] Error Object

[Dominique Martinet]

Hi Karl, thanks for this mail,

Karl Dahlke wrote on Fri, Jan 19, 2018:
> Re: x.foobar, the base value is unfortunately not available after
> error creation. Both expressions like 'v = x.foobar' and 'v =
> x.foobar()' do have access to 'x' when the internal call site creates
> and throws the error. So it would be technically possible to include
> the base value as a property of the error object before it gets
> thrown. That would be an entirely custom feature though, and would
> capture the base value (maybe keeping it live for longer than
> expected). One option would be to pass in the base value into
> Duktape.errCreate using some form of "additional parameters" object,
> e.g. equivalent of:

The problem I have isn't that 'x.foobar is undefined' but the error is
often:
TypeError: undefined not callable (property 'something' of [object Object]) 

That does not tell you the name of the variable to inspect, so you have
to go back to code.


> When using the debugger, it's possible to pause on uncaught error
> (DUK_USE_DEBUGGER_PAUSE_UNCAUGHT), at which point you can inspect 'x'
> as a local variable. The internal implementation is capable of pausing
> also on caught errors, but the debugger protocol doesn't expose this yet.

I have that in my branch, but do not offer the ability to do much from
the pause at this point -- this shouldn't be too hard to extend though
if we can catch what 'x' is.

What I'd like to make work is:
 - plug debugger
 - run with demin
 - on error give a prompt
 - from prompt give possibility to 'list' lines from the script around
current line (kind of like gdb), to eval variables like jdb but through
the debugger eval command

Just that should help greatly; I'm still missing the last part but
shouldn't be too difficult at this point...

-- 
Dominique

[Edbrowse-dev] defaultView / cloning onevent$$array

[Kevin Carhart]

The recent work on debugging and better diagnostics is great - very 
exciting.

I have a startwindow with two suggested changes.

Please download it from

http://carhart.net/~kevin/startwindow_20170124.zip


(1) defaultView gets referenced as a property, rather than being called. 
I goofed in making it a function.  So I converted it into a property with 
its code as a getter.

(2) While we modified cloneNode to bring over functions, it wasn't 
bringing over the onevent$$array arrays, if these are among the child 
items of the node being cloned deeply.  I took KD's code for instanceof 
Array, used when the node to copy, itself, is instanceof Array, and used 
this as a model to do the same thing so that an instanceof Array among the 
child items will be handled also.

This change to cloneNode brings nasa.gov back from returning 1 character 
to returning some content.  A series of impressive console errors ensues.

I also have a suggestion (3) which I didn't do yet.  I was reading that 
the == equality test operator does "some funky conversions" , typecasting 
before comparison, and the triple === is the "strict equality" 
operator, with no drawbacks in the materials I found.  I was looking up 
the proper way to do a typeof test and found a reference that said you 
should say (typeof blah==='object').  So for consistency, any objections 
to converting all the == in startwindow.js into ===?

thanks
Kevin

[Edbrowse-dev] defaultView / cloning onevent$$array

[Karl Dahlke]

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

Wow! The cloneNode function, my version and your version, is really screwed up!
I couldn't see it until I turned the light on.
I added a cloneDebug variable, which if true, prints the cloning process as it happens.
Braces are used to indicate the level (depth) of cloning.
Set it true and try it on jsrt, which does a few simple clones, and you'll see what I mean.

We were cloning all the propertties in an object, including those inherited from prototype.
So we would copy over getElementsByTagName and other stock functions,
and maybe that won't break anything, but it sure is a waste.
I added hasOwnProperty to make sure we're cloning true members.

When copying arrays, we copied childNodes, and the things under childNodes,
but this was already handled as the children of the node, so we were copying it twice.
Don't know if that was a waste, or if it really broke things.

Your fixes brought nasa.gov back from one empty line to 23 lines, adding in my fixes brings it up to 53 lines.
But I'm still not warm and fuzzy.
We need to set cloneDebug and step through all the nodes that nasa is cloning and make sure we're really doing the right thing.
Form.elements for instance, that's a specific array with specific DOM meaning, those children that are input elements,
is that being cloned correctly?
I think so but not sure.

The nasa page has bullet items at the bottom, like Contact NASA, that are just text but are probably suppose to be links,
so not sure what is wrong there.

I changed == to === whenever typeof is involved,
but not sure we should do it globally, I'd have to check each one and see if we do or do not want type conversion.

Karl Dahlke

Re: [Edbrowse-dev] defaultView / cloning onevent$$array

[Kevin Carhart]

Thanks for catching more cloneNode problems.

defaultView - yes

=== - thank you

> The nasa page has bullet items at the bottom, like Contact NASA, that are just text but are probably suppose to be links,
> so not sure what is wrong there.

There are definitely some more problems - nasa still gives a couple of 
runtimes.

[Edbrowse-dev] defaultView / cloning onevent$$array

[Karl Dahlke]

I knew cloneNode form.elements wasn't right.
And a few more problems too, now fixed.
Nasa still comes up 58 lines, but not a single link.
Nobody writes a home page with no links, so there is a systemic problem with the way we're rendering nasa's links.
Maybe they're dynamically created or some such and I'm not recognizing it.

Karl Dahlke

[Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart]

Semi related -- I don't know that this harms nasa rendering, but I suspect 
it is widespread enough that it would:

I think there is something wrong with the event listener with prepending 
"on" or not prepending "on".

Here is what I am observing.  With the current startwindow, if you call 
addEventListener("click"...), you cannot then trigger the code 
with .click().  Note that a1.click() below does nothing.  Both cases for 
attachEvent work.

a1 = document.createElement("div")
[object Object]
a2 = document.createElement("div")
[object Object]
a3 = document.createElement("div")
[object Object]
a1.addEventListener("click",function(){ alert('ael - pass in click - 
listen for click') },false)
undefined
a2.attachEvent("click",function(){ alert('ae - pass in click - listen for 
click') },false)
undefined
a3.attachEvent("onclick",function(){ alert('ae - pass in onclick - listen 
for click') },false)
undefined
a1.click()
a2.click()
ae - pass in click - listen for click
undefined
a3.click()
ae - pass in onclick - listen for click
undefined

-----------------------------------

If I comment out the line that prepends "on" , line 1386, now all three 
phrasings run their handler.


a1 = document.createElement("div")
[object Object]
a2 = document.createElement("div")
[object Object]
a3 = document.createElement("div")
[object Object]
a1.addEventListener("click",function(){ alert('ael - pass in click - 
listen for click') },false)
undefined
a2.attachEvent("click",function(){ alert('ae - pass in click - listen for 
click') },false)
undefined
a3.attachEvent("onclick",function(){ alert('ae - pass in onclick - listen 
for click') },false)
undefined

a1.click()
ael - pass in click - listen for click
undefined
a2.click()
ae - pass in click - listen for click
undefined
a3.click()
ae - pass in onclick - listen for click
undefined

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

The real question is, what is addEventListener "suppose" to do, either in the wild, or by its documentation.
I'm sure I prepend "on" because somebody somewhere told me to, I wouldn't have made that up out of thin air.
Course that somebody could have been wrong.
If we decide not to prepend "on" in that function, then we must also undo it in removeEventListener.

Karl Dahlke

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart]

You didn't make it up, I think it originated with me and I was wrong.  I 
apologize for getting it wrong.  It may have had to do with the fact that 
we didn't have things like showscripts, the ^> export, and demin yet.  It 
has gotten a lot easier to isolate a situation in order to gather better 
evidence and do mini-experiments where you vary only one thing in order to 
nail down a cause.

>From MDN and other sources, I think the only two situations where "on" is 
present should be:
- on inline handlers in html (not what we're dealing with in startwindow)
- and in attachEvent, where the correct syntax is to pass in "onblah"

I don't think we ever have to convert "blah" to "onblah".
If "onblah" is passed in, the event to respond to is going to be "blah"
If "blah" is passed in, the event to respond to is going to be "blah"

One usage example is in the script vendor.js from nasa.gov, at 4883-4885 
if you run demin:

             return n !== L && 9 === n.nodeType && n.documentElement ? (L = 
n, S = n.documentElement, r = n.defaultView, r && r !== r.top && 
(r.addEventListener ? r.addEventListener('unload', Ae, !1) : r.attachEvent 
&& r.attachEvent('onunload', Ae)), x = !_(n), y.attributes = i(function 
(e) {

attachEvent is being called with 'onunload' but I think the intention is 
that the future event to listen for to would be 'unload'

addEventListener is being called with 'unload' and the event to listen for 
will be 'unload'

I also have a few illustrative lines that are how I got on cloneNode and 
events in the first place over the past few days and also in December. 
It's 5739, 5740 and 5741 if you demin vendor.js.  However, 5739 is still 
a chunk even after demin, because there is a long line with 
comma-separated items.  But here is the relevant portion:

t.attachEvent && (t.attachEvent('onclick', function () {
                 re.noCloneEvent = !1;
             }), t.cloneNode(!0).click()), null == re.deleteExpando) {

attachEvent is being called with 'onclick' to add a handler to t.
And then immediately after this, it runs a line with multiple things 
daisy-chained:

t.cloneNode(!0).click()

So cloneNode runs and the result from this is an element, call it tcn. 
It lives in memory and hasn't been assigned.
Then it runs [that result element].click()

So assuming that this sample extrapolates to something more general, is 
this useful as a way of knowing the kind of phrasing we're supposed to be 
covering?

My assumption is that if t.addEventHandler had been used instead of 
t.attachEvent, it would have said

t.addEventHandler('click' ......

And the second line would have been the same,

t.cloneNode(!0).click()

Thank you Karl.  The way to put a positive spin on this is that the new 
diagnostics makes it possible to write this email and be more specific.

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

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

Ok, I made this change, but it raises yet more questions.
An onclick tag in html creates a function called onclick(), executable via foo.onclick().
It does not get stripped to click().
And when we click on that button, we are running onclick(), not click().
I'm pretty sure that's right.
So how does that mesh with click()?
When you click on a button or link, are we suppose to try to run both click() and onclick()?
If not, then when on earth do the click() handlers run?

Same question for unload().
I run onunload() when a page is finished, should I also be running unload()?
I'm confused.

Another interesting snippet from your code is

r !== r.top

That is a test to see if we're a frame inside the window, not the top window.
It means the stuff after is only suppose to happen in frames.
You can see top being set in http.c line 2643.
I mention this because it first looks mysterious, but I'm pretty sure that's what it's doing, and I'm pretty sure edbrowse does it right.

A time (to illustrate) when we want == and not === is startwindow.js line 1156.

Karl Dahlke

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart]

I am not positive, but I think we're doing both systems right, and the two 
systems coexist.
An element could have onclick and click$$array.  It could respond to 
onclick() and click(), and they could both be sitting there. I think the 
former is called in a more narrow case, if it exists on that element, and 
also I believe that there is only one at a time, and if you set a new one, 
it clobbers the old.  Since the latter is an array, there could be any 
number.

> When you click on a button or link, are we suppose to try to run both click() and onclick()?
> If not, then when on earth do the click() handlers run?

I think that the click() handlers would run based on the element's 
presence or absence from a set which had had a handler applied, while onclick is a 
single function and would run if it had been established either in HTML or 
by defining the function on that thing.

I think the handlers are less individual.  If it's a div, and there was 
code that said getElementsByTagName("div").addEventListener("click",code), 
then the ultimate effect is that the element in question has had that 
handler doled out to it as part of a set of 30 or some total.  So it's 
the efficiency of not having to think about that work as much, the way 
you don't have to think about every intersecting position in two nested loops.

I think isn't it also true that all of the attributes beginning with "on" 
are one-of-a-kind entities?  For instance, in decorate.c, lists 
of handlers like "onclick", "onchange", "onsubmit" are called out for 
potentially unique code for each one.  So I think the addEventHandler 
system is geared for intra-javascript, where the event names themselves might be "x1", 
"x2" and "x3" and the naming could itself be based on control structures 
or any type of logic.  It could be as ephemeral as any variable.  So every 
possible event name does not have hardcoded presence.  It's a 
genericization.

Ah, so I thought of a reason why these two things both exist.  It makes 
sense to hardcode onload, because there is only one, and you would not get any 
performance or workload benefit out of being able to parameterize it. 
It's correct to say onload.  I think it's historical - those 30 things 
have specific definition in HTML, while the listener system opens it up so 
that events can be called anything.

Here's one more short reference which I thought was pretty good.  It's 
part of a stackoverflow page, by Michal Perlakowski, early 2016.  The original is 
https://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick

---

In this answer I will describe the three methods of defining DOM event 
handlers.

1. element.addEventListener()

element.addEventListener() has multiple advantages:

o Allows you to register unlimited events handlers and remove them with 
element.removeEventListener().

o Has useCapture parameter, which indicates whether you'd like to handle 
an event in its capturing or bubbling phase.

o Cares about semantics. Basically, it makes registering event handlers 
more explicit. For a beginner, a function call makes it obvious that 
something happens, whereas assigning event to some property of DOM element 
is at least not intuitive.

o Allows you to separate document structure (HTML) and logic (JavaScript). 
In tiny web applications it may not seem to matter, but it does matter 
with any bigger project. It's way much easier to maintain a project which 
separates structure and logic than a project which doesn't.

o Eliminates confusion with correct event names. Due to using inline event 
listeners or assigning event listeners to .onevent properties of DOM 
elements, lots of inexperienced JavaScript programmers thinks that the 
event name is for example onclick or onload. on is not a part of event 
name. Correct event names are click and load, and that's how event names 
are passed to .addEventListener().

o Works in almost all browsers. If you still have to support IE <= 8, you 
can use a polyfill from MDN.




2. element.onevent = function() {}
(e.g. onclick, onload)


This was a way to register event handlers in DOM 0. It's now discouraged, 
because it:

o Allows you to register only one event handler. Also removing the 
assigned handler is not intuitive, because to remove event handler 
assigned using this method, you have to revert onevent property back to 
its initial state (i.e. null).

o Doesn't respond to errors appropriately. For example, if you by mistake 
assign a string to window.onload, for example: window.onload = "test";, it 
won't throw any errors. Your code wouldn't work and it would be really 
hard to find out why. .addEventListener() however, would throw error (at 
least in Firefox): TypeError: Argument 2 of EventTarget.addEventListener 
is not an object.

o Doesn't provide a way to choose if you want to handle an event in its 
capturing or bubbling phase.





3. Inline event handlers (onevent HTML attribute)

Similarly to element.onevent, it's now discouraged. Besides the issues 
that element.onevent has, it:

o Is a potential security issue, because it makes XSS much more harmful. 
Nowadays websites should send proper Content-Security-Policy HTTP header 
to block inline scripts and allow external scripts only from trusted 
domains.

o Doesn't separate document structure and logic.

o If you generate your page with a server-side script, and for example you 
generate a hundred links, each with the same inline event handler, your 
code would be much longer than if the event handler was defined only once. 
That means the client would have to download more content, and in result 
your website would be slower.

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart]

I should fix my semantics.  I realized that I use "handlers" to 
refer to both kinds of things and it could be unclear.  If it makes 
sense from context, you can ignore the following, but I am going to clean this up 
slightly if you want to read this revision instead.

On Fri, 26 Jan 2018, Kevin Carhart wrote:


I am not positive, but I think we're doing both systems right, and the two 
systems coexist.
An element could have onclick and click$$array.  It could respond to 
onclick() and click(), and they could both be sitting there. I think the 
former is called in a more narrow case, if it exists on that element, and 
also I believe that there is only one at a time, and if you set a new one, it 
clobbers the old.  Since the latter is an array, there could be any number.
>
>> When you click on a button or link, are we suppose to try to run both 
>> click() and onclick()?
>> If not, then when on earth do the click() handlers run?

I think that the click() handlers [LISTENER-BASED] would run based on the 
element's presence or absence from a set which had had a handler 
[LISTENER-BASED] applied, while onclick is a single function and would run 
if it had been established either in HTML or by defining the function on 
that thing.

I think the handlers [LISTENER-BASED] are less individual.  If it's a div, 
and there was code that said 
getElementsByTagName("div").addEventListener("click",code), then the 
ultimate effect is that the element in question has had that handler 
[LISTENER-BASED] doled out to it as part of a set of 30 or some total. 
So it's the efficiency of not having to think about that work as much, the 
way you don't have to think about every intersecting position in two 
nested loops.

I think isn't it also true that all of the attributes beginning with "on" are 
one-of-a-kind entities?  For instance, in decorate.c, lists of handlers 
[INDIVIDUAL FUNCTION-BASED] like 
"onclick", "onchange", "onsubmit" are called out for potentially unique code 
for each one.  So I think the addEventListener system is geared for 
intra-javascript, where the event names themselves might be "x1", "x2" and 
"x3" and the naming could itself be based on control structures or any type 
of logic.  It could be as ephemeral as any variable.  So every possible event 
name does not have hardcoded presence.  It's a genericization.

Ah, so I thought of a reason why these two things both exist.  It makes sense 
to hardcode onload, because there is only one, and you would not get any 
performance or workload benefit out of being able to parameterize it. It's 
correct to say onload.  I think it's historical - those 30 things have 
specific definition in HTML, while the listener system opens it up so that
events can be named anything.

Here's one more short reference which I thought was pretty good.  It's part 
of a stackoverflow page, by Michal Perlakowski, early 2016.  The original is 
https://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick

---

In this answer I will describe the three methods of defining DOM event 
handlers.

1. element.addEventListener()

element.addEventListener() has multiple advantages:

o Allows you to register unlimited events handlers and remove them with 
element.removeEventListener().

o Has useCapture parameter, which indicates whether you'd like to handle an 
event in its capturing or bubbling phase.

o Cares about semantics. Basically, it makes registering event handlers more 
explicit. For a beginner, a function call makes it obvious that something 
happens, whereas assigning event to some property of DOM element is at least 
not intuitive.

o Allows you to separate document structure (HTML) and logic (JavaScript). In 
tiny web applications it may not seem to matter, but it does matter with any 
bigger project. It's way much easier to maintain a project which separates 
structure and logic than a project which doesn't.

o Eliminates confusion with correct event names. Due to using inline event 
listeners or assigning event listeners to .onevent properties of DOM 
elements, lots of inexperienced JavaScript programmers thinks that the event 
name is for example onclick or onload. on is not a part of event name. 
Correct event names are click and load, and that's how event names are passed 
to .addEventListener().

o Works in almost all browsers. If you still have to support IE <= 8, you can 
use a polyfill from MDN.




2. element.onevent = function() {}
(e.g. onclick, onload)


This was a way to register event handlers in DOM 0. It's now discouraged, 
because it:

o Allows you to register only one event handler. Also removing the assigned 
handler is not intuitive, because to remove event handler assigned using this 
method, you have to revert onevent property back to its initial state (i.e. 
null).

o Doesn't respond to errors appropriately. For example, if you by mistake 
assign a string to window.onload, for example: window.onload = "test";, it 
won't throw any errors. Your code wouldn't work and it would be really hard 
to find out why. .addEventListener() however, would throw error (at least in 
Firefox): TypeError: Argument 2 of EventTarget.addEventListener is not an 
object.

o Doesn't provide a way to choose if you want to handle an event in its 
capturing or bubbling phase.





3. Inline event handlers (onevent HTML attribute)

Similarly to element.onevent, it's now discouraged. Besides the issues that 
element.onevent has, it:

o Is a potential security issue, because it makes XSS much more harmful. 
Nowadays websites should send proper Content-Security-Policy HTTP header to 
block inline scripts and allow external scripts only from trusted domains.

o Doesn't separate document structure and logic.

o If you generate your page with a server-side script, and for example you 
generate a hundred links, each with the same inline event handler, your code 
would be much longer than if the event handler was defined only once. That 
means the client would have to download more content, and in result your 
website would be slower.

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

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

> I think isn't it also true that all of the attributes beginning with "on" are
> one-of-a-kind entities?

Do you mean there is just one of them? I don't think so.
I think some websites start with onclick= in html, for a handler, then add another one via javascript and they are both suppose to run, at least I sort of remember that but can't point to a specific site right now.
So my code supports this.
If there is already a function onclick, that becomes onclick array[0], and the next one pushes and so on.
That's what I do, and it may not be right, but I don't think it's wrong.

So all of this doesn't answer my question.
You type g to "click" on a link or button,
do I run onclick, or all the onclick functions, for that node, or for all the nodes going up the tree, and/or,
do I run any and all click functions for that node, or all the nodes going up the tree?
onchange and change, onsubmit and submit ...
I really don't know what to do.
At this point I run all onclick handlers at and above the current node.
See handlerGoBrowse at html.c line 1778.

Karl Dahlke

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart]

Hi Karl

>
> So all of this doesn't answer my question.

I think you only have to run onclick, because the "click" system is 
running all the time.  As long as we provide a DOM, and the 
ID and name and class attributes are all standard, the code is establishing, removing, 
and calling all the time.  And also due to the presence of side effects 
like instant innerHTML.    That Drescher site is an example.  One of the 
links triggers ajax, and this is not tied either to a hyperlink or inline 
"on" handler.  There's another source.  The hyperlink has standard IDs, 
so our DOM methods rope it in to a set that is queried for with the 
GetElements functions.  Then, because that certain <A> was in the result 
set, it gets a click handler doled out to it which then works for the 
user.  So we're doing both already - I think.


>> I think isn't it also true that all of the attributes beginning with "on" are
>> one-of-a-kind entities?
>
> Do you mean there is just one of them? I don't think so.
> I think some websites start with onclick= in html, for a handler, then add another one via javascript and they are both suppose to run, at least I sort of remember that but can't point to a specific site right now.
> So my code supports this.
> If there is already a function onclick, that becomes onclick array[0], and the next one pushes and so on.
> That's what I do, and it may not be right, but I don't think it's wrong.

Sorry, I sort of mixed two connotations here.  In that particular thing 
about the one-of-a-kind entities, I was only trying to refer to the fact 
that you have hand-tailored work such as the function set_onhandlers() in 
decorate, which does a lot for a small number of useful inline handlers. 
So this might coexist comfortably with a different system that is suited 
for dynamic naming that does not need to have been delineated at compile 
time.

But the other thing you raised from this was:

> Do you mean there is just one of them? I don't think so.

I think we have it from the horse's mouth from a mozilla page.

https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers

The Web platform provides several ways to get notified of DOM events.  Two 
common styles are: the generalized addEventListener() and a set of 
specific on-event handlers. This page focuses on the details of how the 
latter work. ... The on-event handlers are a group of properties offered 
by DOM elements to help manage how that element reacts to events. Elements 
can be interactive (e.g. links, buttons, images, forms) or non-interactive 
(e.g. the base document). Events are the actions like being clicked, 
detecting pressed keys, getting focus, etc. The on-event handler is 
usually named according to the event it is designed to react to, such as 
onclick, onkeypress, onfocus, etc.... Note that each object can have only 
one on-event handler for a given event (though that handler could call 
multiple sub-handlers). This is why addEventListener() is often the 
better way to get notified of events, especially when wishing to apply 
various event handlers independently from each other, even for the same 
event and/or to the same element.

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

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

Ok, I need to boil all this down. It sounds like I'm doing the right thing, calling the onclick handlers but not the click handlers.
Still, I think that's confusing as hell.
If click() isn't automatically called by clicking then for Christ sake don't call it click! Call it foobar or something else.
Unless ... the one onclick function throws the click event and then everything follows from there, I could grok that,
but if click is truly separate from clicking, and just called click for fun, well, that's just bad programming.

Karl Dahlke

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Geoff McLane]

Hi Karl,

Do not know anything about prepending "on", but...

Out of interest I just tried the latest EB
on https://www.nasa.gov and found that this
page is entirely built in javascript!

That is the base html is real simple, skipping the head, and the scripts -

<body class="html front not-logged-in page-indexhtml show-topics-menu"
class="Array">
<div class="l-page ember-init-hide">
 <header class="l-header container-fluid" role="banner"></header>
 <div class="l-main">
 <div class="l-content container-fluid" id="main" role="main">
 <script>
 ...
 </script>
 </div>
 </div>
 <footer class="l-footer container-fluid" role="contentinfo"></footer>
</div>
  <script>
  ...
  </script>
</body>

You can see the 'header', 'main', and 'footer' html is
all generated content...

Now I used a special DEBUG version of libtidy which
show many lines of tidy processing this... part of the
output, again skipping the head ....

  StartTag body   class="Array"
   StartTag div   class="l-page ember-init-hide"
    StartTag header   class="l-header container-fluid" role="banner"
    StartTag div   class="l-main"
     StartTag div   class="l-content container-fluid" id="main" role="main"
      StartTag script
       Text   (6034) '...y","id":"4739"},];
'
    StartTag footer   class="l-footer container-fluid" role="contentinfo"
   StartTag script
    Text   (533) '...a);
     })();

This basically shows the html page as read, with
no real content...

Then javascript is run, and I should see lots
of generated nodes, but I get almost nothing back...
although libtidy is called some 14 times...

That is the next time tidy is run I only get -

  StartTag body
   StartTag a   href="#"

And similarly the 3rd time tidy is run -

  StartTag body
   StartTag form implicit
    StartEnd input

And again the 4th time tidy is run -

  StartTag body
   StartEnd link
   StartTag table
   StartTag a   href="/a"
    Text   (1) 'a'
   StartTag form implicit
    StartEnd input   type="checkbox"

tidy for 5th time

  StartTag body
   StartTag textarea
    Text   (1) 'x'

6th time into libtidy

  StartTag body
   StartTag form implicit
    StartEnd input   type="radio" checked="checked" name="t"

7th time into tidy

  StartTag body
   StartEnd link
   StartTag table
   StartTag a   href="/a"
    Text   (1) 'a'
   StartTag form implicit
    StartEnd input   type="checkbox"

8th time

  StartTag body
   StartEnd link
   StartTag table
   StartTag a   href="/a"
    Text   (1) 'a'
   StartTag form implicit
    StartEnd input   type="checkbox"

9th -

  StartTag body
   StartTag div

And it more or less continues that way
through 10th to 14th time libtidy is called...

That is, there is no substantial html generated,
and as you point out it seems no multiple
hrefs are generated and added to the DOM.

Visually reviewing the page in a browser, I
can see 20 to 50 hrefs. The header is a set of
javascipt driven drop-down links... The body is
some images, each of which is a link... and as
you point out the footer is a set of links, the
last being "Contact NASA" -
link https://www.nasa.gov/about/contact/index.html

So something is either wrong with duktape html
generation, or for some reason it does not get
back to EB, at least not to libtidy...

Now to test a simpler case of javascript html
generation, I constructed a test1.html -
http://geoffair.org/tmp/test1.html - I think
I constructed some of it from your jsrt...

And the first time libtidy is run I see

  StartTag body
   StartTag h1
    Text   (5) 'test1'
   StartTag script
    Text   (661) '
func...fair<\/a><\/p>");

That script contains 2 document.write's...

But then the javascript is run, and the
next libtidy output contains the 2 new html
nodes -

  StartTag body
   StartTag p
    Text   (24) 'date: 2002/11/25 17:55:9'
   StartTag p
    Text   (6) 'link: '
    StartTag a   href="http://geoffair.com"
     Text   (8) 'geoffair'

So everything works well in this `simple` case...

Why does the nasa javascript fail to generate
many, MANY new nodes, with many, many links?

Do not know what else I can try... maybe finding
where duktape passes back html, and add a debug
output, or something... I have tried before debugging
into duktape library, but that is mind boggling...

Will try anything you can suggest...

But hope this helps...

Geoff.

PS: Normally I send this from my Ubuntu
Thunderbird email client but this time
from a Windows machine, so hope it works!

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

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

This is a good start and a good strategy.
I can capture all the generated html with db5, though I have to do some editing to pull that out and separate it from all the other debug messages.
But we must remember this is only part of the story.
You can build the page piece by piece, without generating any html at all.
Create each table, each cell, each paragraph, each anchor, literally build it from the ground up using the DOM primitives.
NASA might be doing that.
I mean there's obviously more text on the page than you see in html, even if it isn't complete and isn't linked properly.
This stuff is not easy.

Karl Dahlke

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart]

> Still, I think that's confusing as hell.

I agree.  There is a looser tethering with a piece of GUI that you can 
click on, compared to the inline "on" handlers.  Or no tethering at all. 
It's just a string, "click".  There is no requirement about what the 
handler contains or what it's applied to.  You can turn a dog into a 
cat using CSS, JS and HTML if you feel like intercepting and managing 
everything yourself.

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Geoff McLane]

Hi Karl,

Maybe I do not exactly understand by constructing
the page using DOM primatives, but have built
a test2.html -
http://geoffair.org/tmp/test2.html

There the links are built using the javascript -
 var menu = document.body.appendChild( document.createElement( 'div' ) );
 var menu2 = menu.appendChild( document.createElement( 'div' ) );

And then the html is created using menu.innerHTML =, and likewise
for menu2. menu is a h2 with a link, and menu2 is a table with
4 links...

And as stated using my special DEBUG libtidy, when I browse
test2.html I see three libtidy outputs -

First
  StartTag body   onload="init();"
   StartTag h1
    Text   (5) 'test2'

Second
  StartTag body
   StartTag h2
    StartTag a   href="http://edbrowse.org/usersguide.html#guide"
     Text   (8) 'edbrowse'

Third
  StartTag body
   StartTag table
    StartTag tr
     StartTag td
      StartTag a   href="http://google.com"
       Text   (6) 'google'
     StartTag td
      StartTag a   href="http://yahoo.com"
       Text   (5) 'yahoo'
     StartTag td
      StartTag a   href="http://microsoft.com"
       Text   (9) 'microsoft'
     StartTag td
      StartTag a   href="http://edbrowse.org/usersguide.html#guide"
       Text   (8) 'edbrowse'

In browse mode, the last line is indeed those 4 links,
and the command 1,p shows me - extra blank lines removed -

test2
{edbrowse}
{google}|{yahoo}|{microsoft}|{edbrowse}

I can use g1-4 and the link is fetched... beautiful...
great... working well, I think...

And if I set db5 and redirect the output to say tempdb5.txt,
I can see similar stuff in the tempdb5.txt file, but as
you point out it is mixed with a lot of other debug
output...

What I am saying is that I do not see that in browsing
nasa... There are some 14 callbacks with html that is
passed to libtidy... there are some partial links, and
other stuff passed back... but when it is all done, I
have nothing...

Now as stated, maybe I do not quite understand
"using DOM primatives", but I think that's what my
javascript does in this test2.html, and it succeeds
in creating html fragments that are passed back to
the browser to display...

And for instance, I can read in the nasa.js, for
creating the 'footer' links - uses -
buildFragment:function(e){ ... part of which is -

var r=e.createElement("li"),l=e.createElement("a");
e.setAttribute(l,"href","http://www.nasa.gov/about/contact/index.html");
var i=e.createTextNode("Contact NASA");
e.appendChild(l,i),e.appendChild(r,l),e.appendChild(a,r);

So I come back to why do I not see these created "li", "a"
with href shown, with text "Contact NASA", all appended...

This is certainly building the bottom 'footer' line
from the ground up... in fact ALL elements of the page
are built like this... header, content, footer...

There is no doubt the main contents of that page changes
regularly - what I see today is different to what I saw
yesterday...

So, I am still puzzled why more of the generated stuff
is not available in edbrowse...

Ok, to make sure I am not completely crazy, I constucted
a test3.html -
http://geoffair.org/tmp/test3.html
using as close as possible the javascript from nasa.js

In my chrome browser this correctly displays a
"Contact NASA" link, and it works fine... on clicking
the link shown I am taken to the desired page...

*** BUT IT TOO FAILS IN EDBROWSE!!! ***

This tends to indicate that duktape FAILS when the
var t = document.createDocumentFragment();
API is used, and that 'fragment', which has the
said link appended to it, is then appended to the
'footer' tag... or something...

So my test3 js code works in Chrome, AND Microsoft Edge,
BUT **not** in Edbrowse/duktape...

Is this it? Am I just seeing a limit in what
the chosen duktape library can do...

It should be noted I am still linking with
duktape 2.1.0, from a zip source, while it
seems the github git source indicates 2.2, or
higher -
https://github.com/svaarala/duktape/releases/tag/v2.2.0
I must get around to updating this...

That may make a difference... will do this
soonest... and I now have a very minimal test3.html
sample... but now sort of feel this is all 'outside'
edbrowse's direct control...

Regard,
Geoff.

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

Thank you so much for tracking down and preparing test3.html.
This is exactly the help I need.
These problems are almost certainly our DOM, and not duktape itself; I'd bet the farm on that.
I'll look through and see what I can find.

Karl Dahlke

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

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

Boy did you open a can of worms!
Most of this was percolating in my mind for some time, but this has brought it to the fore.

1. I didn't have a Footer class, or recognize the <footer> tag. Didn't know anything about it.
That was an easy fix, just a few lines of code, but without it the critical section in your test3 didn't even run.

2. A.href side effects.
First some background. If you set document.location = url, that is not suppose to replace the document location object with the string url.
It is a side effect setter; the string is suppose to pass into the document.location URL object.
And it has a further side effect of redirecting the browser to a new web page, but that is beyond the scope.
I had thought for some time that A.href is suppose to do the same thing.
If javascript wants to set, or change, the URL that a hyperlink points to,
it will just set A.href = blah.
Right now that replaces the URL object with the string, and sometimes that works, but that's not how it is suppose to work.
It is suppose to be, and remain, a URL object.

A. href Image.src Script.src Frame.src Link.href Area.href Form.action
Am I missing any?

There is a clever compact way to do this; put getters and setters on the prototypes of these classes, similar to those that are on document.location.
See startwindow.js line 1078.
This change is mostly transparent to the rest of edbrowse, you get and set A.href as usual, and go through getters and setters, but did I break something? I wouldn't be a bit surprised.
Well test it out and let me know.
Meantime, the line

    r.setAttribute("href","http://www.nasa.gov/about/contact/index.html");

from the NASA code now creates a URL object with the correct components.
But it still isn't rendered properly; see item 4 below.

3. This goes back to something Kevin said a month ago.
A web page was referencing A.protocol, which was never set.
He created a default empty string a.protocol = "", which got us past the error but made me feel uneasy.
I thought then, and still think, that this should be a getter and setter to dip into a.href.protocol.
It's basically a shortcut.
And similarly for the other components, so I made all these getters and setters.
See the two nested loops at startwindow.js line 1155.

4. Now the hyperlink was constructed properly, but was not rendered as a link in the edbrowse buffer.
I did not look dynamically, upon each render, to see if js had set, or changed, the url of that anchor.
Again, only a few lines of code, but it makes all the difference.
Now test3.html works.
As for nasa.gov, it's empty again. Did I break something?
I don't know, because it comes up empty on the earlier version, before I made any of these changes.
I backed out the last commit, with prepending "on" to the event, it still comes up empty.
And radiocaroline.co.uk hangs forever.
Are the websites changing out from under us? Am I missing something?   (disappointed)
Well I decided to push anyways, so you all can look and comment,
and we're all working with the same code.

Karl Dahlke

Re: [Edbrowse-dev] nasa / prepending "on" to events

[Geoff McLane]

Hi Karl,

Updated and rebuilt with your commit be902a4b33,
and can confirm my test3.html now works... thanks...

That is when browsing test3.html the link exists -
{Contact NASA}

It is different to say the test2.html case in
that there is no indication of this link output
by my debug libtidy...

It is there in the redirected db5 text -
...
> get href
< http://www.nasa.gov/about/contact/index.html
resolve(test3.html|http://www.nasa.gov/about/contact/index.html)
= http://www.nasa.gov/about/contact/index.html
...

However, as you state, I still get NOTHING browsing
the base nasa page... nor the above contact link page...

As we know both pages, and probably many others on
that nasa site, are built entirely by javascript...
but obviously my test3.html does not exactly mirror
the js used...

And the sort of basic 'template' used for each of these pages,
and probably others, is -

```html
 <body class="html ... etc ...">
  <div class="l-page ember-init-hide">
  <header class="l-header container-fluid" role="banner"></header>
   <div class="l-main">
    <div class="l-content container-fluid" id="main" role="main">
      <script>
       ...
      </script>
    </div>
   </div>
  <footer class="l-footer container-fluid" role="contentinfo"></footer>
  </div>
```

One small thing - I note you added a 'footer' array
and a case for it, in startwindow.js, assume that matches the tag -
<footer class="l-footer container-fluid" role="contentinfo"></footer>

What about the 'header' tag matching -
<header class="l-header container-fluid" role="banner"></header>
Or is this handled elsewhere?

And the other case is the main page content -
<div class="l-content container-fluid" id="main" role="main">

Each of these should contain a whole list of links... just
hovering my mouse over various parts of the visual page
and I count upwards of 70 different links... and edbrowse
gets NONE!

Of course the site is filled with stunning visual images,
but on most there is a LOT of readable text and descriptions,
and edbrowse gets 'nothing'!

Do not know what else to try... ideas welcome...

Regards,
Geoff.

[Edbrowse-dev] nasa / prepending "on" to events

[Karl Dahlke]

> What about the 'header' tag

Oops, indeed, ok I added that one. Thanks.
Also made a few more fixes to cloneNode, which NASA uses to get rolling, but still comes up empty.

Karl Dahlke