Consider.it integration in discourse

Dear people,

I’ve resolved this issue.

While debugging, I discovered a discrepancy between iframely.com/debug and onebox’s oembed requests that caused the failure. This might be of interest to @codinghorror, as he says “as long as it passes [at iframely] we are usually good”. Most likely, I’m the only one who will ever be tripped up by this discrepancy. But maybe not, so I thought I’d describe it.

iframely makes the request to considerit’s server with HTML Content-Type set. Onebox does not. The considerit controller that handles initial page load of non-json requests has a respond_to :html constraint on the format. So the controller just returned 404 because it refused to process a non-HTML request. Removing the constraint makes it work.

A mostly working Discourse example with considerit embed: https://forum.daohub.org/t/dao-consider-it-server-upgrade-30-min/3737/3. I’ll write a followup post for why I say “mostly”.

Thanks for all your help.
Travis

2 Likes

Hey, great work! And please write the followup because I’m very interessed on those custom onebox.

About you iframe resize problem, I think the google docs onebox resizes it, so check that code for some clues.

There is one, hopefully final, hurdle to fully working considerit oembed: consistent iframe resizing.

Embedding in a Discourse thread works sometimes. But it often doesn’t run the javascript that invokes the resizing.

I haven’t pinned it down, but here is one curious way I can replicate in Discourse:

  • doesn’t resize if I just load a thread with a considerit link
  • if I have the editor open for the post with the link, the iframe resize works in the thread (but not the preview)

This holds true across refreshes.

So there’s something special that seems to happen in Discourse during edit post mode.

I recorded this riveting 40 second video to demonstrate the behavior.

I’ve had a frustrating past several hours trying to figure it out. If anyone has insights, I would really appreciate it!

Thanks,
Travis


Background:

From my earlier post, the oembed html snippet that considerit returns includes: “…mostly just an iframe…The HTML also loads a small javascript library into the containing window which resizes the iframe whenever the content inside the iframe changes height. The author of this library asserts that the library is engineered to play nicely with the containing window.”

The specific code is e.g. :

   <iframe id='considerit-embed-4186' src='https://dao.consider.it/embed/proposal/slockit1' width='700' frameborder='0' style='overflow:hidden' scrolling='no'></iframe>
   <script src='https://cdnjs.cloudflare.com/ajax/libs/iframe-resizer/3.5.3/iframeResizer.min.js'></script>
   <script type='application/javascript'>
     var resize_interval=setInterval(function(){
       if (typeof iFrameResize != 'undefined'){
         iFrameResize({log:false, checkOrigin:false}, document.getElementById('considerit-embed-4186'))
         clearInterval(resize_interval)
       }
     }, 40)
   </script>
3 Likes

More specifically, I don’t understand why edit post mode would trigger the iframe resizing. Does Discourse/Onebox do anything to prevent a script loaded via Onebox from running except when it is initially oneboxed?

Knowing if there is some special treatment of oembeded-javascript in Onebox would help me greatly in what I investigate to solve this issue.

Thanks!

Anyone have any promising leads for me? :slight_smile:

Even just a “nope, no idea what might be happening” would be useful, as I’ll then know I’m on my own!

I’ve extracted and updated my latest question into its own thread in hopes of attracting the attention of someone who can help, at Attention Onebox experts: Help requested resizing an iFrame embedded via oEmbed

I have a foreboding though that the dynamic resizing strategy I outlined above is going to turn out to not to work within Discourse :frowning:

Thanks for everyone’s help here.

2 Likes