[Edbrowse-dev] thoughts on frames

[Edbrowse-dev] thoughts on frames

[Karl Dahlke]

This is way to long for the irc.

I am both optimistic and pessimistic about frames.

Version 1 allows you to expand a frame inline, instead of the g command that expands it in a new buffer.
It works, pretty much. Browse jsrt and look at line 4.
Expand it with the exp command.
(Contract not yet implemented.)
So far so good.

Still problems though, a frame in space.com causes a seg fault when I expand it.
So still bugs to fix.

When finished, version 1 will allow expand and contract of frames inside a window, which is neat,
and worth doing I suppose, but it will not make a single website accessible to us that is not already accessible.
No progress there.

Version 2 might let the js worlds interact.
The window can see the js objects in the frames etc.
I have no clue, no flippin clue, how to do that.
I'm sure it's a lota lota work, and I believe it would gain us almost nothing.
One more acid3 test would pass, but I think very few websites do that, or need that functionality.
Frames tend to be independent ads, or videos, and that's it.
Rather, the vast majority of inaccessible websites will be brought into the fold by Kevin's find&fix work.
That's where the real world problems are.
That's where the rubber meets the road.
That's what I believe anyways.
So I will get frames version 1 working, but not sure if or when I will get round to frames version 2.
I don't think it's a lot of bang for the buck.
As always, I welcome opposing points of view.

Karl Dahlke

Re: [Edbrowse-dev] thoughts on frames

[Kevin Carhart]

Hi Karl

One observation I have is that I think find & fix and the spec-based 
approach have converged.  The javascript in the acidtests.org page is a 
long series of scenarios to work on and fix.  And this is a good thing, I 
think, because (a) you know that there will be bang for the buck in the 
time you spend on something, since they have hand-designed the scenarios 
based on what they exemplify.  And (b) the writing style of this code is 
very human.  It's indented, it's commented, the variable naming has a 
cleanness to it and doesn't have variables like 'a', 'b', 'c'.  So I think 
acid3 and find&fix are basically the same thing, even if the scenarios we 
wanted to investigate are not the ones about frames.

On frames in particular, if there's an impasse, there's an impasse.. if 
you don't know how to write it, I seriously doubt that I do.

But, do you think there is any subset of these situations which might only 
live on the JS side and then be discarded?  For instance, suppose a frame 
is used as temporary storage, or in order to do a Towers of Hammurabi 
manuever and put your interconnected nodes down in a frame, to rearrange 
them and put them back in the main document.

Is this worth pursuing?  I can't quite tell what the example in acid3 is 
trying to exemplify, but I think 'doc', the side document that is defined 
as

var doc = iframe.contentDocument;

is only intratest.  It produces a pass/fail result and so doc doesn't have 
to create side effects.  Maybe later in another scenario it does, but we 
can try to deal with this test and then take it from there.

Kevin




On Mon, 27 Feb 2017, Karl Dahlke wrote:

> This is way to long for the irc.
>
> I am both optimistic and pessimistic about frames.
>
> Version 1 allows you to expand a frame inline, instead of the g command that expands it in a new buffer.
> It works, pretty much. Browse jsrt and look at line 4.
> Expand it with the exp command.
> (Contract not yet implemented.)
> So far so good.
>
> Still problems though, a frame in space.com causes a seg fault when I expand it.
> So still bugs to fix.
>
> When finished, version 1 will allow expand and contract of frames inside a window, which is neat,
> and worth doing I suppose, but it will not make a single website accessible to us that is not already accessible.
> No progress there.
>
> Version 2 might let the js worlds interact.
> The window can see the js objects in the frames etc.
> I have no clue, no flippin clue, how to do that.
> I'm sure it's a lota lota work, and I believe it would gain us almost nothing.
> One more acid3 test would pass, but I think very few websites do that, or need that functionality.
> Frames tend to be independent ads, or videos, and that's it.
> Rather, the vast majority of inaccessible websites will be brought into the fold by Kevin's find&fix work.
> That's where the real world problems are.
> That's where the rubber meets the road.
> That's what I believe anyways.
> So I will get frames version 1 working, but not sure if or when I will get round to frames version 2.
> I don't think it's a lot of bang for the buck.
> As always, I welcome opposing points of view.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

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

Re: [Edbrowse-dev] thoughts on frames

[Adam Thompson]

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

Sorry, have been having much work done on the house so my home internet
connection has been a bit patchy hence why it's taken a while for me to reply.

Anyway, I think the js objects in frames thing is may be more common than we'd
expect, depending on what sites are used.  I'm not sure how much work it'd be to
implement such a thing as js access between frames yet, but it looks like there
may be some way to do this in spidermonkey at least; I think that's what all
that cross-compartment stuff is for.  I'm not sure how that'll work from our
side though since I'm unclear as to whether compartments need to share a js
context or something... I'll try and have a look.

On Mon, Feb 27, 2017 at 09:48:13PM -0800, Kevin Carhart wrote:
> 
> Hi Karl
> 
> One observation I have is that I think find & fix and the spec-based
> approach have converged.  The javascript in the acidtests.org page is a long
> series of scenarios to work on and fix.  And this is a good thing, I think,
> because (a) you know that there will be bang for the buck in the time you
> spend on something, since they have hand-designed the scenarios based on
> what they exemplify.  And (b) the writing style of this code is very human.
> It's indented, it's commented, the variable naming has a cleanness to it and
> doesn't have variables like 'a', 'b', 'c'.  So I think acid3 and find&fix
> are basically the same thing, even if the scenarios we wanted to investigate
> are not the ones about frames.
> 
> On frames in particular, if there's an impasse, there's an impasse.. if you
> don't know how to write it, I seriously doubt that I do.
> 
> But, do you think there is any subset of these situations which might only
> live on the JS side and then be discarded?  For instance, suppose a frame is
> used as temporary storage, or in order to do a Towers of Hammurabi manuever
> and put your interconnected nodes down in a frame, to rearrange them and put
> them back in the main document.
> 
> Is this worth pursuing?  I can't quite tell what the example in acid3 is
> trying to exemplify, but I think 'doc', the side document that is defined as
> 
> var doc = iframe.contentDocument;
> 
> is only intratest.  It produces a pass/fail result and so doc doesn't have
> to create side effects.  Maybe later in another scenario it does, but we can
> try to deal with this test and then take it from there.
> 
> Kevin
> 
> 
> 
> 
> On Mon, 27 Feb 2017, Karl Dahlke wrote:
> 
> >This is way to long for the irc.
> >
> >I am both optimistic and pessimistic about frames.
> >
> >Version 1 allows you to expand a frame inline, instead of the g command that expands it in a new buffer.
> >It works, pretty much. Browse jsrt and look at line 4.
> >Expand it with the exp command.
> >(Contract not yet implemented.)
> >So far so good.
> >
> >Still problems though, a frame in space.com causes a seg fault when I expand it.
> >So still bugs to fix.
> >
> >When finished, version 1 will allow expand and contract of frames inside a window, which is neat,
> >and worth doing I suppose, but it will not make a single website accessible to us that is not already accessible.
> >No progress there.
> >
> >Version 2 might let the js worlds interact.
> >The window can see the js objects in the frames etc.
> >I have no clue, no flippin clue, how to do that.
> >I'm sure it's a lota lota work, and I believe it would gain us almost nothing.
> >One more acid3 test would pass, but I think very few websites do that, or need that functionality.
> >Frames tend to be independent ads, or videos, and that's it.
> >Rather, the vast majority of inaccessible websites will be brought into the fold by Kevin's find&fix work.
> >That's where the real world problems are.
> >That's where the rubber meets the road.
> >That's what I believe anyways.
> >So I will get frames version 1 working, but not sure if or when I will get round to frames version 2.
> >I don't think it's a lot of bang for the buck.
> >As always, I welcome opposing points of view.
> >
> >Karl Dahlke
> >_______________________________________________
> >Edbrowse-dev mailing list
> >Edbrowse-dev@lists.the-brannons.com
> >http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
> >
> 
> --------
> Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

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

[Edbrowse-dev] thoughts on frames

[Karl Dahlke]

> implement such a thing as js access between frames yet, but it looks like there
> may be some way to do this in spidermonkey at least; I think that's what all
> that cross-compartment stuff is for.
> I'll try and have a look.

Agreed, and thank you.
Any such work should probably wait until things stabilize a bit and we stamp a new version;
we have done quite a bit lately.
Also, looking into js 38, or duktape or the next engine whatever it is, might be a higher priority.

Karl Dahlke