* [Edbrowse-dev] Tidy error reporting
@ 2017-11-16 12:29 Karl Dahlke
2017-11-22 8:43 ` [Edbrowse-dev] data-* attributes Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-16 12:29 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes
2017-11-16 12:29 [Edbrowse-dev] Tidy error reporting Karl Dahlke
@ 2017-11-22 8:43 ` Kevin Carhart
2017-11-22 9:33 ` Kevin Carhart
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-22 8:43 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes
2017-11-22 8:43 ` [Edbrowse-dev] data-* attributes Kevin Carhart
@ 2017-11-22 9:33 ` Kevin Carhart
2017-11-22 15:48 ` Karl Dahlke
2017-11-24 21:19 ` Karl Dahlke
2 siblings, 0 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-22 9:33 UTC (permalink / raw)
To: Edbrowse-dev
>
> Here's the relevant function. It is document.scripts[2].data
Sorry, not document.scripts[2]. It is actually document.scripts[1]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes
2017-11-22 8:43 ` [Edbrowse-dev] data-* attributes Kevin Carhart
2017-11-22 9:33 ` Kevin Carhart
@ 2017-11-22 15:48 ` Karl Dahlke
2017-11-22 21:36 ` Kevin Carhart
2017-11-24 21:19 ` Karl Dahlke
2 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-22 15:48 UTC (permalink / raw)
To: Edbrowse-dev
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes
2017-11-22 15:48 ` Karl Dahlke
@ 2017-11-22 21:36 ` Kevin Carhart
2017-11-23 1:23 ` Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Kevin Carhart @ 2017-11-22 21:36 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes
2017-11-22 21:36 ` Kevin Carhart
@ 2017-11-23 1:23 ` Kevin Carhart
0 siblings, 0 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-23 1:23 UTC (permalink / raw)
To: Edbrowse-dev
>> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes
2017-11-22 8:43 ` [Edbrowse-dev] data-* attributes Kevin Carhart
2017-11-22 9:33 ` Kevin Carhart
2017-11-22 15:48 ` Karl Dahlke
@ 2017-11-24 21:19 ` Karl Dahlke
2017-11-25 0:20 ` [Edbrowse-dev] data-* attributes / new work on RC Kevin Carhart
2 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-24 21:19 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-24 21:19 ` Karl Dahlke
@ 2017-11-25 0:20 ` Kevin Carhart
2017-11-25 0:56 ` Karl Dahlke
0 siblings, 1 reply; 25+ messages in thread
From: Kevin Carhart @ 2017-11-25 0:20 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 0:20 ` [Edbrowse-dev] data-* attributes / new work on RC Kevin Carhart
@ 2017-11-25 0:56 ` Karl Dahlke
2017-11-25 1:15 ` Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-25 0:56 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 0:56 ` Karl Dahlke
@ 2017-11-25 1:15 ` Kevin Carhart
2017-11-25 1:22 ` Karl Dahlke
0 siblings, 1 reply; 25+ messages in thread
From: Kevin Carhart @ 2017-11-25 1:15 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 1:15 ` Kevin Carhart
@ 2017-11-25 1:22 ` Karl Dahlke
2017-11-25 1:44 ` Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-25 1:22 UTC (permalink / raw)
To: Edbrowse-dev
Ok. It's in.
Karl Dahlke
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 1:22 ` Karl Dahlke
@ 2017-11-25 1:44 ` Kevin Carhart
2017-11-25 2:28 ` Karl Dahlke
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-25 1:44 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 1:44 ` Kevin Carhart
@ 2017-11-25 2:28 ` Karl Dahlke
2017-11-25 3:10 ` Kevin Carhart
2017-11-26 13:14 ` Karl Dahlke
2017-11-26 22:43 ` Karl Dahlke
2 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-25 2:28 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 2:28 ` Karl Dahlke
@ 2017-11-25 3:10 ` Kevin Carhart
2017-11-25 5:02 ` Karl Dahlke
0 siblings, 1 reply; 25+ messages in thread
From: Kevin Carhart @ 2017-11-25 3:10 UTC (permalink / raw)
To: Edbrowse-dev
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 3:10 ` Kevin Carhart
@ 2017-11-25 5:02 ` Karl Dahlke
2017-11-25 5:35 ` Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-25 5:02 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 5:02 ` Karl Dahlke
@ 2017-11-25 5:35 ` Kevin Carhart
0 siblings, 0 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-25 5:35 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 1:44 ` Kevin Carhart
2017-11-25 2:28 ` Karl Dahlke
@ 2017-11-26 13:14 ` Karl Dahlke
2017-11-27 1:03 ` Kevin Carhart
2017-11-27 1:48 ` Kevin Carhart
2017-11-26 22:43 ` Karl Dahlke
2 siblings, 2 replies; 25+ messages in thread
From: Karl Dahlke @ 2017-11-26 13:14 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-25 1:44 ` Kevin Carhart
2017-11-25 2:28 ` Karl Dahlke
2017-11-26 13:14 ` Karl Dahlke
@ 2017-11-26 22:43 ` Karl Dahlke
2017-11-27 3:19 ` Kevin Carhart
2 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-26 22:43 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-26 13:14 ` Karl Dahlke
@ 2017-11-27 1:03 ` Kevin Carhart
2017-11-27 1:48 ` Kevin Carhart
1 sibling, 0 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-27 1:03 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-26 13:14 ` Karl Dahlke
2017-11-27 1:03 ` Kevin Carhart
@ 2017-11-27 1:48 ` Kevin Carhart
2017-11-27 2:58 ` Karl Dahlke
1 sibling, 1 reply; 25+ messages in thread
From: Kevin Carhart @ 2017-11-27 1:48 UTC (permalink / raw)
To: Edbrowse-dev
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-27 1:48 ` Kevin Carhart
@ 2017-11-27 2:58 ` Karl Dahlke
2017-11-27 3:37 ` Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-27 2:58 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-26 22:43 ` Karl Dahlke
@ 2017-11-27 3:19 ` Kevin Carhart
2017-11-27 4:23 ` Karl Dahlke
0 siblings, 1 reply; 25+ messages in thread
From: Kevin Carhart @ 2017-11-27 3:19 UTC (permalink / raw)
To: Edbrowse-dev
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-27 2:58 ` Karl Dahlke
@ 2017-11-27 3:37 ` Kevin Carhart
0 siblings, 0 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-27 3:37 UTC (permalink / raw)
To: Karl Dahlke; +Cc: Edbrowse-dev
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Edbrowse-dev] data-* attributes / new work on RC
2017-11-27 3:19 ` Kevin Carhart
@ 2017-11-27 4:23 ` Karl Dahlke
2017-11-27 4:51 ` Kevin Carhart
0 siblings, 1 reply; 25+ messages in thread
From: Karl Dahlke @ 2017-11-27 4:23 UTC (permalink / raw)
To: Edbrowse-dev
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Edbrowse-dev] data-* attributes / new work on RC
2017-11-27 4:23 ` Karl Dahlke
@ 2017-11-27 4:51 ` Kevin Carhart
0 siblings, 0 replies; 25+ messages in thread
From: Kevin Carhart @ 2017-11-27 4:51 UTC (permalink / raw)
To: Karl Dahlke; +Cc: Edbrowse-dev
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2017-11-27 4:49 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-16 12:29 [Edbrowse-dev] Tidy error reporting Karl Dahlke
2017-11-22 8:43 ` [Edbrowse-dev] data-* attributes Kevin Carhart
2017-11-22 9:33 ` Kevin Carhart
2017-11-22 15:48 ` Karl Dahlke
2017-11-22 21:36 ` Kevin Carhart
2017-11-23 1:23 ` Kevin Carhart
2017-11-24 21:19 ` Karl Dahlke
2017-11-25 0:20 ` [Edbrowse-dev] data-* attributes / new work on RC Kevin Carhart
2017-11-25 0:56 ` Karl Dahlke
2017-11-25 1:15 ` Kevin Carhart
2017-11-25 1:22 ` Karl Dahlke
2017-11-25 1:44 ` Kevin Carhart
2017-11-25 2:28 ` Karl Dahlke
2017-11-25 3:10 ` Kevin Carhart
2017-11-25 5:02 ` Karl Dahlke
2017-11-25 5:35 ` Kevin Carhart
2017-11-26 13:14 ` Karl Dahlke
2017-11-27 1:03 ` Kevin Carhart
2017-11-27 1:48 ` Kevin Carhart
2017-11-27 2:58 ` Karl Dahlke
2017-11-27 3:37 ` Kevin Carhart
2017-11-26 22:43 ` Karl Dahlke
2017-11-27 3:19 ` Kevin Carhart
2017-11-27 4:23 ` Karl Dahlke
2017-11-27 4:51 ` Kevin Carhart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).