[Edbrowse-dev] $ object in javascript

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

If you're doing find&fix, it is perhaps more efficacious to track
through a page with 10 lines of js rather than 1000 lines of jquery.
This page http://www.radiocaroline.co.uk/top15_page.html
has just a few lines of script, but I don't understand them,
and if I don't understand then then you can be sure
edbrowse doesn't handle them properly.
There seems to be an inbuilt function or object $ which does some magic things,
which I haven't implemented at all.
Anybody know how this is suppose to work?

if(!$("#scheduled_top15s").find("table").length){
$.get("php/get_scheduled_top15s_public_2.php", function( data ) {
  $("#scheduled_top15s").html( data );
});
}

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> There seems to be an inbuilt function or object $ which does some magic things,
> which I haven't implemented at all.

$ is an alias for the jQuery function, the entrypoint into jQuery.
It's also an object and used like a namespace apparently.

-- Chris

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

Hi Karl and company,

$.get is a wrapper around an HTTP get.  So the page code loads a version 
of jquery, which includes a get method someplace within it.  When the page 
code calls this, it will want to work with XMLHttpRequest supplied by the 
DOM.  So it goes to our XMLHttpRequest code in startwindow, or should. 
>From there, it calls our native method for inline HTTP requests, in 
jseng-moz.cpp.  It can 
then fire the request, get some html, send it back to startwindow, and 
from startwindow send it back to the page's code.  When it says

