[Edbrowse-dev] Tidy error reporting

[Edbrowse-dev] Tidy error reporting

[Karl Dahlke]

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

As tidy has made some enhancements for us, which we appreciate, they also, on the same or earlier branch, changed slightly the means of error reporting.
Line and column number are now part of the message, and need not be reported by us.
More important, there are info errors, lots of them, that we don't need to see.
I made a 2 line change to accommodate this, (last push), which is no big deal, but I thought I'd give you a heads up, because it may not compile against the tidy master branch.
You might need the next branch or issue-643.
This means we don't want to release the next version of edbrowse until issue-643 is merged into master.
That's ok, we weren't hot to release a version anyways.
In fact it's not clear when to snapshot, as we are making many small yet important changes and improvements, rather than one big change.
At some point we'll just say it's time, and cut 3.7.2.
Once we get a few more web sites and/or acid tests working, and it just feels right.

Karl Dahlke

[Edbrowse-dev] data-* attributes

[Kevin Carhart]

Thanks for the recent message about the tidy changes.

Karl, you asked about the site oranges.com and said links aren't working 
and they used to.

There is something going on with the attribute data-source, and more 
generally maybe with data-* attributes, which are part of html5.

A link in oranges looks like..
<a href="/wine-basket" 
data-source="a1b9910284ad8c677b8d3ec4b464ce6ebbd0e6c7f8d8ead8b20bb80596edf86d1fa76d1417b2ca95bfd19c3ab9ff0bf6f9f98fbd283bd71e4e36b34ae70d2b852c6c61f8bc9cc7cfb33613393216eda8253513da19f726536504e22590e7d2b783a2e6357490c911d5fcab6b21cc911149047db90ccfdea7">Wine 
Basket</a>


And the javascript later wants to reference:
$(this).attr("data-source")

Where this is the link that has just been clicked.

