[Edbrowse-dev] Dynamic Scripts (fwd)

[Edbrowse-dev] Dynamic Scripts (fwd)

[Kevin Carhart]

Ahh, this is great!  I think this is a big one.  I think we brought 
it up at one time and set it aside.  Do you think it's the same as the 
following?  Check it out, we touched on this way before duktape.  I copied 
and pasted this old list traffic a long time ago, and when I read your 
message, I thought it sounded like the same thing.  Exemplified by 
http://carhart.net/~kevin/immediate.html


On Wed, 15 Jun 2016, Karl Dahlke wrote:

> Is there some simple js you could whip up and post,
> as an example, so I know what you're talking about?
>
> Karl Dahlke
>

---

I replied:

Hi Karl
Yes.... could you go to http://carhart.net/~kevin/immediate.html?
In edbrowse nothing will happen so please 'ub' for the HTML source.
Now if I bail out and try it in my firefox, the alert will fire.  I'm not 
sure precisely which
line it occurs on.  But there is not an eval() in javascript, so I think 
there must be
evaluation supplied by the DOM.

I believe this is the purpose of the iframe formulation in the google 
groups page we were
talking about a while ago.  immediate.html is a simpler version of the 
construction that they
use.  Since google is doing it, it may be a common phrasing.
---

Karl replied:

> frame.contentDocument.write(html);

The key here is, I think, when we design the new Iframe object,
that Iframe.contentDocument.write() somehow invokes the innerHTML 
machinery.
That parses and executes html immediately,
though if that html has <script> as in your example,
the script might not run immediately, as another script is already 
running,
but I don't think that's a problem,
as long as the html dom objects are created immediately, which they are,
because innerHTML requires that as we already saw.

---

[Edbrowse-dev] Dynamic Scripts (fwd)

[Karl Dahlke]

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

With latest push, you can create an Iframe dynamically using document.createElement, and put it just about anywhere.
Kevin's immediate program fires immediately, though it is still not right in a way that you can't see.

As I've been doing cross-frame references, I come to realize an unexpected problem.
In side the frame f, create a script s, and then ask: s instanceof Script, and it fails.

Subtle ...

It fails because classes are created per window, that is, per frame.
If a script is instantiated by any means inside a frame f, it is an instance of f.contentWindow.Script, not an instance of Script.
I'm almost certain that these classes should be defined across all frames, across all windows, like Array and Date and the like.
It would also save time and memory, and that's a nice thing too.
I was going to do this a while ago, put them all in eb$master, but there was a snag, a reason not to, and I don't remember the gotcha right now.
I'll go back and look, because it's a tad more important than I thought it first was.

Karl Dahlke