Re: [Edbrowse-dev] Render

[Adam Thompson <arthompson1990@gmail.com>]

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

On Wed, Mar 12, 2014 at 09:57:36AM -0700, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> >> > 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.
> 
> Can't we make the render function (or edbrowse_render) read-only?  I'm
> pretty sure we can.  But maybe this still wouldn't solve all the
> problems.

I'm not too sure we can. If so, any chance of linking to the docs as I've yet to find any which mention read-only functions.

> > I'd really like to know how browsers test when scripts have gone into infinite 
> > loops, or have generally broken
> 
> That's the halting problem, and it isn't computable.  There's no way to
> truely detect whether an arbitrary script has failed.  I suspect they
> just use a timeout, but I haven't looked at the source.

Yeah, I know about the halting problem,
which is why I was unsure how firefox etc kill supposedly broken scripts.
I think the time out is probably the approach used since I've seen on a couple
of occasions scripts which have triggered this when in reality they've just
been taking a *long* time to do anything.

> We should be able to call alarm before JS execution and let SIGALRM
> interrupt JS when the timeout is reached.  But I can't guarantee that
> Spidermonkey will not call sleep.  Mixing calls to alarm and sleep is a
> bad idea.

Yeah, but I'm unsure how else we can do this within a single thread.
I wonder if smjs has any hooks we can use for this kind of thing.
Incidentally, did you know that when one writes an infinite recursive function,
smjs seems to kill it at a certain limit without throwing an error,
at least not one which edbrowse displays?
The limit seems to be 60000 on my machine.

> > 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.
> 
> Yes, I'm pretty sure static html will always be with us, because a lot
> of written content is basically static.
> Also, lots of people are viewing the web with tablets and phones, and
> I've read that JavaScript sucks massively on mobile devices.

It's getting better with the advent of more powerful devices (my friends now
have ones which aren't a million miles away from being more powerful than my desktop!).

> Unfortunately, blogs created on Google's Blogger platform with the
> default template are unreadable without JavaScript.  You needed JS
> enabled to read content that is static.  They weren't readable with
> edbrowse, and last time I looked, they weren't even very nice to read in
> chrome with chromevox or firefox with a screen reader.  Deedra had one
> of these, and she couldn't easily read it in firefox.That was early last year.  Maybe Google has fixed their default template
> by now.

I'm not sure, I hope they fix it if they haven't already.
I remember getting emailed a link to one of these and wondering why it was
broken in edbrowse.
I thought this was a one-off but apparently not.

Cheers,
Adam.

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