But that attribute isn't there, so it can't read/write its value to a 
cookie, namely a hash corresponding to a given link destination.  (I dunno 
what was wrong with plain hyperlinks but that's what they use.)

I think tidy knows about these attributes, because they are referenced in 
the tidy file attrs.c

So maybe we want to make a change in decorate.

I wonder what's missing.  Maybe something in decorate.  Should attributes 
beginning with data-* be hardcoded, or should any arbitrary name-value 
pair be passed along and use Attributes as a catch-all?

Here's the relevant function.  It is document.scripts[2].data

         $(function() {
                 $("a").click(function() {
                         document.cookie = "_utms=" + 
($(this).attr("data-source") ? $(this).attr("data-source") : 
"a1b9910284ad8c677b8d3ec4b464ce6ebbd0e6c7f8d8ead8b20bb80596edf86d1fa76d1417b2ca951a0ccb450672500b") 
+ "; path=/";
                 });
                 $("form").submit(function() {
                         document.cookie = "_utms=" + 
($(this).attr("data-source") ? $(this).attr("data-source") : 
"a1b9910284ad8c677b8d3ec4b464ce6ebbd0e6c7f8d8ead8b20bb80596edf86d1fa76d1417b2ca951a0ccb450672500b") 
+ "; path=/";
                 });
         });




K












Date: Sun, 19 Nov 2017 08:32:43
From: Karl Dahlke <eklhad@comcast.net>
To: kevin@carhart.net
Subject: www.oranges.com

The links on this page don't work, and I'm pretty sure they use to.
Line 113 {The Color Orange} {Wine Basket} etc
Just make a note of it if we don't have time to investigate right now.

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes

[Kevin Carhart]

>
> Here's the relevant function.  It is document.scripts[2].data

Sorry, not document.scripts[2].  It is actually document.scripts[1]

[Edbrowse-dev] data-* attributes

[Karl Dahlke]

> Karl, you asked about the site oranges.com and said links aren't working
> There is something going on with the attribute data-source,

Yes, you're right, this is a problem that we must fix. I'll write more on that later.
Oddly enough, that's not why the link doesn't work.
I can set the attribute as it should be via jdb, and still the link doesn't work.
The onclick function returns nothing, and it should return true or false.
I interpret nothing as false, and the hyperlink does not run.
This is a real world website, so I guess I should interpret undefined as true, and move forward with the link.
Similar comments apply for submitting a form etc.
My last push makes this minor yet important change.
It's possible that a lot of links on a lot of websites will start working.
Here are the comments that I added to the source.

/*********************************************************************
run_function_bool()
This function is typically used for handlers: onclick, onchange, onsubmit, onload, etc.
The return value is sometimes significant.
If a hyperlink has an onclick function, and said function returns false,
the hyperlink is not followed.
If onsubmit returns false the form does not submit.
And yet this opens a can of worms. Here is my default behavior for corner cases.
I generally want the browser to continue, unless the function
explicitly says false, or fails.
the function doesn't exist. (false)
The function encounters an error during execution. (false)
The function returns a bogus type like object, or a string like foo
that is not true or false. (true)
The function returns undefined. (true)
*********************************************************************/

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes

[Kevin Carhart]

Thanks Karl , oh yeah, I got part of my investigation right but I 
misunderstood the meaning and functional importance of those hashes. 
Interesting, huh?  So the site is saying, this onclick is spliced into 
the middle.  The code that the handler runs simply records where they 
came from (for who knows why - for some reason like tracking the 
relative popularity of site sections as part of SEO), and then 
it is expecting to hand back control to regular hyperlinks to go to the 
new destination.

On Wed, 22 Nov 2017, Karl Dahlke wrote:

>> Karl, you asked about the site oranges.com and said links aren't working
>> There is something going on with the attribute data-source,
>
> Yes, you're right, this is a problem that we must fix. I'll write more on that later.
> Oddly enough, that's not why the link doesn't work.
> I can set the attribute as it should be via jdb, and still the link doesn't work.
> The onclick function returns nothing, and it should return true or false.
> I interpret nothing as false, and the hyperlink does not run.
> This is a real world website, so I guess I should interpret undefined as true, and move forward with the link.
> Similar comments apply for submitting a form etc.
> My last push makes this minor yet important change.
> It's possible that a lot of links on a lot of websites will start working.
> Here are the comments that I added to the source.
>
> /*********************************************************************
> run_function_bool()
> This function is typically used for handlers: onclick, onchange, onsubmit, onload, etc.
> The return value is sometimes significant.
> If a hyperlink has an onclick function, and said function returns false,
> the hyperlink is not followed.
> If onsubmit returns false the form does not submit.
> And yet this opens a can of worms. Here is my default behavior for corner cases.
> I generally want the browser to continue, unless the function
> explicitly says false, or fails.
> the function doesn't exist. (false)
> The function encounters an error during execution. (false)
> The function returns a bogus type like object, or a string like foo
> that is not true or false. (true)
> The function returns undefined. (true)
> *********************************************************************/
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

Re: [Edbrowse-dev] data-* attributes

[Kevin Carhart]

>> This is a real world website, so I guess I should interpret undefined as 
>> true, and move forward with the link.

I think this is probably true, but it might or might not be relevant to 
look at whether this actually is a real world website.  I mean, at one 
level it is, but this is a keywords and SEO-related website, like a link 
farm for gaming Google's page rank.  You can tell because the relationship 
of the content to the word "orange" is not all there somehow.

Does this matter when all you are 
assessing is the prevalence of their technical phrasing??  Maybe not, but 
the perversity or orneryness in terms of the site authors' goals might 
reflect on whether it's a good proxy for the world..  of course if the 
world is also perverse and ornery then you're fine.

[Edbrowse-dev] data-* attributes

[Karl Dahlke]

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

I have addressed the problem uncovered by Kevin, wherein foo=bar in an html tag does not make it over to the js world.
Well it doesn't get there because I didn't implement it. Just didn't do it.
The only tricky part here is identifying all the exceptions.
Example <a style="style directives">
we have special code to manage this, creating a style object under the a object, then in that style object things like background=red and so on,
and if I then mindlessly set style to its string, as if it was foo=bar, then all that work is thrown away and it doesn't work.
Same comments for onclick = some javascript function, which actually compiles the function and puts that in under onclick, and you wouldn't want that thrown away and replaced with its string.
So there's a list of exception attributes that we manage specialy, and if not in this list, then I go ahead and set object.attribute=value.
The cookie set by oranges.com when you go somewhere else should now be correct, for whatever that's worth.
As always, we hope this makes a few other things work too.

Karl Dahlke

[Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

Thank you for figuring out the attributes and exceptions!

Well I certainly feel efficient, because during this time, I had another 
look at radiocaroline and I found a couple of good ones.

I did about six things entirely in startwindow, and I'm sending you my 
revised startwindow file.  Since attachments are no good, could you 
retrieve it from...
http://carhart.net/~kevin/startwindow_20171124.zip

I made sure to grab the latest edbrowse, with the attribute change 
(63c049f1f6253f952636270be62761dfeeb37281) so hopefully there will not be 
a collision.

Here are the changes:
(1) I added an element called Audio in the three places that the litany of 
element names appears.  Some of radiocaroline's javascript files try 
to instantiate new Audio()

(2) I set up localStorage.  What does localStorage do for developers that 
isn't already satisfied by cookies?  I don't know, but 
radiocaroline wants to use it. 
It expects to call setItem, getItem and removeItem.  So I just made a 
localStorage object and made those three methods into aliases for 
setAttribute, getAttribute and removeAttribute.

(3) Added 'onload' in addition to 'onreadystatechange' in the 
XMLHttpRequest code.  Apparently onreadystatechange is associated with out 
of date browsers, and newer versions of jquery (>=2) have switched to 
onload.  I hope this change will make ajax on some other sites succeed.

(4) Add 'Image' to the short list of element types that gets the addEvent 
code added to its prototype.  Radiocaroline has an onclick on an Image.

(5) I added a brick of eb$nullfunction stubs for a lot of Canvas methods, 
in place of the three or four that we had.  Radiocaroline calls a 
canvas-related library, which wants several of these to be there.  I 
started out by making a stub for one, compile, try again, and it would 
raise an error on the next one.  So that's why I added the whole list.

(6) I added encodeURI to the XHR code.  There is an ajax request for some 
JSON in the radiocaroline code, and it appends Date(), I think because 
this is a trick to avoid cacheing.  Usually those types of appends are in 
timestamp style, but this one comes out like 'Nov 23 2017'.  Then the CURL 
action was failing because the spaces in the request weren't encoded.

hope some of these will be good... try out radio caroline after applying - 
the menus show up via ajax!  Unfortunately the links lead you into a black 
hole which I'd like to discuss separately, but one thing at a time.

K


On Fri, 24 Nov 2017, Karl Dahlke wrote:

> I have addressed the problem uncovered by Kevin, wherein foo=bar in an html tag does not make it over to the js world.
> Well it doesn't get there because I didn't implement it. Just didn't do it.
> The only tricky part here is identifying all the exceptions.
> Example <a style="style directives">
> we have special code to manage this, creating a style object under the a object, then in that style object things like background=red and so on,
> and if I then mindlessly set style to its string, as if it was foo=bar, then all that work is thrown away and it doesn't work.
> Same comments for onclick = some javascript function, which actually compiles the function and puts that in under onclick, and you wouldn't want that thrown away and replaced with its string.
> So there's a list of exception attributes that we manage specialy, and if not in this list, then I go ahead and set object.attribute=value.
> The cookie set by oranges.com when you go somewhere else should now be correct, for whatever that's worth.
> As always, we hope this makes a few other things work too.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

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

This is lovely!
I applied your startwindow.js file and was going to push but I had to change something and wanted to check with you first.
You have localStorage in eb$master but I don't think that works.
I suspect each window has its own local storage.
Furthermore, if one window could access the local storage of another window it is probably a security hole that some clever person could exploit for bad things.
So I put it in the standard window, including localStorage.attributes = [] which you forgot but setAttribute() needs.
If this seems right to you I'll push.

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

Yep, thank you for improving it, please fire away.
Kevin


On Fri, 24 Nov 2017, Karl Dahlke wrote:

> This is lovely!
> I applied your startwindow.js file and was going to push but I had to change something and wanted to check with you first.
> You have localStorage in eb$master but I don't think that works.
> I suspect each window has its own local storage.
> Furthermore, if one window could access the local storage of another window it is probably a security hole that some clever person could exploit for bad things.
> So I put it in the standard window, including localStorage.attributes = [] which you forgot but setAttribute() needs.
> If this seems right to you I'll push.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

Ok. It's in.

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

Great progress!

Can you make heads or tails out of this behavior when you try to click 
those links, like the top15s or the schedule?  It takes you to a 
netherworld of size 0, and you have to back up with ^.  It's as though you 
went to an empty frame, or like when you add additional ed environments 
for editing.

Here's the code for the click handler which has been added to "a" 
elements.  It's in the file menus.js.  I don't think a click is triggering 
this code, because I added some alerts and they don't show up.

         function parse_menu_item(url, externalURL, soundURL){
         //if(soundURL) playSound(soundURL);
         if(externalURL){
         window.open(externalURL); // open url in external window only
         return false; // no need to proceed
         }else if(url == "donate.html"){
         slidePopupPanel();
         }else{
         window.location.hash = url; // apply hash to address bar
         }
         }

Maybe it's something to do with the hash change.  Is that supposed to 
trigger http action to a new destination?

K

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

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

Before we attack that one I think we have a bigger problem.
Browse the home page with db3.
After it is browsed, it seems to fetch a page every 5 seconds, and each time it puts that page into cache, even though it seems to be the same page.
Why is it doing that? What does that mean?

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

Hmm.. I think it's a json file that shows you continuous updating of what 
is playing on the station right this moment.

{"songs":[{"acrid":"86f891c0fbab6d78754d568e49dfe986","artist":"John's 
Children","title":"Go-Go Girl","album":"The Complete John's 
Children","duration":130000},{"acrid":"3dcce24c501ab5b248797d6a6a79af08","artist":"Smokey
River Boys","title":"Stone Fox Chase","album":"20 Greatest Hits of 
Bluegrass","duration":"206267"}

If we don't like the chattyness and undesired network activity, could we 
default the xhr flag to off?  Apparently you get the one manifestation of 
working xhr, along with the other.  Shut it off, and the menus don't flow 
in in the first place.  Turn it on and it's now very chatty and does 
dynamic things you may not want.

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

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

That's cool, as long as it's suppose to do that and it's not an edbrowse bug.
I can turn xhr off if I'm in jdb poking around, and don't want to be bothered with that, and turn it back on when I want to actively do something.

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

I don't think it's an edbrowse bug.  In fact, if I go to 
carolineflashback.co.uk, the entire conduit works and the updates find 
their home inside of a div or whatever harness, in edbrowse rendering!
On the main rc, I think it's the same architecture, but maybe there is a 
confound somewhere, so the network activity occurs but the new text does 
not make it back to its html harness yet.

05:22 Currently on-air

Continuous Flashback Music

Next at 08:00

Roger Day

line 1 has been updated

05:23 Currently on-air

Continuous Flashback Music

Next at 08:00

Roger Day

line 1 has been updated

05:24 Currently on-air

Continuous Flashback Music

Next at 08:00

Roger Day

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

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

After browsing the home page, I set db4 and went to the Our Ship link, to find out about the Ross Revenge, they broadcast from a ship or some such silliness, anyways, got this.

g
jSyncup starts
jSyncup ends
execute onmouseover
execution complete
jSideEffects starts
jSideEffects ends
execute onclick
TypeError: undefined not callable (property 'preventDefault' of [object Object])
execution complete
jSideEffects starts
jSideEffects ends
rerender

So the onmouseover code ran, and then the onclick code got an error, and as you remember from my last post, I return false in this case,
as if to say, the javascript did not run properly, it is not safe to proceed.
Thing is, 90% of the time it is safe to proceed, but if the js was setting things up for a purchase on an ecommerce site, then maybe it's not safe to proceed.
I'm really not sure what to do here.
The disadvantage of my conservative stance is, a lot of links don't work that should work.
I'm just trying to find out about the damn ship!!
The advantage: it sort of forces us to get things working properly, instead of just running around and past the problems.

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11092 bytes --]


> After browsing the home page, I set db4 and went to the Our Ship link,

I think there are strands of a couple of causes at once, maybe.

I recognize preventDefault.  This has to do with Event.

If you clone https://github.com/thatcher/env-js.git

and go to src/event/event.js , preventDefault is here.  It has to do with 
bubbling/capturing, which is what that third argument to addEventHandler 
is about.  And this env code is where I got the Event = function(){
definition from.

I think we want eb$master.Event.prototype.preventDefault, and maybe some 
others like eb$master.Event.prototype.stopPropagation.  But this raises 
the question of bubbling & capturing.  I think that's what radiocaroline 
is trying to call preventDefault for.  I'm going to include an article that MDN 
links, because it seems like useful history.  If we understand this 
theme, maybe we ought to revisit that third argument to addEventListener, 
which if you remember we currently set aside and call it 'notused'.

The author is Peter-Paul Koch and the article is at 
https://www.quirksmode.org/js/events_order.html

---

Netscape 4 only supports event capturing, Explorer only supports event 
bubbling. Netscape 6 and Konqueror support both, while Opera and iCab 
support neither.

On the Introduction to events page I asked a question that at first sight 
seems incomprehensible: “If an element and one of its ancestors have an 
event handler for the same event, which one should fire first?” Not 
surprisingly, this depends on the browser.

The basic problem is very simple. Suppose you have a element inside an 
element and both have an onClick event handler. If the user clicks on 
element2 he causes a click event in both element1 and element2. But which 
event fires first? Which event handler should be executed first? What, in 
other words, is the event order?

Two models

Not surprisingly, back in the bad old days Netscape and Microsoft came to 
different conclusions.

     Netscape said that the event on element1 takes place first. This is 
called event capturing.
     Microsoft maintained that the event on element2 takes precedence. This 
is called event bubbling.

The two event orders are radically opposed. Explorer only supports event 
bubbling. Mozilla, Opera 7 and Konqueror support both. Older Opera's and 
iCab support neither.

Event capturing

When you use event capturing

[arrow pointing DOWN from element1 to element2]

the event handler of element1 fires first, the event handler of element2 
fires last.

Event bubbling

When you use event bubbling

[diagram with an arrow pointing up from element2 , then element1]

the event handler of element2 fires first, the event handler of element1 
fires last.

W3C model

W3C has very sensibly decided to take a middle position in this struggle. 
Any event taking place in the W3C event model is first captured until it 
reaches the target element and then bubbles up again.

[diagram that says "W3C event model."  First there's an arrow going down 
the tree from e1 to e2, and then a second arrow coming up from e2 to e1.]

You, the web developer, can choose whether to register an event handler in 
the capturing or in the bubbling phase. This is done through the 
addEventListener() method explained on the Advanced models page. If its 
last argument is true the event handler is set for the capturing phase, if 
it is false the event handler is set for the bubbling phase.

Suppose you do

element1.addEventListener('click',doSomething2,true)
element2.addEventListener('click',doSomething,false)

If the user clicks on element2 the following happens:

     The click event starts in the capturing phase. The event looks if any 
ancestor element of element2 has a onclick event handler for the capturing 
phase.
     The event finds one on element1. doSomething2() is executed.
     The event travels down to the target itself, no more event handlers 
for the capturing phase are found. The event moves to its bubbling phase 
and executes doSomething(), which is registered to element2 for the 
bubbling phase.
     The event travels upwards again and checks if any ancestor element of 
the target has an event handler for the bubbling phase. This is not the 
case, so nothing happens.

The reverse would be

element1.addEventListener('click',doSomething2,false)
element2.addEventListener('click',doSomething,false)

Now if the user clicks on element2 the following happens:

     The click event starts in the capturing phase. The event looks if any 
ancestor element of element2 has a onclick event handler for the capturing 
phase and doesn’t find any.
     The event travels down to the target itself. The event moves to its 
bubbling phase and executes doSomething(), which is registered to element2 
for the bubbling phase.
     The event travels upwards again and checks if any ancestor element of 
the target has an event handler for the bubbling phase.
     The event finds one on element1. Now doSomething2() is executed.

Compatibility with traditional model

In the browsers that support the W3C DOM, a traditional event registration

element1.onclick = doSomething2;

is seen as a registration in the bubbling phase.

Use of event bubbling

Few web developers consciously use event capturing or bubbling. In Web 
pages as they are made today, it is simply not necessary to let a bubbling 
event be handled by several different event handlers. Users might get 
confused by several things happening after one mouse click, and usually 
you want to keep your event handling scripts separated. When the user 
clicks on an element, something happens, when he clicks on another 
element, something else happens.

Of course this might change in the future, and it’s good to have models 
available that are forward compatible. But the main practical use of event 
capturing and bubbling today is the registration of default functions.

It always happens

What you first need to understand is that event capturing or bubbling 
always happens. If you define a general onclick event handler for your 
entire document

document.onclick = doSomething;
if (document.captureEvents) document.captureEvents(Event.CLICK);

any click event on any element in the document will eventually bubble up 
to the document and thus fire this general event handler. Only when a 
previous event handling script explicitly orders the event to stop 
bubbling, it will not propagate to the document.

Uses

Because any event ends up on the document, default event handlers become 
possible. Suppose you have this page:

[diagram of a document object with childNodes element1 and element2]

element1.onclick = doSomething;
element2.onclick = doSomething;
document.onclick = defaultFunction;

Now if the user clicks on element1 or 2, doSomething() is executed. You 
can stop the event propagation here, if you wish. If you don’t the event 
bubbles up to defaultFunction(). If the user clicks anywhere else 
defaultFunction() is also executed. This might be useful sometimes.

Setting document–wide event handlers is necessary in drag–and–drop 
scripts. Typically a mousedown event on a layer selects this layer and 
makes it respond to the mousemove event. Though the mousedown is usually 
registered on the layer to avoid browser bugs, both other event handlers 
must be document–wide.

Remember the First Law of Browserology: anything can happen, and it 
usually does when you’re least prepared for it. So it may happen that the 
user moves his mouse very wildly and the script doesn’t keep up so that 
the mouse is not over the layer any more.

     If the onmousemove event handler is registered to the layer, the layer 
doesn’t react to the mouse movement any more, causing confusion.
     If the onmouseup event handler is registered on the layer, this event 
isn’t caught either so that the layer keeps reacting to the mouse 
movements even after the user thinks he dropped the layer. This causes 
even more confusion.

So in this case event bubbling is very useful because registering your 
event handlers on document level makes sure they’re always executed.

Turning it off

But usually you want to turn all capturing and bubbling off to keep 
functions from interfering with each other. Besides, if your document 
structure is very complex (lots of nested tables and such) you may save 
system resources by turning off bubbling. The browser has to go through 
every single ancestor element of the event target to see if it has an 
event handler. Even if none are found, the search still takes time.

In the Microsoft model you must set the event’s cancelBubble property to 
true.

window.event.cancelBubble = true

In the W3C model you must call the event’s stopPropagation() method.

e.stopPropagation()

This stops all propagation of the event in the bubbling phase. For a 
complete cross-browser experience do

function doSomething(e)
{
 	if (!e) var e = window.event;
 	e.cancelBubble = true;
 	if (e.stopPropagation) e.stopPropagation();
}

Setting the cancelBubble property in browsers that don’t support it 
doesn’t hurt. The browser shrugs and creates the property. Of course it 
doesn’t actually cancel the bubbling, but the assignment itself is safe.

currentTarget

As we’ve seen earlier, an event has a target or srcElement that contains a 
reference to the element the event happened on. In our example this is 
element2, since the user clicked on it.

It is very important to understand that during the capturing and bubbling 
phases (if any) this target does not change: it always remains a reference 
to element2.

But suppose we register these event handlers:

element1.onclick = doSomething;
element2.onclick = doSomething;

If the user clicks on element2 doSomething() is executed twice. But how do 
you know which HTML element is currently handling the event? 
target/srcElement don’t give a clue, they always refer to element2 since 
it is the original source of the event.

To solve this problem W3C has added the currentTarget property. It 
contains a reference to the HTML element the event is currently being 
handled by: exactly what we need. Unfortunately the Microsoft model 
doesn’t contain a similar property.

You can also use the this keyword. In the example above it refers to the 
HTML element the event is handled on, just like currentTarget.

Problems of the Microsoft model

But when you use the Microsoft event registration model the this keyword 
doesn’t refer to the HTML element. Combined with the lack of a 
currentTarget–like property in the Microsoft model, this means that if you 
do

element1.attachEvent('onclick',doSomething)
element2.attachEvent('onclick',doSomething)

you cannot know which HTML element currently handles the event. This is 
the most serious problem with the Microsoft event registration model and 
for me it’s reason enough never to use it, not even in IE/Win only 
applications.

I hope Microsoft will soon add a currentTarget–like property — or maybe 
even follow the standard? Web developers need this information.

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

> After browsing the home page, I set db4 and went to the Our Ship link,

I think there are strands of a couple of causes at once, maybe.

I recognize preventDefault.  This has to do with Event.

If you clone https://github.com/thatcher/env-js.git

and go to src/event/event.js , preventDefault is here.  It has to do with 
bubbling/capturing, which is what that third argument to addEventHandler 
is about.  And this env code is where I got the Event = function(){ 
definition from.

I think we want eb$master.Event.prototype.preventDefault, and maybe some 
others like eb$master.Event.prototype.stopPropagation.  But this raises 
the question of bubbling & capturing.  I think that's what radiocaroline 
is trying to call preventDefault for.  I'm going to include an article 
that MDN links, because it seems like useful history.  If we understand 
this theme, maybe we ought to revisit that third argument to 
addEventListener, which if you remember we currently set aside and call it 
'notused'.  I put it on carhart.net and cleaned it up slightly.  Please 
pull it up when you have a moment.

http://carhart.net/~kevin/ppk_events.html

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

Holy shit - I don't do any of that, in any model.
I run the onclick function of the thing you click on; that's it.
No traveling up the tree.
So can we stub out these functions for now, just to move along?
Or is that a bad idea?

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

> So can we stub out these functions for now, just to move along?

Yep, we can, it's just a seesaw like everything.   Maybe some things rely 
on it, and others don't.

I do have another piece of evidence that the Events code comes up in sites 
we want.  I revisited xqsuperschools.org, which is on the wish list.  The 
current first-occurring runtime error says:

application-e518b48189c89ff2924c9b37a81179824299937c79fecd4f8024 line 
10368: TypeError: undefined not callable (property 'createEvent' of 
[object Object])

And here is the code from around that line:

----
       CustomEvent = window.CustomEvent;

       if (typeof CustomEvent !== 'function') {
         CustomEvent = function(event, params) {
           var evt;
           evt = document.createEvent('CustomEvent'); // line 10368
           evt.initCustomEvent(event, params.bubbles, params.cancelable, 
params.detail);
           return evt;
         };
         CustomEvent.prototype = window.Event.prototype;
       }

       fire = Rails.fire = function(obj, name, data) {
         var event;
         event = new CustomEvent(name, {
           bubbles: true,
           cancelable: true,
           detail: data
         });
         obj.dispatchEvent(event);
         return !event.defaultPrevented;
       };
----

So bubbles comes up in use cases..  createEvent comes up, 
dispatchEvent comes up, etc.

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

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

I'm still in a bit of a quandary regarding an onclick function that doesn't complete because of an edbrowse error or shortcoming.
99% of the time you still want to go to the link, if you're a casual user, though there may be that 1% wherein you should have stopped.

1. return true and folllow the link. Developers like me can always set db3 and I'll see the error along the way.

2. Return false and don't follow the link. This would frustrate users as various links just wouldn't work, they would just sit there silently.

3. Some kind of debug toggle flag to do one or the other.

4. Return true and proceed unless debug is 3 or higher, whence we return false and stop, because after all we're trying to debug.
I kind of lean towards this one.

What do you think?

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

On Sun, 26 Nov 2017, Karl Dahlke wrote:

> I'm still in a bit of a quandary regarding an onclick function that doesn't complete because of an edbrowse error or shortcoming.

I guess it would be good to give it some kind of toggle.

If I am on a site where I can accidentally buy an elephant with my credit 
card, then I am worried about anything being permitted if the site is in a 
broken state, even where "broken state" is defined very conservatively, 
meaning one or more runtime errors whatsoever.

But the problem is that those types of web actions are mixed together with 
sites where the goal is to read plain text, or write plain text, or 
something with no danger, something low key, and in that case we can lean 
towards the permissive.

If you remember George something, the candy store that we didn't get 
working in time for Christmas gifts a couple years ago, I seem to remember 
there was something at the top that said this:

you are logged in
you are not logged in

Where, possibly, what's going on is that these these strings are both 
sitting in html, and the page JS is supposed to erase whichever one is NOT 
the case.  But say the page JS broke earlier along and never erased 
one.  This is bad.  It's a minefield.  Maybe we should be even more 
conservative than we are already, meaning that it might be good to fail 
all links or just refuse to load.

But if the user KNOWS that it is experimental and wants to do it 
anyway, they can set a certain flag.

We should just warn them, like requiring an opt-in. 
Because otherwise the gravity of the situation may not be clear.   It 
seems humorous.  "Logged in, not logged in.  How can I be both logged in 
and not logged in at the same time.  It must be some kind of glitch.  The 
site seems to work though..."   And if they then go on to do something 
successfully, I now have a quandary also because they have gotten some use 
out of it even though it is a problem to plop someone down in a 
semi-broken page where they are going to form impressions based on 
surface appearances.

[Edbrowse-dev] data-* attributes / new work on RC

[Karl Dahlke]

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

Remember that even if our js functions run to completion, they still might not be right.
I won't, out of fear / paranoia, cripple edbrowse so badly that it is useless.
That's what the disclaimers are for in README and in the documentation.
I will probably set it up so that the casual user, without setting flags or options, does as much as he can reasonably do,
and that will probably be my ongoing philosophy.

Karl Dahlke

Re: [Edbrowse-dev] data-* attributes / new work on RC

[Kevin Carhart]

> That's what the disclaimers are for in README and in the documentation.

Good point, and considering that's where I got the elephant in the 
first place, I will stop worrying.  :)

root@elsandbox:~/the_latest/edbrowse# grep elephant *
grep: build: Is a directory
grep: CMakeModules: Is a directory
grep: doc: Is a directory
grep: lang: Is a directory
grep: perl: Is a directory
README:causing you to buy a $37,000 elephant instead of
grep: src: Is a directory
grep: tools: Is a directory
grep: win32: Is a directory