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.
The focus is also stolen when the Typerform embed is in view when the topic/post is loaded, as per:
That is a deal-breaker.
You’re very wrong here, it also hijacked focus whenever the embed was visible, making the removal a necessity. Your best options are marketplace or maybe reaching out to Typeform directly. I know @techAPJ spoke to them back in July, perhaps as a customer you will have more luck.
There hasn’t been a clarion call from Typeform users to reinstate the embeds because the use case is very specific - @bas may have filed the issue initially, but it was affecting every discourse instance where typeform is embedded. If Typeform is a business critical need I suggest @Senthil and @John_Waltrip1 combine their budgets and get a developer on the case.
Hi @Stephen (@sam ) - Let us not push folks to marketplace - Some of us are developers are very well capable of supporting ourselves. And it is one the reasons we choose a open source platform like discourse.
When I found a bug, and noticed what happened, and I am engaging with others here. Pushing members who come for support to marketplace seems a bit odd. I already shared what my backup plan was as for my immediate need.
I respect discourse teams choices.
I wonder why I had not noticed any of these, and I never something that bothered me with my usage. I will see what I can do for myself. I have limited time now, I cannot contribute to enabling this in discourse atm.
Thank you,
Senthil
If you have no time but have yes money, it seems to me perfectly reasonable to point you at marketplace . We have zero paying customers asking for a fix here and can not justify development time to build the custom plugin. We are not going to revert our change here, if you want the feature it needs to be implemented properly using the embed API. This clearly costs time and time translates pretty cleanly to money.
Just found this thread, when looking for reasons why all our embedded Typeforms have stopped working…
We now have a few different teams who use Typeform on our forums, and the custom Onebox integration was a major factor in deciding to get a paid account with them - seamless embedding is a much nicer user experience than sending them off-site to load a survey page.
I’m not sure what I can contribute towards getting that custom plugin built, but I wanted to post here so there was at least one paying customer in this thread
Thanks for the post @BenLeong!
If you are also a customer of typeform, perhaps you could bring it up with them? Their code is calling the focus action, not ours – so we’d be building a workaround for someone else’s code behaviors.
Better to fix it at the source so it gets fixed for everyone, I think.
Will do - I’ll direct them to this thread for more details, if they need them.
No luck with Typeform, unfortunately - this was the response after the query was escalated to their developers:
As this is a custom embed, it isn’t something we can assist with, I’m afraid.
As your site isn’t a static site they recommended that, if you are looking to customise your embedded typeform, then our Embed SDK might be better-suited for this purpose.
We are thinking about this and will see if we can find someone in the wider community to build this. There is quite a lot of work in building this in a secure way. Essentially this embed API is expecting Discourse to trust a 3rd party JS payload to run within the same page as Discourse, isolating it into an iframe may be possible but its a tricky thing to build.
I am curious though at a more high level, what specific examples do you use typeform for? Maybe a native Discourse plugin with similar functionality is the path we should take longer term?
I came up with a working example using the SDK inside an iframe: Codepen. Codepen re-renders the preview when something changes and the focus remains on the HTML editor.
I modified the TypeForm example (Original Codepen) injecting the <div>
and <script>
inside the IFrame through the srcdoc attribute and changed the references in order to avoid leaning on window
.
If we need to support older browsers, we could inject the iframe content via JS (with another script tag)
I don’t know if it’s acceptable to render inline scripts inside a Onebox Engine. If it is, we could simply bring the deleted engine back and tweak it to use this technique without the need of a custom plugin.
Any thoughts? Thanks!
Keep in mind Discourse is very aggressive about deprecating old browser support, as it stands we support: IE11 and up.
In this particular case we would recommend a polyfill for edge and IE. Can I use... Support tables for HTML5, CSS3, etc we have a few other polyfills going now.
Inline scripts are a huge no-no, what we would do is defer load them similar to how Discourse Graphviz does it.
Given the JS requirement here my recommendation here is to start with a very specific discourse-typeform
plugin here instead of attempting to bring this in to onebox.
Looks like passing the param: typeform-embed=embed-widget
solves the focus issue (example). When doing this through the SDK, an IFrame that contains that parameter as a query string in the original URL is created.
Other options listed here can also be passed as query strings.
In my opinion, adding these parameters to the original engine is enough, but I will be happy to start working on a plugin if that is a better option
So you mean we can just revert the changes and add that query param to fix the focus steal?
Yes!
Please take a look at the SDK example and inspect the source, you will note that the SDK is rendering an iframe
and doing exactly what I’m proposing.
Wow awesome, if it works, go ahead and submit a PR to onebox! We can get it deployed here to confirm
Here it is. I have not tried it against a discourse local instance yet (Still trying to set it up on my machine)