function (data) { ...

, this is a handler that specifies what it will do with the HTML 
that is returned.  It could do particular DOM splices, put the response 
into a div, or stuff like that.  I am not sure if it is formally correct 
to call it a callback, but that's the idea.

So the pieces are there, but it has not been exercised 
that much.  When I was trying to get the drescher site working, it was a 
cycle like this and in some cases it worked.  So the good news is that 
the intentions of this snippet represent a common thing to want to do, so 
effort we put into it will pay off.

Here's a paraphrase of the entire snippet.  Yes, as Chris says, the $ is 
just an alias for the jQuery object.  It tests for the presence of a 
certain table which is subsidiary to the node scheduled_top15s.  If not 
found... if (not ( blah blah expression has length) ...

you go grab it inline, using GET, 
and once you have it, you follow the instructions in the handler, so in 
this case it populates the innerhtml of scheduled_top15s with the 
dynamically retrieved tags.  And our native C++ will handle 
this, which is very cool!

At this point, whatever code follows can rely on that thing existing 
because you either verified its presence or grabbed it using GET.


>
> if(!$("#scheduled_top15s").find("table").length){
> $.get("php/get_scheduled_top15s_public_2.php", function( data ) {
>  $("#scheduled_top15s").html( data );
> });
> }
>

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

I can understand most or all of Kevin's explanation,
but there is no other js code on the page,
no <script src=jquery.js> or any such thing,
so to my mind $ has never been set.
If I have debug 3 and go into jdb and type $ it says not defined.
Is $ suppose to be predefined in all browsers to have certain capabilities,
or is there a jquery page loaded somewhere somehow that I don't see?

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Tyler Spivey]

Firefox's web console says:
ReferenceError: $ is not defined[Learn More]
top15_page.html:66:4

This page is also missing its head/body sections, so maybe it's incomplete.
On 11/29/2016 11:30 PM, Karl Dahlke wrote:
> I can understand most or all of Kevin's explanation,
> but there is no other js code on the page,
> no <script src=jquery.js> or any such thing,
> so to my mind $ has never been set.
> If I have debug 3 and go into jdb and type $ it says not defined.
> Is $ suppose to be predefined in all browsers to have certain capabilities,
> or is there a jquery page loaded somewhere somehow that I don't see?
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

Ok - I stumbled on this page through a rather indirect route, google cache etc;
I don't think you're suppose to call this page directly.
It is perhaps a frame in a larger framework; that would explain everything.
This link calls that page and probably puts stuff around it,
like header, script includes, etc.
This is the actual link from the website.
I apologize if I sent everyone chasing a red herring.

http://www.radiocaroline.co.uk/?tracker=true#top15_page.html

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

> I apologize if I sent everyone chasing a red herring.

Any & all scenarios are a good thing as far as I am concerned.  When you 
come in by a direct route instead, does it work?  Does $ exist?

Kevin

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

> come in by a direct route instead does it work? Does $ exist?

No and yes.
Sure $ is there supporting jquery,
But the website doesn't work because jquery isn't fully implemented / operational.
This should probably be the highest priority for 3.6.3.
More than half the sites I run into use jquery.

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Wed, Nov 30, 2016 at 08:17:45PM -0500, Karl Dahlke wrote:
> > come in by a direct route instead does it work? Does $ exist?
> 
> No and yes.
> Sure $ is there supporting jquery,
> But the website doesn't work because jquery isn't fully implemented / operational.
> This should probably be the highest priority for 3.6.3.
> More than half the sites I run into use jquery.

Agreed, this'd be good to get for 3.6.3.  Anyone know how much more we need to
implement, and is there anything I can do to help with this
(I'm hoping to be able to put some more time into edbrowse development again).

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

> Anyone know how much more we need to implement,
> and is there anything I can do to help with this

Kevin has done most of jquery. He pokes around and finds things that I
have implemented improperly, or not at all,
and I fix it, and he finds the next thing, and on we go.
I'm not sure if we're 10% the way there or 90%, but perhaps you and he could coordinate.
He has been busy lately though, with personal matters, and also trying to oppose
the rise of fascism in our country, which is, we would all agree,
more important than working on edbrowse.
So I don't want to dissuade him from that.

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

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

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

> How do you think we ought to work?

Well you could just send email to me, and Chris, and anyone else interested,
that's mostly how we have trudged forward in the past.
Or there's a speakup IM channel that we chat on but we would all have to be awake and online at the same time.
Sometimes that has worked well for me and Chris, or me and Tyler, but that's just cause we don't sleep much, or regular, I guess.
So I don't know, whatever you like.

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

Hi Karl

Okay, sounds good.  Pretty much like we have done.  When I find out if 
Adam is around, I will offer to stay up so that we overlap.  I never go to 
bed before around 1 Pacific anyhow.

Do you remember at the beginning of the jquery development when we were 
working with a series of tests at the top of their "supports" function?
In writing out that long message, it makes me think that I wish there was 
something similar, a grand test suite for DOM implementations.  Maybe 
there is.  I have these two poles - I 
can go to W3 and read the spec but it's very detached from scenarios.  So 
then I can go 
work on find and fix, but this is just scenarios and doesn't let you know 
what's ahead or how close you are to finishing.  We need a series of 
anecdotal exercises designed by people, similar to our jsrt only published 
by the W3 consortium or something, so that you have a definitive way of 
knowing when you've passed your tests or which ones failed.  Maybe this 
exists.  I'm sure at Firefox and Chrome they run their browser through a 
suite like that.




  On Mon, 26 Dec 2016, Karl Dahlke wrote:

>> How do you think we ought to work?
>
> Well you could just send email to me, and Chris, and anyone else interested,
> that's mostly how we have trudged forward in the past.
> Or there's a speakup IM channel that we chat on but we would all have to be awake and online at the same time.
> Sometimes that has worked well for me and Chris, or me and Tyler, but that's just cause we don't sleep much, or regular, I guess.
> So I don't know, whatever you like.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

It would be difficult for you me Adam in realtime, as he is in England, thus a span of 8 timezones.
So maybe just email each other, or maybe stay on this list for any major design questions.
You and I can email directly if we're just fixing some bugs or tweaking code.

Don't know about existing jquery regression tests, or even dom regression tests,
but we may want to expand jsrt as we go.
Not sure if that means pulling jquery into jsrt.
I suppose if all the dom stuff worked perfectly then jquery would work as well.

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Chris Brannon]

Kevin Carhart <kevin@carhart.net> writes:

> In writing out that long message, it makes me think that I wish there
> was something similar, a grand test suite for DOM implementations.
> Maybe there is.

The Acid3 test is a web test page from the Web Standards Project that checks
a web browser's compliance with elements of various web standards,
particularly the Document Object Model (DOM) and JavaScript.

https://en.wikipedia.org/Acid3
http://acid3.acidtests.org

I think someone may have been trying to run edbrowse against this at one
time, and it's how we got support for data: URIs.

I'll be honest, I am starting to find this project very
overwhelming on an intellectual level.
I don't know how long I can keep up.
And the security implications of AJAX scare the crap out of me.
We're making web requests at the behest of code sent to us by total
strangers, using our credentials?
Sounds like a real Pandora's Box.
But I'll keep up as much as I can.

And what are the implications of doing that XHR stuff in startwindow.js,
rather than native C?  If you need it ported from JS to C, I can
certainly do that, as I have enough familiarity with both languages.

-- Chris

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

Hi Chris,

> I'll be honest, I am starting to find this project very
> overwhelming on an intellectual level.
> I don't know how long I can keep up.

My alarm bells go off.  You have a veto.  If you think it is like 
this, the drawbacks may outweigh the benefits or something is awry and it 
shouldn't be done this way.  Possibly it could be alleviated if we base 
our changes off of top-down tests like Acid3.  Thank you for the link to 
acid3.  Maybe I am adding unnecessary complication.

> And the security implications of AJAX scare the crap out of me.
> We're making web requests at the behest of code sent to us by total

I think there is a restriction, which may be a convention rather than 
something that is enforced by code, that AJAX cannot load from outside 
domains, but only from the domain of the original page.  I think you're 
right that another entry point from the internet is worrisome.  It is one 
more place where we talk to the curl library and something like malware 
could be retrieved.  Although, is this different than the security 
implications of the web request browsed with the 'b' command in the first 
place?

How do we know when we have done it securely?

> And what are the implications of doing that XHR stuff in startwindow.js,
> rather than native C?  If you need it ported from JS to C, I can
> certainly do that, as I have enough familiarity with both languages.

Thank you.  It is a mixture of both right now.  The reason that there is a 
javascript piece is that there was an existing 
JS implementation that I was able to modify.  This came from the Env JS 
project.  The JS piece mostly gathers parameters.  Then it calls the 
native code, fetchHTTP:

var entire_http_response = 
document.fetchHTTP(this.url,this.method,headerstring,data);

Kevin

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

> And the security implications of AJAX scare the crap out of me.

I don't think we need full ajax to manage jquery, and render 90% of the web pages.
Like we don't usually need the asynchronous stuff, as Kevin pointed out.
The web page might load a tad slower, but it still renders properly.

As for fear, well, if everybody is afraid, or unwilling, or unable, then I guess I give up too, on edbrowse, which is really my only standing accomplishment in life, and probably on everything else too.
Sure, don't bother with xhr requests, leave 90% of the web pages inaccessible, and I can use edbrowse to write letters like this one and that's about all.
Whatever. I'll unsubscribe from this list and call it a day.
I didn't make any real contributions in math either, or science,
nor are my adult children in any way functional, so whatever.

> And what are the implications of doing that XHR stuff in startwindow.js,
> rather than native C? If you need it ported from JS to C, I can
> certainly do that, as I have enough familiarity with both languages.

Well we've all been corresponding long enough to know my answer to that one;
do as much as you can in start js:
it's about a quarter of the code, more readable and maintainable, and portable across different js engines, or even different versions of mozilla.
But Adam's answer is different, do more in C, so I don't know, but I appreciate your offer.

Chris, would you rather I, or someone else, took over the official github hosting and edbrowse.org?
I primarily passed them to you because I'm older and will likely die sooner, but if you don't want them we could transition them back to me, and maybe another younger person will take them over within the next 20 years.
I don't know - I'm gonna look for some Christmas pie to eat. Maybe sugar will make me feel better.

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Chris Brannon]

