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.
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.”
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.