From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by hurricane.the-brannons.com (Postfix) with ESMTPS id AF51878638 for ; Sat, 1 Mar 2014 05:36:37 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id a1so1482087wgh.34 for ; Sat, 01 Mar 2014 05:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IMGiYCfK/OvDE40k4Vq8yUz4iSD+6cMWixOVBe1Pf6A=; b=qDjcKNoWJDKmJO6lXj7AbbOcaHTu60HLJlwExCrkT2glGU3GG/lIKoRMmGP1u+DWXJ Vc51YHuJdD1INJh5FZTxT2aCmtiVDz4KDyksFIC37EMgNsTyB/2DRHgbFIbsIwitFnu6 C9OFp4wRLtAGLhfCDLAcP1Yc7TM4bSIzsxFU0HG9CwpGI8GnJFLAiLLQlU+JlTjxWNvn sN2l0XTanwSwO/cLhCjqpq6y8gY2/2I7lZa6rulvHkXJttlhtKQ+mdkr6kand4Iq7LBE ca/NM+M6VH22/unkodi0+3iBmWC6WdAQyDm4/DasRvEPIYC4aaoyl4eUtCOSRMl4mn6C hXnw== X-Received: by 10.180.83.137 with SMTP id q9mr7577897wiy.55.1393680927494; Sat, 01 Mar 2014 05:35:27 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id ay8sm7837244wjb.13.2014.03.01.05.35.25 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 01 Mar 2014 05:35:26 -0800 (PST) Date: Sat, 1 Mar 2014 13:35:23 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140301133523.GH19851@toaster.adamthompson.me.uk> References: <20140128183238.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QnBU6tTI9sljzm9u" Content-Disposition: inline In-Reply-To: <20140128183238.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Render X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 13:36:38 -0000 --QnBU6tTI9sljzm9u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 28, 2014 at 06:32:38PM -0500, Karl Dahlke wrote: > > Also, how are you going to make this function called every time js does= anything? >=20 > Already done. > jSyncup is called before every js action, and jsdw is called afterword. > It's already bracketed. > And we have to do that anyways, to see what changes js made to our buffer > and report them back to the user. > These are things you just "see" in a regular browser. > "Oh - I clicked this button and now there's something new there." > We have to report it, and I made a first stab at it, > but we have to do better. > Like jsrt when you push the calc button it tells you that a line was upda= ted. Yeah, I thought I was missing something. >=20 > > Primarily because I know of no way of protecting this js render functio= n from > > being zapped by an unfortunately crafted page. >=20 > Like malice? That (which is probably unlikely), or a web developer choosing render as a perfectly reasonable name for some bit of shiny js. The same problem also exists with edbrowse_render, though much reduced, particularly if the popularity of edbrowse increases. This is because of the tendancy of developers to create browser-specific js, and if anyone did this for edbrowse (again unlikely but still) they may well use edbrowse_ for a function name. I know that the 2nd one seems like a particularly unlikely issue to encount= er but one of the motivations behind the move to mozjs24 and the js improvemen= ts in general is reliability and security and there's just so much damage one could do by overriding the render function, i.e. form submissions etc. Or (note, completely untested so excuse my rusty js syntax):
This render function has a relatively plausable bug (if you fill in the com= plex code sections with something) which creates an infinite loop. This wouldn't break anything as long as the user never clicked the "render javascript test text" button normally, however it's overridden the proposed render function and so gets called=20 automatically. > > At the moment if js does stupid things and breaks the js dom that's not= nice > > if it completely destroys our method for rendering the buffer that's > > not only difficult to debug but also means you end up with an empty pag= e. >=20 > Yes, a great point made in one sentence. > You couldn't turn js completely off, as you do today, > it would still have to be on long enough to build the objects from html l= ike today, > but not run any scripts, then traverse the objects to render the page, > which is a funny flavor of off, not entirely off. > And if js was off because some other session hogged all the js memory, > well then we're up the creek eh? > Really annoying that the js pool is a fixed size. Yes and no. It's a hard limit on js memory usage which, given some of the = buggy js out there, is a good thing. It's just unfortunate in our case pot= entially. > So yes there's more to think about here. > Damn, I really liked the idea too! So did I until I looked into it. I even went as far as exploring pure js DOM implementations like env.js (apparently spidermonkey versions exist) whilst thinking through all the implications. Whilst we're on the subject of js reliability, I'd really like to know how browsers test when scripts have gone into infin= ite=20 loops, or have generally broken (i.e. firefox (I think) has a "A script on this page has stopped responding" erro= r). This'd be another nice addition to edbrowse. > Well we have time to mull it over and talk it out. Agreed. > I found this in a tutorial long ago and bookmarked it. > It's the kind of thing we should support. > See how tables and cells and paragraphs and just about anything > on the web page can be built by javascript, not just by html tags? >=20 > https://developer.mozilla.org/en/docs/Traversing_an_HTML_table_with_JavaS= cript_and_DOM_Interfaces > Most web pages aren't that crazy but some are, and more and more web pages > at least build little partswith js, > like building the secondary menu based on your selection in a primary men= u. > That happens all the time. Yeah. I've just read a bit of this tutorial. I knew you *could* do that with js but I'd never actually seen the code to do it before. > I wrote such a website for my work; I wrote a website > I couldn't even use with edbrowse. Ironic. Yeah, just a bit. > Anyways, I wonder, how long can we say > "Gee we need to render html even if js won't run", > will the day come when there just aren't many web pages left > that have any meaning without js? > Not trying to cause trouble, just wondering. [begin opinionated speculation] No, static html will always exist, and I can point to many sites where the = js merely serves to run google analytics etc, and which won't be changing any time soon. Indeed, I talked to someone who develops software (web-based and backend st= uff) and he was saying about a project he was involved in to create a js-free version of a highly js-intensive site. He found it quite interesting that, with careful design, he was able to achieve a nice user experience without all the shiny js stuf= f. That was last year. In addition, it's certainly encouraged practice in web accessibility to pro= vide a largely js free version of the site to work in cases where js is unavaila= ble or the js-driven interface is not accessible to screenreader users. Unfortunately with the current drive for ever more js and shiny, such practises have been forgotten in some cases, however I've seen definite improvements in some sites (which were more than negated by the updates made to others). The basic point I'm trying to make here is that I think it'll continue to be important to render pages without js as long as the html standard doesn't s= tart requiring js in order to parse and render. [end opinionated speculation] > So anyways all this dynamic creation, perhaps well after the page is pars= ed, > perhaps because you pushed a button, > all this dynamism we must support. Agreed, and then there's AJAX (or whatever it's called when you actually ge= t a JSON response instead), and all the dynamically created stuff from that exe= cuting. > html tags become js objects. > js scripts make more objects or change these objects. > js objects become things on the screen, or in our case the text buffer. >=20 > User pushes a button. > js function makes new objects or changes the objects. > js tree of objects implies a new buffer. > compare with the old buffer and report any differences. > Wait for next user input or action. Yeah. I think in order to get this to work in a nice way we really need to rethink how we create our DOM, i.e. I think we probably need to change the = tag array to a tag tree then work from there. That'll allow us to write element creation as a tag creation function and appendchild (not sure of case) as a tree insertion. When we parse tags we re-use the C versions of these tag creation and tree insertion functions, and provide js wrappers for them. There are other ways I'm contemplating for handling tag properties (like a string to something hash map) which would allow JS wrappers to become more generic (I think). I *definitely* don't want to create a ridiculously abstract way of creating= a DOM with classes, derived classes etc to create tag objects, far from it! I'm just trying to come up with an extension to the existing html tag struc= ture which would allow it to work as a tree and store tag properties. Once we have this, I think the JS stuff will probably get much simpler as w= e'll just be creating wrappers rather than dealing with js GC weirdness, i.e. getElementByTagName only has to create the (rooted?) js objects when called, other than that the DOM stays away from the GC. These objects would only need to concist of small wrapper functions which plugged into the existing DOM, rather than copying text etc. I think this is probably not a million miles away from what we currently ha= ve, with the exception of a tree structure and generic property handling. Also, thinking in terms of optimisation, if a child of a tag is changed, a flag could be set in its parent (or a pointer to the parent added to a li= st) meaning rendering need only start from that child, rather than re-rendering the entire tree possibly. I'm not sure how plausable this sounds, but I think this is where we need to head for. Cheers, Adam. --QnBU6tTI9sljzm9u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTEeIbAAoJELZ22lNQBzHOjwQIAKF3tHDhMkh0FfutbhM3SFK1 B2JluVdCdxjX/4CqhtrqgnbqHgvtWCdZwb/zHOr94eNrLdBupgOQlqIE2DC3+SrK ejwKF6ZRNcJv6gFco11A6MGhv+E2dgZ40UC1iNnw7Mja9hkJO51QGgrcuc/UtzSA ZIXa7hFiifk1CFP1j4biuqzkxD5H3lJ98V2YYDlb6ZYQK1qGYa3DZuoD6l4BvLix lgSB6INYTdENHsjUqE5h1W5TJDz1qkWUZyd7HIvJYz90HLqkPsp0Q61drScvG5NW AxmGiASbEC4C8JIXwfZSCnrrHB0/jANDk4HRECSgL46Ar+5q3pUIyziB05dIkk0= =1/2e -----END PGP SIGNATURE----- --QnBU6tTI9sljzm9u--