Re: [Edbrowse-dev] Render

[Adam Thompson <arthompson1990@gmail.com>]

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

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

Yeah, I thought I was missing something.

> 
> > Primarily because I know of no way of protecting this js render function from
> > being zapped by an unfortunately crafted page.
> 
> 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_<whatever> for a function name.

I know that the 2nd one seems like a particularly unlikely issue to encounter
but one of the motivations behind the move to mozjs24 and the js improvements
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):
<script type="text/javascript">
function render()
{
var x = 0;
while (x < 10)
{
// complex code to do fancy things
x++;
// more complex code including something like
var para = document.getElementsByTagName("p")[x--];
var txt = document.createTextNode("This is test text");
para.appendChild(txt);
}
}
</script>
<form>
<input type="button" value="render javascript test text" onclick="render()" />

This render function has a relatively plausable bug (if you fill in the complex
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 
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 page.
> 
> 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 like 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 potentially.

> 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 infinite 
loops, or have generally broken (i.e.
firefox (I think) has a "A script on this page has stopped responding" error).
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?
> 
> https://developer.mozilla.org/en/docs/Traversing_an_HTML_table_with_JavaScript_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 menu.
> 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 stuff)
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 stuff.
That was last year.

In addition, it's certainly encouraged practice in web accessibility to provide
a largely js free version of the site to work in cases where js is unavailable
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 start requiring js
in order to parse and render.
[end opinionated speculation]
> So anyways all this dynamic creation, perhaps well after the page is parsed,
> 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 get a
JSON response instead), and all the dynamically created stuff from that executing.

> 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.
> 
> 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 structure
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 we'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 have,
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 list)
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.

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