Snapshots of nested iframes with Shutterbug

[Aaron Unger]

The ITSI portal uses Shutterbug to take snapshots of models embedded
within iframes. I have one particular model which itself has some
iframes (http://itsi.portal.concord.org/activities/78.run_html -- see
the model in the 'Collect Data II' section). Currently, when I snapshot
the model iframe, the inner iframes are basically ignored.

Is there any way to get Shutterbug to recurse iframes? Or can the model
page do something when Shutterbug issues 'saycheese' which would
re-target the snapshot to the sub-iframe? It's ok if just the Lab model
gets snapshotted in this case. Any thoughts?

Thanks!
-- Aaron

[Scott Cytacki]

Strange, it should actually already work. Piotr added support for this when working on the jsmol stuff.

https://github.com/concord-consortium/shutterbug/blob/master/demo/nested_iframe_example.html

-- Aaron

--
You received this message because you are subscribed to the Google Groups "shutterbug-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shutterbug-dev+unsubscribe@googlegroups.com.
To post to this group, send email to shutterbug-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/537FCD11.4000304%40concord.org.
For more options, visit https://groups.google.com/d/optout.

--

Scott Cytacki

The Concord Consortium

http://concord.org

[Aaron Unger]

Hmm. Could it be related to the fact that the innermost frame content is complex (it's a Lab model)? I tried adding Shutterbug to the middle frame content (so that Shutterbug would be set up at all levels), but that didn't seem to help.

-- Aaron

On 5/23/2014 6:31 PM, Scott Cytacki wrote:

Strange, it should actually already work. Piotr added support for this when working on the jsmol stuff.

https://github.com/concord-consortium/shutterbug/blob/master/demo/nested_iframe_example.html

On Fri, May 23, 2014 at 6:34 PM, Aaron Unger <aun...@concord.org> wrote:

The ITSI portal uses Shutterbug to take snapshots of models embedded within iframes. I have one particular model which itself has some iframes (http://itsi.portal.concord.org/activities/78.run_html -- see the model in the 'Collect Data II' section). Currently, when I snapshot the model iframe, the inner iframes are basically ignored.

Is there any way to get Shutterbug to recurse iframes? Or can the model page do something when Shutterbug issues 'saycheese' which would re-target the snapshot to the sub-iframe? It's ok if just the Lab model gets snapshotted in this case. Any thoughts?

Thanks!

-- Aaron

--
You received this message because you are subscribed to the Google Groups "shutterbug-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to shutterbug-de...@googlegroups.com.
To post to this group, send email to shutter...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/537FCD11.4000304%40concord.org.
For more options, visit https://groups.google.com/d/optout.

--

Scott Cytacki

The Concord Consortium

http://concord.org

--
You received this message because you are subscribed to the Google Groups "shutterbug-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to shutterbug-de...@googlegroups.com.
To post to this group, send email to shutter...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/CAOSVvmqqvJJugXAO1fYrF8NoF_orsYUyC%3DqD7XJTvJJ24ejcFg%40mail.gmail.com.

[Scott Cytacki]

You definitely need to add shutterbug in the middle window. 

I can think of a few things:

- perhaps itsi portal isn't using the latest shutterbug itself

- the way shutterbug is configured on the middle window is somehow incorrect. I've seen in some cases that it is important to select a certain dom element to snapshot. Just doing 'body' doesn't work all the time.

- timeout setting: there is a timeout value that gets passed from into the iframe as you go down the stack of frames. It is decremented somewhat on each level, so perhaps the middle window is not waiting long enough for lab to take the snapshot.

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/5384B514.9020604%40concord.org.

For more options, visit https://groups.google.com/d/optout.

[Aaron Unger]

I just updated the ITSI portal's shutterbug version the other day, so it should be using the latest.

Perhaps it's because there's no instance of Shutterbug running on the intermediate page's server? Is there anything special I need to do if I'm using a third-party shutterbug instance?

I'll mess around with the target and timeout to see if that is interfering...

-- Aaron

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/CAOSVvmo6VBABKFS2TWEs-6X34LUmFgovEoVuPgoGqe--p27kNg%40mail.gmail.com.

[Noah Paessel]

The recursing iFrames feature of shutterbug only works only if each iFrame has shutterbug loaded *and* configured to snapshot the correct part of it's DOM.  

You can see in Piotr's example that each iFrame includes shutterbug, and also initializes its own shutterbug instances with the next iFrame down the stack.

https://github.com/concord-consortium/shutterbug/blob/master/demo/nested_iframe_example.html ➙ 

https://github.com/concord-consortium/shutterbug/blob/master/demo/iframe4.html ➙ 

https://github.com/concord-consortium/shutterbug/blob/master/demo/iframe.html

I wish there were some better magic we could do here to automate this.

-n

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/5384BF45.6010407%40concord.org.

[Aaron Unger]

The chaining of  shutterbug instances makes sense. I agree that it'd be nice if it didn't have to work that way.

So I've sort of got it working - some combination of 1) pointing to the itsi portal shutterbug instead of the herokuapp shutterbug and 2) wrapping the page content in a div and targeting that rather than 'body'.

The only problem now is that the Lab css seems to be getting lost... Thoughts on that? It also happens if I add a snapshot button to the intermediate page (so a page with an iframe, no nesting), so I don't think it's a problem with the nested iframes.

-- Aaron

[Scott Cytacki]

Ah yes, the heroku app is not updated as far as I know. So the shutterbug.js from it would not support the nested iframes.

Regarding the css issues, I notice the css (or at least some styling) is broken when taking snapshots of MW models directly in ITSI now. For example in this activity: http://itsi.portal.concord.org/activities/16.run_html

It seems to be related to https/ssl. If I embed an interactive with https into LARA I get the same styling issues. My guess is that it is related to how (I think) shutterbug on the server side sets the codebase of the document. And perhaps that codebase is https, but the client side is replacing the "//..." links with "http://...", so then the css is blocked because it is mixing protocols.

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/5384CC9E.50403%40concord.org.

For more options, visit https://groups.google.com/d/optout.

[Aaron Unger]

Interestingly, if I point the iframes to http://lab.concord.org/...  instead of https://lab.concord.org/... the snapshots look fine.

Accessing the ITSI portal through https (so the whole stack is https iframes) doesn't seem to help, though.

-- Aaron

[Noah Paessel]

Shutterbug is setting it doc root (base_url in the code, which includes http or https) based on:  1) rack request param 'base_url', 2) The web referrer, or 3) The URL it was loaded as.

