Reusing DIVs.

[Doug Koellmer]

Me again!  I took a week to work on some other things, but I'm moving back to caja integration now for a bit.

I have the major gears grinding away.  Vanilla caja was pretty easy to integrate...good job guys.  However, I notice now that I'm getting "leaked" iframes, specifically <iframe style="display: none; " width="0" height="0" class="es53-guest-frame"></iframe>.

To roughly describe my setup, I have multiple (average 12) DIVs on a page, all displaying static cajoled html inserted using normal innerHTML="yaddayadda".  A user clicks on a cell and the dynamic version is inserted with caja.load().  A user clicks outside and innerHTML is used again to insert static html.  A user might go from profile to profile, with each click invoking a caja.load() call on a different DIV.  The DIVs are pooled, so in practice there may be 20 max created during the life of my application.  They get attached/detached to/from the DOM occasionally, but never actually GCed.

Any advice on using caja efficiently with this set up?  I poured through documentation and the Playground code, but I don't see anything obvious.

I understand if you need more info.

Thank you.

[ihab...@gmail.com]

Hi Doug,

On Sat, Jul 14, 2012 at 11:28 AM, Doug Koellmer <dou...@gmail.com> wrote:

... I'm moving back to caja integration now for a bit.

Great, good to hear from you again!

 

... I notice now that I'm getting "leaked" iframes, specifically <iframe style="display: none; " width="0" height="0" class="es53-guest-frame"></iframe>.

These are iframes that Caja uses to squirrel away the untrusted code, yes. For each gadget, Caja creates one of these.

 

To roughly describe my setup, I have multiple (average 12) DIVs on a page, all displaying static cajoled html inserted using normal innerHTML="yaddayadda".  A user clicks on a cell and the dynamic version is inserted with caja.load().  A user clicks outside and innerHTML is used again to insert static html.  A user might go from profile to profile, with each click invoking a caja.load() call on a different DIV.  The DIVs are pooled, so in practice there may be 20 max created during the life of my application.  They get attached/detached to/from the DOM occasionally, but never actually GCed.

I think I can safely say that we never envisioned this use case. :)

Any advice on using caja efficiently with this set up?  I poured through documentation and the Playground code, but I don't see anything obvious.

First, you need to be able to track resource usage in your browser. Chrome's 

  View -> Developer -> Developer Tools -> Profiles -> Take Heap Snapshot

is useful in that regard. Next, when you do a caja.load() --

  caja.load(..., function(frame) {

    // "frame.iframe" is a direct reference to the

    // "es53-guest-frame" that has been created

  })

If you don't need it any more, you can simply do:

  frame.iframe.setAttribute("src", "http://my.server/blank.html");

where "blank.html" is some empty HTML file you have somewhere. Then you can say:

  frame.iframe.parentNode.removeChild(frame.iframe);

The question is whether this is sufficient to sufficiently stop the leaks. A lot of the Caja data structures are actually in a separate iframe, and we have not audited our code for any dangling references. If you could try this technique (as a vanguard of a new way...) and let us know how it works, that would be awesome.

Ihab

--
Ihab A.B. Awad, Palo Alto, CA

[ihab...@gmail.com]

I should clarify --

On Sun, Jul 15, 2012 at 10:28 AM, <ihab...@gmail.com> wrote:

  frame.iframe.setAttribute("src", "http://my.server/blank.html");

You could also use "about:blank", but this will create spurious warnings if you are serving the main page over HTTPS.

Ihab

[felix]

btw, this is also a problem in the playground, every time you hit 'cajole' a new guest frame is added (and it's not clear to me if these are completely isolated from each other or not). I think we can fix caja.js so that if you re-use the same container div, it removes any previous cajoled gadget in the same div, but I haven't tried doing that yet.

[ihab...@gmail.com]

On Sun, Jul 15, 2012 at 11:44 AM, <ihab...@gmail.com> wrote:

You could also use "about:blank", but this will create spurious warnings if you are serving the main page over HTTPS.

See also:

http://stackoverflow.com/questions/1626300/how-to-close-an-iframe

Ihab

[Doug Koellmer]

Thanks for all the advice.  I have done as instructed, and the iframe is being removed from the DOM nicely.

Using the heap snapshot tool (thanks for bringing this tool to my attention btw), I see that memory is slowly going up a few megs at a time every time I use caja.load then "kill" the iframe, as opposed to using normal innerHTML, which pretty much flatlines memory usage.

I think it will take some time for me to get the most out of the snapshot tool, but under the "compiled code" section, I see a reference to "http://localhost:8888/js/caja/4960/es53-guest-frame.js?debug=1" added for every caja.load call.

Let me know if/how I can provide more information.

- Doug

[felix]

yeah I think we hold some references to guest frame objects (which is one reason I think caja.js should be doing the kill/unload; it knows everything it's holding on to and can unhook it all.)

[Doug Koellmer]

Do you think I should create an issue for this?  I can look into fixing it myself if you don't think it's overly complicated (more than a few days) for someone new to the codebase.  The leak is pretty low on my personal priority list though, so it will be some weeks before I can look into it.

[ihab...@gmail.com]

On Mon, Jul 16, 2012 at 7:38 PM, Doug Koellmer <dou...@gmail.com> wrote:

Do you think I should create an issue for this?

Felix already did:

  New issue 1492 by felix8a: caja.js needs a way to kill guests
  http://code.google.com/p/google-caja/issues/detail?id=1492

 

I can look into fixing it myself if you don't think it's overly complicated (more than a few days) for someone new to the codebase.  The leak is pretty low on my personal priority list though, so it will be some weeks before I can look into it.

It's sort of low on our list as well, so I guess whichever one gets there first?

:)

Ihab

[Doug Koellmer]

Cool...it's a race!...kind of.

I'll start poking around the code here and there to slowly get an idea of what needs doing.

[Bert Lagaisse]

I have a similar question. I'm trying to unload a frame (and containing div), which has an interval in it. For some reason, the interval keeps firing if I remove the div from the hostpage.

Is it possible to "unload" a guest page, or completely remove the frame and all its contents (including intervals etc).

I can't find an "unload" or "remove" frame option.

Any suggestions ? 

Removing the iframe after setting the src to blank only generates a lot of errors, and the caja object is not usable afterwards.

Op zaterdag 14 juli 2012 20:28:58 UTC+2 schreef Doug Koellmer:

[Kevin Reid]

On Thu, May 25, 2017 at 6:00 AM, Bert Lagaisse <bert.l...@gmail.com> wrote:

I have a similar question. I'm trying to unload a frame (and containing div), which has an interval in it. For some reason, the interval keeps firing if I remove the div from the hostpage.

Is it possible to "unload" a guest page, or completely remove the frame and all its contents (including intervals etc).

Caja does not support destroying a guest. It would be possible, but hasn't been implemented.

[Mike Stay]

As far as destroying an interval goes, you can replace the existing
setInterval function before loading the guest code with a function
that adds each created interval to a table. At destruction time you
can use it to cancel the intervals.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Google Caja Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-caja-dis...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Mike Stay - meta...@gmail.com
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com