Kevin Carhart <kevin@carhart.net> writes:

> Hi Chris,
>
>> I'll be honest, I am starting to find this project very
>> overwhelming on an intellectual level.
>> I don't know how long I can keep up.
>
> My alarm bells go off.  You have a veto.  If you think it is like
> this, the drawbacks may outweigh the benefits or something is awry and
> it shouldn't be done this way.

Oh not at all.  I'm not saying "don't move forward" or anything like that!
I mean I have a problem wrapping my head around all of the complexity
here.  That's a personal problem of mine, and I'll either get over it or
I won't.  But by all means let's keep moving forward!

> I think there is a restriction, which may be a convention rather than
> something that is enforced by code, that AJAX cannot load from outside
> domains, but only from the domain of the original page.

Yes, and we should probably make sure we honor that.

> Although, is this different than the
> security implications of the web request browsed with the 'b' command
> in the first place?

Maybe not much, except all of this stuff is possibly taking place in the
background, totally out of user control.

-- Chris

Re: [Edbrowse-dev] $ object in javascript

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> Well we've all been corresponding long enough to know my answer to that one;
> do as much as you can in start js:

Right.  It has so many benefits.  I wonder if there's any way of making
the code in startwindow tamper-proof, so that it cannot be replaced by
the outside world.  Also it would be nice if some methods and fields
could be only visible to code in startwindow, while not being visible to
the outside world.  I don't think we can do that, but I'm going to
research it.

