From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 37DB479C69 for ; Tue, 27 Dec 2016 11:11:18 -0800 (PST) Received: by mail-lf0-x241.google.com with SMTP id x140so13950507lfa.2 for ; Tue, 27 Dec 2016 11:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Z1PQy0AFkU7ZsOeA2Y9xRTyyHK+eX0/r+z8FXaX676w=; b=HfUVfnCC2xnOKg6goQvDPqKqz8u7zJ+rh65YkEB4e3PMYAwSvEzBeSknvnNu3fZzNb hwZS9OT+MBGphApYHhrftwTj9jq0VR5vVmZr7yBW+t6Y74mEXJU+v06EcP8hv3BhWf/6 mW1jlukG6oSVrBfK4dbqAVFmRH9u+wrs+SdnMaoxaf8BXj/6FYI4VUtAJVFn4lemZfL7 WJdU9glEhDXJuJorbDqGJk3boB/b1S6Ek0Pn4GQORvNcXl+PHqkwOw5HpkdflMCl/IhT I8BYGZpFx8LKOpk3UEYcp/pmg4hT9ohJHzatCLDP/cJcKTbMVlcjoXYaG10tYZJ5TUeM CWvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Z1PQy0AFkU7ZsOeA2Y9xRTyyHK+eX0/r+z8FXaX676w=; b=Ykaa34XQISVg8dv+mgrUm9VkP7HX2hDaszsV5Ta5kMw7bKtSDeIcKb1xgizSG49SNK AHC3PSpSZHwSnL8eqpbwD/poU+9RUSBwzgUZ3WHmWgHayzuFavtnqGNeMQ8O0SP1mSM1 mCQfBggdkJyj5LVWsZh5LH2fRbepUWVU3FKvChpwEc4g1vhOwXvrm9JdwSZNEXEAnKA9 rQ64LLIoPmgLfSVbOumy+5Dlr69xjZ/FTwn/HrronXcpVSkMxN6Ofo7zIMHqSIhwcd1Y DLLEZKbWBOJidBu/gLBzY236Z+27Z3Wnp0JxtT3zJghgI/EoPnpzOJY22OMcpoQoLL4m llpg== X-Gm-Message-State: AIkVDXKwiSdCq+nTCzlX6bomm1CI7gpzzqzerDdQtVcyExJr0+rpTVkOZ81Ezyt7zW3AXg== X-Received: by 10.46.69.2 with SMTP id s2mr12998759lja.56.1482865900571; Tue, 27 Dec 2016 11:11:40 -0800 (PST) Received: from odin (odin.sdf-eu.org. [178.63.35.194]) by smtp.gmail.com with ESMTPSA id 26sm11384717lji.37.2016.12.27.11.11.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 11:11:39 -0800 (PST) Date: Tue, 27 Dec 2016 19:11:26 +0000 From: Adam Thompson To: Kevin Carhart Cc: Karl Dahlke , Edbrowse-dev@lists.the-brannons.com Message-ID: <20161227191126.GD8364@odin> References: <20161029110356.eklhad@comcast.net> <20161225130639.GB16190@odin> <20161126095227.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 19:11:18 -0000 --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 26, 2016 at 07:04:19PM -0800, Kevin Carhart wrote: > 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 wan= ts > and I think we are fairly far along. Good to know. Hopefully we can get some relatively quick wins here. > 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 - t= his > 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. Yeah... I sometimes work with devs who use jquery and it seems to do a bunc= h of things behind the scenes. > 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 th= is > in startwindow. It is not truly asynchronous, but there are a ton of pag= es > 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 AJ= AX, > but I think it occurs a lot. Agreed. This is an increasingly common design pattern. Incidentally, as far as I understand, js is a prototype object orientation system, i.e. you define objects based on other objects rather than classes. > 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 involv= ing > DOM, non jquery issue involving XHR) I think it is some of each of all fo= ur: >=20 > (1) jquery calls that want DOM calls. DOM calls not implemented. Note t= hat > 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. I guess we need to do placeholders for these. > (2) jquery wants get or post. Get/post wants our XMLHttpRequest. Somethi= ng > goes wrong along the way and the DOM tags to be retrieved inline do not m= ake > it back through all the hops from javascript back to edbrowse proper wher= e a > non-developer user could enjoy it. It's possible that the ajax works gre= at > 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= =2E 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 targ= et > iframe just changed its innerHTML. Now the edbrowse side-effects process > brings it back to edbrowse proper, and the edbrowse rendering of the targ= et > iframe suddenly has new information. The notification fires. There are a > lot of hops but potentially very groundbreaking, and we are partway there > already. Agreed. The only slight thing to notice here (and I've not checked our fetchHttp machinary yet) is that AJAX has slightly different behavior to br= owser HTTP requests as far as cookies go I think. There's also CORS (see one of my previous emails today). > (3) Some page that doesn't use jquery could use a piece of DOM manipulati= on, > also unrelated to ajax, that we haven't implemented yet. This is a third > option. Behavior fails. Yep, though hopefully this will be easier using startwindow. > (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. Or using some other framework which isn't jquery (i.e. not quite hand-roled= js). > I think there is a lot of fertile territory and I'm optimistic. How do y= ou > think we ought to work? It depends on time zones etc, but I've certainly got time this week. --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJYYrzdAAoJED6sZNk+oYF/AXkP/RLdvpkcMQ8vIAXisLch407Z 6SgFOBKJj37qGMa1vrGP2gv5J4R5oVDPf52wm5Qhu4DfesxJldzXPpvjTwYi2f/9 mc9NsYhmeZ5sSCKpA4Qf5IhygcvULmi6sBYGwEtvNnTZ6oUlfUAOozdqEVUuHI3U XgYXIb4kqlRuImXXD8T4dgTiiXJ0Gv2rPCOBjw8DxoU7RoD36CGNLtkawxUnhLgY L7vtlv7lRItSkZQqBFRkk28XVcw9jJxb2JUU0ZE/J+dWOhXXwzK462SgBszM9dmX Nj6djcTOjivwtdRftVBhSzd0T5Nhd6jGNhpIDVRsBRxYN3z2HcMAxx+Kma/kZBOH i14uQEIZlqRkywQTThgtHRVt1P7wM5jzF4bGU2mI6yYaZYYXA0UuFBuYc9ACOPvn Xtjx4U3HzLflJKZ7UBY6JzYWT7neSeAshxJa8Sjrdh42J3PMEKm3sRx4UBVEcI+w mu2QvyXXzJh3EQWHfaAYPhxNEvWF8TCIuk7xOa9kIX9Z7y0a9yHA5f/m5RCFs3qt iqmiKVftiri7m4qkG6mBPOLhbYfgKGJu54D2FKjdeafwrXeW1CUiQbijOOlcREPy +cbU4/3H5HiJEHwFSlbhKuqyozSJKFvXJ7JGpRpIb334H5wWjtM0wtRQYVe6isey TX8flUX6LMmjyRE1PiOW =0bxP -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb--