* [Edbrowse-dev] thoughts on frames @ 2017-02-27 17:34 Karl Dahlke 2017-02-28 5:48 ` Kevin Carhart 0 siblings, 1 reply; 4+ messages in thread From: Karl Dahlke @ 2017-02-27 17:34 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Edbrowse-dev] thoughts on frames 2017-02-27 17:34 [Edbrowse-dev] thoughts on frames Karl Dahlke @ 2017-02-28 5:48 ` Kevin Carhart 2017-03-04 11:31 ` Adam Thompson 0 siblings, 1 reply; 4+ messages in thread From: Kevin Carhart @ 2017-02-28 5:48 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Edbrowse-dev] thoughts on frames 2017-02-28 5:48 ` Kevin Carhart @ 2017-03-04 11:31 ` Adam Thompson 2017-03-04 12:38 ` Karl Dahlke 0 siblings, 1 reply; 4+ messages in thread From: Adam Thompson @ 2017-03-04 11:31 UTC (permalink / raw) To: Kevin Carhart; +Cc: Karl Dahlke, Edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Edbrowse-dev] thoughts on frames 2017-03-04 11:31 ` Adam Thompson @ 2017-03-04 12:38 ` Karl Dahlke 0 siblings, 0 replies; 4+ messages in thread From: Karl Dahlke @ 2017-03-04 12:38 UTC (permalink / raw) To: Edbrowse-dev > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-03-04 12:38 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-27 17:34 [Edbrowse-dev] thoughts on frames Karl Dahlke 2017-02-28 5:48 ` Kevin Carhart 2017-03-04 11:31 ` Adam Thompson 2017-03-04 12:38 ` Karl Dahlke
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).