> Chris, would you rather I, or someone else, took over the official github hosting and edbrowse.org?
> I primarily passed them to you because I'm older and will likely die
> sooner,

Well, I have no problem coordinating, hosting this list, etc etc.
As it stands, our source downloads are now all hosted on Github.  Github
will automatically generate an archive for each tagged release, so
there's no need to host them on edbrowse.org as well.
I do still have to manage the static binaries myself.  And the build
process is quite finnicky.  I'll keep doing that.  Don't panic, I'm not
going away.

-- Chris

Re: [Edbrowse-dev] $ object in javascript

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Mon, Dec 26, 2016 at 11:38:13PM -0500, Karl Dahlke wrote:
> It would be difficult for you me Adam in realtime, as he is in England, thus a span of 8 timezones.
> So maybe just email each other, or maybe stay on this list for any major design questions.
> You and I can email directly if we're just fixing some bugs or tweaking code.

I can be online fairly late this week (I don't go back to the day job until the
new year) but US time zones confuse me a bit so I'm not sure how the times work
out.  Realtime would be the best if we can but as I said time zones may be an
issue here.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Edbrowse-dev] $ object in javascript

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Tue, Dec 27, 2016 at 07:47:18AM -0800, Chris Brannon wrote:
> Karl Dahlke <eklhad@comcast.net> writes:
> 
> > Well we've all been corresponding long enough to know my answer to that one;
> > do as much as you can in start js:
> 
> Right.  It has so many benefits.  I wonder if there's any way of making
> the code in startwindow tamper-proof, so that it cannot be replaced by
> the outside world.  Also it would be nice if some methods and fields
> could be only visible to code in startwindow, while not being visible to
> the outside world.  I don't think we can do that, but I'm going to
> research it.

As far as I know we can't with smjs, which scares me a little given all
the AJAX machinary we're looking at.
However, if we can make our native http fetching machinary work correctly we
*may* be ok.  I think I'd rather the get and post bits were native so we can
make them read-only (I think) and make sure they can't be switched by outside
code.

> > Chris, would you rather I, or someone else, took over the official github hosting and edbrowse.org?
> > I primarily passed them to you because I'm older and will likely die
> > sooner,
> 
> Well, I have no problem coordinating, hosting this list, etc etc.
> As it stands, our source downloads are now all hosted on Github.  Github
> will automatically generate an archive for each tagged release, so
> there's no need to host them on edbrowse.org as well.
> I do still have to manage the static binaries myself.  And the build
> process is quite finnicky.  I'll keep doing that.  Don't panic, I'm not
> going away.

I'm also able to help if any is required.  Out of interest, and on a slightly
unrelated note, anyone know whos maintaining the netBSD package in pkgsrc?

Cheers,
Adam.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Edbrowse-dev] $ object in javascript

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 6159 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

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

Great - I am around also.  Maybe let's get calibrated and this will
supercede confusion over the time zones.  Right now it's 11:30 AM in
California.

