Re: Snapshots of Nested Iframes in LARA

4 views
Skip to first unread message

Scott Cytacki

unread,
May 30, 2014, 11:10:37 AM5/30/14
to Wladkowski, Henry, Frieda Reichsman, shutter...@googlegroups.com
Hi Henry,

I'm not sure what your work around was to get the nested iframes to work. Did you modify shutterbug.js?

The latest version of shutterbug should handle nested iframes for you. You need to be using this latest version in all of the frames.
Looking at the code, it looks like it is using an older version of shutterbug from lab-dev.ritesproject.net.

There isn't an up-to-date copy of shutterbug.js that you can just reference from a URL. So I would recommend copying it from here:
and putting it next to your html pages.

Also Aaron has found some strange issues with sizing when nested iframes are used. So if you are using the latest version of shutterbug and you still have issues with nested iframes, please let us know. 
The best ways to do that are to:
- join the shutterbug-dev google group
- or create an issue in the shutterbug github issue tracker.


On Thu, May 29, 2014 at 4:52 PM, Wladkowski, Henry <hen...@ritesproject.net> wrote:
Hello Scott and Frieda,

  Earlier I was having trouble getting snapshots of custom made content for RITES.  Thanks to your email to the git repository for shutterbug, I was able to get about half of the pieces I needed to enable the desired snapshots.  The other half was RITES idiosyncrasies and where shutterbug was installed; certainly not something you need to worry about!

  During a meeting between Frieda and I, I brought up a problem getting shutterbug to capture pages with nested iframes, along with a possible workaround.  It's something that really needs an example, so I quickly redrafted one up.


  Testing on my computer it works fine, though it is a little ambiguously slow.  To be clear, everything below the line "Click on each rock for a closer view. ..." should be in the snapshot.  Maybe a loading bar, hour glass, or other feature that indicates the computer is still loading the image?  I'm guessing my browser's cache or a lack of patience is to blame for my supposed problem.

  With this particular example there is a minor issue.  If you have an enlarged rock in view when taking a snapshot, the resulting image has the rock placed a little too low compared to the original.  That said, there's another problem that originates with the webpage, not shutterbug, that makes the window a lot longer than it was before, and I'm not sure how many people will be trying to do the same thing the way I did it.  I can send you a link to the embedded webpage as well if you're interested.

Thanks for making this work!  I'll let you know if there's something else that seems to break, and let me know if you have any questions for me!

--



Henry Wladkowski
Interface Technician



--
Scott Cytacki
The Concord Consortium

Henry Wladkowski

unread,
Jun 4, 2014, 3:42:26 PM6/4/14
to shutter...@googlegroups.com, hen...@ritesproject.net, freic...@concord.org
Hello everyone!

  I have a page with two iframes in it, one of an editable table that has an up to date version of shutterbug, and the other a SWF that isn't ours to edit, so it does not have shutterbug.  Predictably, the SWF isn't captured.  What's strange is:
  • Instead of a blank page for the SWF iframe, the snapshot shows the working, edited copy of the table.
  • The snapshot shows the default, unedited table for the table's iframe.
Here's an example page of this behavior: http://authoring.concord.org/activities/375/pages/2479/edit
This strangeness is particularly apparent when you click on the "Prepare for Snapshot" button I put in the example, which hides the iframe for the SWF (along with some crediting text).  The snapshot still puts the edited copy of the table in the SWF's iframe, now set to 'style="display:none;", and shows the default unedited table for the table's iframe, which ends up being the only iframe visible.

I've already found two workarounds for this particular example - one involving switching the order of the iframes -  so it's not that important to get specifically this running.  However, it does show some weird behavior that might crop up somewhere else - perhaps something to let other editors know about.

                                                                                                                                  Henry Wladkowski

Noah Paessel

unread,
Jun 5, 2014, 6:59:01 PM6/5/14
to Henry Wladkowski, shutter...@googlegroups.com, Frieda Reichsman

Hi Henry,

Sorry for not answering sooner.

I had a look at your example. If you only want to target the iframe with the table in it, then you can tell shutterbug to only target that iFrame for its snapshot.

So I have recreated your page here: http://dl.dropboxusercontent.com/u/73403/ritestest.html
I removed the javascript which dynamically hide things.  Then I told shutterbug to target just the table iFrame.  I did this by giving the iFrame an ID,  and then initializing shutterbug with that iframes selector:

.... 
<script>new Shutterbug('#table');</script> 
… 
<iframe id="table" src="http://goo.gl/Gh5PGB" width="800" height="200" frameborder="0"></iframe>
… 

I also added a page-8 to your generic test activity for you to try:   http://authoring.concord.org/activities/375/pages/2491/preview

I hope this helps!

- Noah





--
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/079773df-2ae0-499f-9448-58a2112bd3e7%40googlegroups.com.

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

Henry Wladkowski

unread,
Jun 6, 2014, 9:00:12 AM6/6/14
to shutter...@googlegroups.com, hen...@ritesproject.net, freic...@concord.org, kno...@gmail.com
Hi Noah,

  I didn't know you could do that.  Thanks!  I think I'll actually end up using that example, since it looks much better than the workaround I picked.

                                                                                                          Henry Wladkowski
Reply all
Reply to author
Forward
0 new messages