This happens on meta
Confirmed, @techAPJ since this is a misbahving onebox can we disable this out of the box?
@Bas I recommend bringing this up with typeform and letting them know we disabled the onebox.
Longer term I want to change our Markdown renderer always to apply diffs as opposed to re-rendering the whole preview.
I temporarily disabled our custom Typeform onebox engine until they sort out this issue on their side.
For now we will fall back to opengraph onebox for Typeform, like:
I don’t think they’ll listen to me… so no, I won’t raise it with them.
Then you are hosed because we don’t control typeform.
Fine with that, I personally don’t use typeform that much, just though it was something that you wanted to know
Drat, I really like Discourse’s custom typeform onebox feature. While this sounds like an annoying bug, wouldn’t a workaround be to simply paste in the typeform link after you’ve composed your paragraphs?
As a hosted customer, is there a way I can get this reverted back for my instance?
I tried whitelisting in iframe setting, but no go.
Onebox only allows blacklisting of domains. The way I disabled Typeform (temporarily) was such that I disabled custom Typeform iframe embedding so that we can at least get the OpenGraph onebox. It’s not possible right now to whitelist Typeform iframe for certain sites.
If we want to do that we’ll have to run a migration for all Discourse instances where we’ll blacklist
typeform.com domain (by adding it into
onebox domains blacklist setting) and the site admin will then have to remove the
typeform.com domain from blacklist setting. Before doing this I want to contact Typeform and explain the issue so that they have a chance to fix this.
I just notified them via Twitter and and their custom Contact us form. I’ll follow up again next week.
I got a not-so-useful standard response from Typeform asking me to look into their Embed SDK which doesn’t provide any information regarding iframe embeds.
But thinking more about the problem described in first post, I realized that we can fix this issue simply by loading their default OpenGraph image in the composer (as placeholder) instead of rendering full blown iframe. I am not sure why we did this (rendering iframe in composer) in the first place. For example we do not render iframe in composer for slides.com onebox, we render an image instead.
So this issue is now fixed via:
I will update onebox gem version soon Done.
Great, thank you! Can you tell me when hosted customers can expect to see this deployed?
Early next week most probably. If you can message me your community URL I can expedite the process if required.
We had to remove support for Typeform iframe embedding completely because on topic render the focus was jumping to Typeform causing page jiggling which we absolutely despise.
As per Typeform documentation they do not recommend or support custom iframe embeds: https://developer.typeform.com/embed/custom-embed/
To properly support Typeform we’ll need to create a plugin using their Embed SDK. I do plan to create a plugin for Typeform embedding but it’s not on the top of my list right now.
Can we please reconsider completely removing support for this until a better solution comes along?
Best I can tell support for Typeform has been around since 3/2017 and only has one bug against it, this one. While I appreciate this bug was found so that support for Typeform can be improved, it’s a shame that this is now gone completely because a user who doesn’t use Typeform that much reported the issue. I’m guessing either nobody uses Tyepform in Discourse, or they found a workaround for this pesky bug.
Would simply pasting in the iframe link after composing the topic be a sufficient workaround to keep this functionality active, so you don’t have to fight focus?
In my case, we have a discourse instance with 700 members, and when I want a embeded form with stripe support, I embed the Typeform. It is important rather than sharing the link, as I know that folks only within the community have accessed and are registering.
- Disabling support for an UI issue seems like an overkill decision.
I realized that white-listing typeform in onebox domains, and or even trying to embed using iframe was not working. (With iframe - it simply blanks).
Could you please share a workaround that will help me to embed the typeform in Discourse?
Here is the work around that I am planning going do - since a feature was killed.
- I am still planing to use the typeform and embed, but I am going to embed in a static HTML page, with my discourse header (at-least looks) like it is a from the same web community.
- Host that static site under my discourse domain and redirect it using discourse domain URI, so that it will at will at-least request the participants to login via my discourse instance.
All of these hoops and jumps because of this change -
- FIX: disable typeform custom engine temporarily · discourse/onebox@a581f65 · GitHub
- Which was supposedly fixed FIX: do not render typeform iframe in preview, render an image instead · discourse/onebox@b8faf57 · GitHub
- But reverted again - No URI shared in this discussion
With the original support completely lost.
Workaround and suggestions to get typeform within discourse will be appreciable.
What a pain. I, too, am disappointed this feature was killed. The remedy appears to have been worse than the illness in this case.
I would recommend a post in #marketplace to commission a plugin using the official embed api
Hi @sam - That’s a one option. How about reverting the change? As the preview form stealing focus does not seem like a huge issue. ( I am user, I am not even sure what that means).
EDIT: I got what the issue is - the Focus is stolen only during the preview mode, like when you are actually typing something in the box when the typeform link. Usually, when the typeform embed is used, you just paste the link (because it needs a wide area to expand and show the form). If you want to type somethig, type it and then paste the link.
I personally think that we overdid something as a fix here by removing the support completely and then wait for SDK based solution.
Ofcourse, this is your call. We as users (two of us) got a negative impression here, and I know how to do some ugly workaround with my requirements and due to lack of this.