When I sit down to try to do something, I generally resort to fixing
cases from the inside out.  Do you think it would be good to take a set of
tests like Acid3 and work off of that?  It seems like we need an
intermediate point which is both an implementation of the spec approach,
but also gives you a series of specific things to say "this passed," "this
failed."  Find-and-fix has problems because it's just one thing after 
the next, forever, with no way of knowing if you have ten or a hundred 
remaining.  Going to the W3 consortium and getting the spec document has 
problems because it is hard to know where to begin or how to translate 
what you're reading into an attainable task.

thanks
Kevin

[Edbrowse-dev] $ object in javascript

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Implementing the spec is valuable, or at the very least reading the spec,
so that the piece you decide to implement, you're implementing it right!
But I do believe, with the above caveat, that find&fix is the biggest bang for the buck, and we don't have a lot of resources here, so on we go.
(I sometimes wonder how many fulltime programmers maintain chrome or edge or whatever.)

I think we need to amass a list of sites that people want, that just don't work.
That's a market driven approach.
Kevin is already doing that; he has 2 or 3 that people have asked about,
that he is looking into.
My latest pet pieve is an entire domain, nasa.gov.
I'm a big space fan, and I love to read the articles,
but every page comes up blank, with or without js.
Didn't use to; the site use to be very accessible.
Not any more.
That's the problem with edbrowse, if you're not swimming forward you're falling behind.
I also can't listen to nasa tv with realplayer, though I could before.
That's another story.
Anyways, Kevin, you might add nasa.gov to the list of desirable and unworkable pages.

Karl Dahlke

Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart]

Hi Chris

> here.  That's a personal problem of mine, and I'll either get over it or
> I won't.  But by all means let's keep moving forward!

Good, well, I have contradictory reactions because I'm glad you are in 
favor of continuing to pursue the dynamic functionality but if the 
possibilities are that it's just over your head, or that some of that 
complexity is optional and reflects my writing style or my misconceptions, 
it is likely the second.

I don't have any objection to bringing more of XHR into compiled code.

Kevin

Re: [Edbrowse-dev] $ object in javascript

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Out of interest, and on a slightly
> unrelated note, anyone know whos maintaining the netBSD package in pkgsrc?

Yes.  Leonardo Taccari was packaging it for NetBSD as of early this
year.  Do you need an email address too?

-- Chris

[Edbrowse-dev] nextSibling and previousSibling

[Kevin Carhart]

Hi Karl

I remember you mentioning NASA, so I will try to solve it.

Hang on, here is a very concrete idea!  I know we need nextSibling and 
previousSibling.  Does anyone want to take them, and if not, I'm going to 
make an artificial deadline that I'm going to try to get nextSibling and 
previousSibling out by the end of Wednesday!  Then I will feel as though I 
haven't bunted.

We just have to grab bits like this.  I think 
implementing types of manipulations may be superior to starting with a 
site, because if you implement three manipulations, go back to the site 
and it magically works, you have fixed a root cause with broad 
implications and have not needed to care about a NASA developer's *own* 
middle layer of business logic and variables and style quirks, which 
takes time of its own and learning *that* stuff does not extrapolate at 
all.  So that would be my argument for favoring the spec down - it could 
save a lot of time.  Though just like I said above, I'm sure it's a back 
and forth, and you're trying to loosen up a logjam by two different 
means, poke over here with a case, prod over there with a DOM concept. 
Once it's done it's done.

Sibling code in the next 48 hours, or bust!

Kevin




On Tue, 27 Dec 2016, Karl Dahlke wrote:

> Implementing the spec is valuable, or at the very least reading the spec,
> so that the piece you decide to implement, you're implementing it right!
> But I do believe, with the above caveat, that find&fix is the biggest bang for the buck, and we don't have a lot of resources here, so on we go.
> (I sometimes wonder how many fulltime programmers maintain chrome or edge or whatever.)
>
> I think we need to amass a list of sites that people want, that just don't work.
> That's a market driven approach.
> Kevin is already doing that; he has 2 or 3 that people have asked about,
> that he is looking into.
> My latest pet pieve is an entire domain, nasa.gov.
> I'm a big space fan, and I love to read the articles,
> but every page comes up blank, with or without js.
> Didn't use to; the site use to be very accessible.
> Not any more.
> That's the problem with edbrowse, if you're not swimming forward you're falling behind.
> I also can't listen to nasa tv with realplayer, though I could before.
> That's another story.
> Anyways, Kevin, you might add nasa.gov to the list of desirable and unworkable pages.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

