* [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
* 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-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-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 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
* [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).