From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out.smtp-auth.no-ip.com (out.smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 5729279C69 for ; Mon, 26 Dec 2016 19:03:58 -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 DCA2B6F6; Mon, 26 Dec 2016 19:04:20 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id uBR34JQJ005323; Mon, 26 Dec 2016 19:04:19 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id uBR34J8n005317; Mon, 26 Dec 2016 19:04:19 -0800 Date: Mon, 26 Dec 2016 19:04:19 -0800 (PST) From: Kevin Carhart To: Karl Dahlke cc: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20161126095227.eklhad@comcast.net> Message-ID: References: <20161029110356.eklhad@comcast.net> <20161225130639.GB16190@odin> <20161126095227.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] $ object in javascript X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.23 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 03:03:58 -0000 Hi all I have time to work on it this week. I'd love to have one or more threads onlist or offlist or even hop on an IM client, to figure it out. Any working-method is ok with me. What I have usually observed is that jquery is a wrapper around various integral DOM manipulations which would live either in startwindow or jseng-moz.cpp. A lot of these, we have. Maybe some others, we don't have. Any missing method makes behaviors fail. Jquery code is fairly readable when you are in a version that is not minified. You will have various methods defined in a jquery.js file, so you're sitting there reviewing the JS code, and the $ object has various calls available with fancy seeming names invented by the jquery authors, but the code that constitutes that call simply wants to do open DOM things: insertBefore, appendChild, the usual. I think we have most of what it wants and I think we are fairly far along. A related question is AJAX. jquery and AJAX are two different things, but jquery has the keywords 'get' and 'post'. jquery provides developers with the ability to retrieve things inline with minimal work for them. Ha - this just means that the burden has been moved around to us, the people responsible for the browser's XMLHttpRequest. So this is a second kind of thing. Some of the failed sites we are seeing relate to pages that want to call $.get or $.post. This happened in the radio caroline page. The $ object has a set of functions (call them functions, methods, calls.. it may not be appropriate to use OO terminology for javascript, but since what I've been exposed to is a mess of both, I sometimes say 'methods' - sorry about this!), and this set of functions includes get and post. The JS code that constitutes $.get and $.post, itself wants to take advantage of an XMLHttpRequest implementation which the browser is responsible for. We have code for this in startwindow. It is not truly asynchronous, but there are a ton of pages which are using an inline HTTP request but don't take advantage of asynchronous timing. Their pages don't require it- they might just have something like a list of days, or an enumeration of items that the web visitor can click on, and for each one that you click on, it plops the results into one iframe. So it's a little bit of an extraneous use of AJAX, but I think it occurs a lot. So at the risk of being a little repetitive, I'll lay this out again: what kind of problem are we facing when site behaviors don't work? Of four possibilties (jquery wants DOM, jquery wants XHR, non jquery issue involving DOM, non jquery issue involving XHR) I think it is some of each of all four: (1) jquery calls that want DOM calls. DOM calls not implemented. Note that this could include all kinds of CSS! I have worked on things like "getComputedStyle". It expects style stuff to be available and this could be a blocker. A missing method is a missing method, even when edbrowse is ultimately going to not care and throw it out. (2) jquery wants get or post. Get/post wants our XMLHttpRequest. Something goes wrong along the way and the DOM tags to be retrieved inline do not make it back through all the hops from javascript back to edbrowse proper where a non-developer user could enjoy it. It's possible that the ajax works great and the resulting DOM changes actually do happen but don't make it out of javascript. The chokepoint could be early or late, but a chokepoint anywhere would mean that edbrowse users wouldn't get the benefit YET. Some kinds of chokepoints might be easy for us to fix and some might be difficult, and it might be hard to differentiate the cause of the problem. I think we can do it though - the good news is that this has actually succeeded sometimes! Something magically changes in place, in edbrowse. Maybe you are clicking on different days in the pirate radio schedule, and the 'results' iframe is properly receiving a new piece of text. (And that is when we would present the user with a notification that something changed on certain line numbers.) It's not out of reach that we could get this going. It just means that several gears need to work together and none can fail: edbrowse, to third party page code, to page code's jquery code, to page code's jquery's GET/POST, to startwindow's XHR, to our native XHR in jseng-moz, leap off to the internet via curl, to native XHR, back to startwindow XHR, back to page code's jquery, back to page code. The page code now has some tags and some instructions. The instructions run on the tags, and the tree changes, as represented in javascript. Perhaps a target iframe just changed its innerHTML. Now the edbrowse side-effects process brings it back to edbrowse proper, and the edbrowse rendering of the target iframe suddenly has new information. The notification fires. There are a lot of hops but potentially very groundbreaking, and we are partway there already. (3) Some page that doesn't use jquery could use a piece of DOM manipulation, also unrelated to ajax, that we haven't implemented yet. This is a third option. Behavior fails. (4) Some page that doesn't use jquery could instantiate XMLHttpRequest directly in a handmade JS function. Something goes wrong along the way maybe, and behavior fails. I think there is a lot of fertile territory and I'm optimistic. How do you think we ought to work? Kevin