Re: [Edbrowse-dev] nextSibling and previousSibling

[Chris Brannon]

Kevin Carhart <kevin@carhart.net> writes:

> Hang on, here is a very concrete idea!  I know we need nextSibling and
> previousSibling.  Does anyone want to take them, and if not, I'm going
> to make an artificial deadline that I'm going to try to get
> nextSibling and previousSibling out by the end of Wednesday!

Ok that sounds good.  Here's my own artificial deadline.  I found the
spec for XmlHTTPRequest.  It's at https://xhr.spec.whatwg.org.  So over
the next two days I'll read, process, and hopefully internalize it,
since I think that's one of the places we're hoping to go.

-- Chris

Re: [Edbrowse-dev] $ object in javascript

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Tue, Dec 27, 2016 at 11:47:08AM -0800, Kevin Carhart wrote:
> >It depends on time zones etc, but I've certainly got time this week.
> 
> Great - I am around also.  Maybe let's get calibrated and this will
> supercede confusion over the time zones.  Right now it's 11:30 AM in
> California.

Ok, according to the date header that's -0800 offset so it's now  11:30 (approx)
in utc, which should make it 03:30 in the morning for you?

Hmmm, any idea what time/how you'd be online to work? Any preference as to IM
clients etc?

> When I sit down to try to do something, I generally resort to fixing
> cases from the inside out.  Do you think it would be good to take a set of
> tests like Acid3 and work off of that?  It seems like we need an
> intermediate point which is both an implementation of the spec approach,
> but also gives you a series of specific things to say "this passed," "this
> failed."  Find-and-fix has problems because it's just one thing after the
> next, forever, with no way of knowing if you have ten or a hundred
> remaining.  Going to the W3 consortium and getting the spec document has
> problems because it is hard to know where to begin or how to translate what
> you're reading into an attainable task.

Agreed, I like the set of tests method personally, particularly seeing as how
many devs seem to take a "I'll use it like this because it works" approach to the spec which means that one could only end up implementing a partial "fix"
and miss some important use-cases.

I'm going to take a look at acid3 I think and see what I can find.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[Edbrowse-dev] Edbrowse in NetBSD

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

Changed subject since this really is a separate thread now.
On Tue, Dec 27, 2016 at 12:23:16PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Out of interest, and on a slightly
> > unrelated note, anyone know whos maintaining the netBSD package in pkgsrc?
> 
> Yes.  Leonardo Taccari was packaging it for NetBSD as of early this
> year.  Do you need an email address too?

Yes, that'd be very helpful.
Basically the js side isn't working at all on netbsd x86_64 and we should get it
building 3.6.2 if it's not already.

Cheers,
Adam.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Edbrowse-dev] Edbrowse in NetBSD

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Yes, that'd be very helpful.
> Basically the js side isn't working at all on netbsd x86_64 and we should get it
> building 3.6.2 if it's not already.

Right.  You could try iamleot@gmail.com, assuming he's still working on
the package.  I don't know what the procedure is for reporting a stale /
buggy package in NetBSD.  Is it just "contact the maintainer"?

-- Chris

Re: [Edbrowse-dev] Edbrowse in NetBSD

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Wed, Dec 28, 2016 at 03:50:07AM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Yes, that'd be very helpful.
> > Basically the js side isn't working at all on netbsd x86_64 and we should get it
> > building 3.6.2 if it's not already.
> 
> Right.  You could try iamleot@gmail.com, assuming he's still working on
> the package.  I don't know what the procedure is for reporting a stale /
> buggy package in NetBSD.  Is it just "contact the maintainer"?

As far as I'm aware yes since the package is actually in the pkgsrc/wip (i.e.
work-in-progress) part of the tree.  This may well be an edbrowse issue though
since I tried a build myself and the js engine seg faulted.  I'm not sure
though, could be a library issue also.
I'll contact him (if he's not following this list?) and discuss further.  Thanks
for the contact details.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]