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 wants
> 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 - 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.

Yeah... I sometimes work with devs who use jquery and it seems to do a bunch 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 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.

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 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.

I guess we need to do placeholders for these.

> (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.

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 browser
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 manipulation,
> 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 you
> think we ought to work?

It depends on time zones etc, but I've certainly got time this week.