* [Edbrowse-dev] $ object in javascript @ 2016-11-29 16:03 Karl Dahlke 2016-11-29 16:24 ` Chris Brannon 2016-11-30 0:47 ` Kevin Carhart 0 siblings, 2 replies; 32+ messages in thread From: Karl Dahlke @ 2016-11-29 16:03 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-11-29 16:03 [Edbrowse-dev] $ object in javascript Karl Dahlke @ 2016-11-29 16:24 ` Chris Brannon 2016-11-30 0:47 ` Kevin Carhart 1 sibling, 0 replies; 32+ messages in thread From: Chris Brannon @ 2016-11-29 16:24 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-11-29 16:03 [Edbrowse-dev] $ object in javascript Karl Dahlke 2016-11-29 16:24 ` Chris Brannon @ 2016-11-30 0:47 ` Kevin Carhart 2016-11-30 7:30 ` Karl Dahlke 1 sibling, 1 reply; 32+ messages in thread From: Kevin Carhart @ 2016-11-30 0:47 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev 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 ); > }); > } > ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-11-30 0:47 ` Kevin Carhart @ 2016-11-30 7:30 ` Karl Dahlke 2016-11-30 7:43 ` Tyler Spivey 0 siblings, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-11-30 7:30 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-11-30 7:30 ` Karl Dahlke @ 2016-11-30 7:43 ` Tyler Spivey 2016-11-30 7:54 ` Karl Dahlke 0 siblings, 1 reply; 32+ messages in thread From: Tyler Spivey @ 2016-11-30 7:43 UTC (permalink / raw) To: Edbrowse-dev 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 > ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-11-30 7:43 ` Tyler Spivey @ 2016-11-30 7:54 ` Karl Dahlke 2016-12-01 0:04 ` Kevin Carhart 0 siblings, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-11-30 7:54 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-11-30 7:54 ` Karl Dahlke @ 2016-12-01 0:04 ` Kevin Carhart 2016-12-01 1:17 ` Karl Dahlke 0 siblings, 1 reply; 32+ messages in thread From: Kevin Carhart @ 2016-12-01 0:04 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-12-01 0:04 ` Kevin Carhart @ 2016-12-01 1:17 ` Karl Dahlke 2016-12-25 13:06 ` Adam Thompson 0 siblings, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-12-01 1:17 UTC (permalink / raw) To: Edbrowse-dev > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-01 1:17 ` Karl Dahlke @ 2016-12-25 13:06 ` Adam Thompson 2016-12-26 14:52 ` Karl Dahlke 0 siblings, 1 reply; 32+ messages in thread From: Adam Thompson @ 2016-12-25 13:06 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-12-25 13:06 ` Adam Thompson @ 2016-12-26 14:52 ` Karl Dahlke 2016-12-27 3:04 ` Kevin Carhart 0 siblings, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-12-26 14:52 UTC (permalink / raw) To: Edbrowse-dev > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-26 14:52 ` Karl Dahlke @ 2016-12-27 3:04 ` Kevin Carhart 2016-12-27 3:49 ` Karl Dahlke 2016-12-27 19:11 ` [Edbrowse-dev] $ object in javascript Adam Thompson 0 siblings, 2 replies; 32+ messages in thread From: Kevin Carhart @ 2016-12-27 3:04 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-12-27 3:04 ` Kevin Carhart @ 2016-12-27 3:49 ` Karl Dahlke 2016-12-27 4:17 ` Kevin Carhart 2016-12-27 19:11 ` [Edbrowse-dev] $ object in javascript Adam Thompson 1 sibling, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-12-27 3:49 UTC (permalink / raw) To: Edbrowse-dev [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 3:49 ` Karl Dahlke @ 2016-12-27 4:17 ` Kevin Carhart 2016-12-27 4:38 ` Karl Dahlke 2016-12-27 4:59 ` Chris Brannon 0 siblings, 2 replies; 32+ messages in thread From: Kevin Carhart @ 2016-12-27 4:17 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-12-27 4:17 ` Kevin Carhart @ 2016-12-27 4:38 ` Karl Dahlke 2016-12-27 18:37 ` Adam Thompson 2016-12-27 4:59 ` Chris Brannon 1 sibling, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-12-27 4:38 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 4:38 ` Karl Dahlke @ 2016-12-27 18:37 ` Adam Thompson 0 siblings, 0 replies; 32+ messages in thread From: Adam Thompson @ 2016-12-27 18:37 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 4:17 ` Kevin Carhart 2016-12-27 4:38 ` Karl Dahlke @ 2016-12-27 4:59 ` Chris Brannon 2016-12-27 6:53 ` Kevin Carhart 2016-12-27 13:26 ` Karl Dahlke 1 sibling, 2 replies; 32+ messages in thread From: Chris Brannon @ 2016-12-27 4:59 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 4:59 ` Chris Brannon @ 2016-12-27 6:53 ` Kevin Carhart 2016-12-27 15:21 ` Chris Brannon 2016-12-27 13:26 ` Karl Dahlke 1 sibling, 1 reply; 32+ messages in thread From: Kevin Carhart @ 2016-12-27 6:53 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 6:53 ` Kevin Carhart @ 2016-12-27 15:21 ` Chris Brannon 2016-12-27 20:13 ` Kevin Carhart 0 siblings, 1 reply; 32+ messages in thread From: Chris Brannon @ 2016-12-27 15:21 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 15:21 ` Chris Brannon @ 2016-12-27 20:13 ` Kevin Carhart 0 siblings, 0 replies; 32+ messages in thread From: Kevin Carhart @ 2016-12-27 20:13 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-12-27 4:59 ` Chris Brannon 2016-12-27 6:53 ` Kevin Carhart @ 2016-12-27 13:26 ` Karl Dahlke 2016-12-27 15:47 ` Chris Brannon 1 sibling, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-12-27 13:26 UTC (permalink / raw) To: Edbrowse-dev [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 13:26 ` Karl Dahlke @ 2016-12-27 15:47 ` Chris Brannon 2016-12-27 18:48 ` Adam Thompson 0 siblings, 1 reply; 32+ messages in thread From: Chris Brannon @ 2016-12-27 15:47 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 15:47 ` Chris Brannon @ 2016-12-27 18:48 ` Adam Thompson 2016-12-27 20:23 ` Chris Brannon 0 siblings, 1 reply; 32+ messages in thread From: Adam Thompson @ 2016-12-27 18:48 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 18:48 ` Adam Thompson @ 2016-12-27 20:23 ` Chris Brannon 2016-12-28 11:42 ` [Edbrowse-dev] Edbrowse in NetBSD Adam Thompson 0 siblings, 1 reply; 32+ messages in thread From: Chris Brannon @ 2016-12-27 20:23 UTC (permalink / raw) To: Adam Thompson; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] Edbrowse in NetBSD 2016-12-27 20:23 ` Chris Brannon @ 2016-12-28 11:42 ` Adam Thompson 2016-12-28 11:50 ` Chris Brannon 0 siblings, 1 reply; 32+ messages in thread From: Adam Thompson @ 2016-12-28 11:42 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] Edbrowse in NetBSD 2016-12-28 11:42 ` [Edbrowse-dev] Edbrowse in NetBSD Adam Thompson @ 2016-12-28 11:50 ` Chris Brannon 2016-12-28 12:15 ` Adam Thompson 0 siblings, 1 reply; 32+ messages in thread From: Chris Brannon @ 2016-12-28 11:50 UTC (permalink / raw) To: Adam Thompson; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] Edbrowse in NetBSD 2016-12-28 11:50 ` Chris Brannon @ 2016-12-28 12:15 ` Adam Thompson 0 siblings, 0 replies; 32+ messages in thread From: Adam Thompson @ 2016-12-28 12:15 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 3:04 ` Kevin Carhart 2016-12-27 3:49 ` Karl Dahlke @ 2016-12-27 19:11 ` Adam Thompson 2016-12-27 19:47 ` Kevin Carhart 1 sibling, 1 reply; 32+ messages in thread From: Adam Thompson @ 2016-12-27 19:11 UTC (permalink / raw) To: Kevin Carhart; +Cc: Karl Dahlke, Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 19:11 ` [Edbrowse-dev] $ object in javascript Adam Thompson @ 2016-12-27 19:47 ` Kevin Carhart 2016-12-27 20:11 ` Karl Dahlke 2016-12-28 11:38 ` [Edbrowse-dev] $ object in javascript Adam Thompson 0 siblings, 2 replies; 32+ messages in thread From: Kevin Carhart @ 2016-12-27 19:47 UTC (permalink / raw) To: Adam Thompson; +Cc: Karl Dahlke, Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] $ object in javascript 2016-12-27 19:47 ` Kevin Carhart @ 2016-12-27 20:11 ` Karl Dahlke 2016-12-27 20:45 ` [Edbrowse-dev] nextSibling and previousSibling Kevin Carhart 2016-12-28 11:38 ` [Edbrowse-dev] $ object in javascript Adam Thompson 1 sibling, 1 reply; 32+ messages in thread From: Karl Dahlke @ 2016-12-27 20:11 UTC (permalink / raw) To: Edbrowse-dev [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Edbrowse-dev] nextSibling and previousSibling 2016-12-27 20:11 ` Karl Dahlke @ 2016-12-27 20:45 ` Kevin Carhart 2016-12-27 21:14 ` Chris Brannon 0 siblings, 1 reply; 32+ messages in thread From: Kevin Carhart @ 2016-12-27 20:45 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] nextSibling and previousSibling 2016-12-27 20:45 ` [Edbrowse-dev] nextSibling and previousSibling Kevin Carhart @ 2016-12-27 21:14 ` Chris Brannon 0 siblings, 0 replies; 32+ messages in thread From: Chris Brannon @ 2016-12-27 21:14 UTC (permalink / raw) To: Kevin Carhart; +Cc: Karl Dahlke, Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Edbrowse-dev] $ object in javascript 2016-12-27 19:47 ` Kevin Carhart 2016-12-27 20:11 ` Karl Dahlke @ 2016-12-28 11:38 ` Adam Thompson 1 sibling, 0 replies; 32+ messages in thread From: Adam Thompson @ 2016-12-28 11:38 UTC (permalink / raw) To: Kevin Carhart; +Cc: Karl Dahlke, Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2016-12-28 12:15 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-29 16:03 [Edbrowse-dev] $ object in javascript Karl Dahlke 2016-11-29 16:24 ` Chris Brannon 2016-11-30 0:47 ` Kevin Carhart 2016-11-30 7:30 ` Karl Dahlke 2016-11-30 7:43 ` Tyler Spivey 2016-11-30 7:54 ` Karl Dahlke 2016-12-01 0:04 ` Kevin Carhart 2016-12-01 1:17 ` Karl Dahlke 2016-12-25 13:06 ` Adam Thompson 2016-12-26 14:52 ` Karl Dahlke 2016-12-27 3:04 ` Kevin Carhart 2016-12-27 3:49 ` Karl Dahlke 2016-12-27 4:17 ` Kevin Carhart 2016-12-27 4:38 ` Karl Dahlke 2016-12-27 18:37 ` Adam Thompson 2016-12-27 4:59 ` Chris Brannon 2016-12-27 6:53 ` Kevin Carhart 2016-12-27 15:21 ` Chris Brannon 2016-12-27 20:13 ` Kevin Carhart 2016-12-27 13:26 ` Karl Dahlke 2016-12-27 15:47 ` Chris Brannon 2016-12-27 18:48 ` Adam Thompson 2016-12-27 20:23 ` Chris Brannon 2016-12-28 11:42 ` [Edbrowse-dev] Edbrowse in NetBSD Adam Thompson 2016-12-28 11:50 ` Chris Brannon 2016-12-28 12:15 ` Adam Thompson 2016-12-27 19:11 ` [Edbrowse-dev] $ object in javascript Adam Thompson 2016-12-27 19:47 ` Kevin Carhart 2016-12-27 20:11 ` Karl Dahlke 2016-12-27 20:45 ` [Edbrowse-dev] nextSibling and previousSibling Kevin Carhart 2016-12-27 21:14 ` Chris Brannon 2016-12-28 11:38 ` [Edbrowse-dev] $ object in javascript Adam Thompson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).