https://github.com/concord-consortium/shutterbug/blob/master/lib/shutterbug/configuration.rb#L41

When the HTML is evaluated via PhantomJS its loading it as a file off the file system.  Seems likely that an SSL implementation would mark content loaded from the filesystem as not being sent over SSL. (?)

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/5384D93E.5000300%40concord.org.

[Noah Paessel]

Seems like we could try passing "--ignore-ssl-errors=true" to phantomjs when it is starting up.   on this line:  

https://github.com/concord-consortium/shutterbug/blob/master/lib/shutterbug/phantom_job.rb#L63

I took that from the API:

http://phantomjs.org/api/command-line.html

Also note that a long time ago there was a discussion and ticket about preventing mixed content warnings when loading from the filesystem on the webkit tracker:  https://bugs.webkit.org/show_bug.cgi?id=63145

Are you able to test the above Aaron?

[Aaron Unger]

I can test that. It looks like there might be some other options worth checking, too.

I'll let you know what I find.

-- Aaron

[Aaron Unger]

Setting --ssl-protocol=any fixed the problem. I think for good measure I'll also include --ignore-ssl-errors=true, so we don't have to worry about invalid certificate problems later.

-- Aaron

[Aaron Unger]

The fix that worked on my machine, doesn't work on the ITSI server. The same html fragment rendered with the same version of phantomjs  yields different results on the different machines. Frustrating.

Perhaps there's something we can do on the fragment capturing side?

-- Aaron

[Noah Paessel]

Does Itsi run its own shutterbug rack app, or does it use the heroku App?

To view this discussion on the web visit https://groups.google.com/d/msgid/shutterbug-dev/5384FD85.6030203%40concord.org.

[Aaron Unger]

It's using it's own rack app, which is running the latest and greatest version.

-- Aaron

[Aaron Unger]

OK, so I think I've got a good grasp of what's going on.

phantomjs is statically linked to openssl at compile-time. Because ITSI is running on a RHEL 5.8 box (and the binaries provided by phantomjs are also built on a CentOS 5.8 box), openssl 0.9.8 is being statically linked in. This version of openssl seems to have issues with https on lab.concord.org and lab-framework.concord.org.

The version I built on my local box is linked to openssl 1.0.1 and so it doesn't have the same problem. Unfortunately, any system with a newer version of openssl also has a newer version of glibc, and so therefore building a binary on those systems and copying it to the ITSI server won't work.

So that leaves 2 easy options:
 1) How is the ssl on lab and lab-framework configured? Is there a way we can change it so that older versions of openssl support it?
or 2) It might be time to move the ITSI server to a newer OS. ITSI is just running the portal, correct? In which case it might not be too painful to make the move.

Thoughts?

-- Aaron

[Aaron Unger]

And actually, I just looked at how lab was configured, and we can scratch #1. It's specifically the SNI part of openssl that's failing on the old version of openssl, and SNI is required since we're serving lab through cloudfront.

I guess an option 3 would be to petition the phantomjs crew to build one against an SNI-enabled openssl, but I'd imagine they'll run into the same problems I'm running into building one that is supported on older systems.

-- Aaron