From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.60; helo=out.smtp-auth.no-ip.com; envelope-from=kevin@carhart.net; receiver= Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 42E3A77D9F for ; Thu, 25 Jan 2018 21:50:55 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 1A74F501 for ; Thu, 25 Jan 2018 21:51:06 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id w0Q5p5jw031644 for ; Thu, 25 Jan 2018 21:51:05 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id w0Q5p4P8031641 for ; Thu, 25 Jan 2018 21:51:05 -0800 Date: Thu, 25 Jan 2018 21:51:04 -0800 (PST) From: Kevin Carhart To: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20180025235944.eklhad@comcast.net> Message-ID: References: <20180019150815.eklhad@comcast.net> <20180025235944.eklhad@comcast.net> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Edbrowse-dev] nasa / prepending "on" to events X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.25 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 05:50:55 -0000 You didn't make it up, I think it originated with me and I was wrong. I apologize for getting it wrong. It may have had to do with the fact that we didn't have things like showscripts, the ^> export, and demin yet. It has gotten a lot easier to isolate a situation in order to gather better evidence and do mini-experiments where you vary only one thing in order to nail down a cause. >>From MDN and other sources, I think the only two situations where "on" is present should be: - on inline handlers in html (not what we're dealing with in startwindow) - and in attachEvent, where the correct syntax is to pass in "onblah" I don't think we ever have to convert "blah" to "onblah". If "onblah" is passed in, the event to respond to is going to be "blah" If "blah" is passed in, the event to respond to is going to be "blah" One usage example is in the script vendor.js from nasa.gov, at 4883-4885 if you run demin: return n !== L && 9 === n.nodeType && n.documentElement ? (L = n, S = n.documentElement, r = n.defaultView, r && r !== r.top && (r.addEventListener ? r.addEventListener('unload', Ae, !1) : r.attachEvent && r.attachEvent('onunload', Ae)), x = !_(n), y.attributes = i(function (e) { attachEvent is being called with 'onunload' but I think the intention is that the future event to listen for to would be 'unload' addEventListener is being called with 'unload' and the event to listen for will be 'unload' I also have a few illustrative lines that are how I got on cloneNode and events in the first place over the past few days and also in December. It's 5739, 5740 and 5741 if you demin vendor.js. However, 5739 is still a chunk even after demin, because there is a long line with comma-separated items. But here is the relevant portion: t.attachEvent && (t.attachEvent('onclick', function () { re.noCloneEvent = !1; }), t.cloneNode(!0).click()), null == re.deleteExpando) { attachEvent is being called with 'onclick' to add a handler to t. And then immediately after this, it runs a line with multiple things daisy-chained: t.cloneNode(!0).click() So cloneNode runs and the result from this is an element, call it tcn. It lives in memory and hasn't been assigned. Then it runs [that result element].click() So assuming that this sample extrapolates to something more general, is this useful as a way of knowing the kind of phrasing we're supposed to be covering? My assumption is that if t.addEventHandler had been used instead of t.attachEvent, it would have said t.addEventHandler('click' ...... And the second line would have been the same, t.cloneNode(!0).click() Thank you Karl. The way to put a positive spin on this is that the new diagnostics makes it possible to write this email and be more specific.