Adding app.screencast.com as an oEmbed provider

[brhodes]

This ticket is a request to have ​https://app.screencast.com added to the list of oEmbed providers.

TechSmith opened a ticket with you 8 years ago to add Screencast.com (original ticket: #38367). We have created a new version of Screencast with an updated domain name and new oEmbed api than the old ticket.

The new version of Screencast also has oEmbed endpoints and header metadata tags set up for unfurling.

Example embeddable URLs:
​https://app.screencast.com/<hash>/e or
​https://app.screencast.com/connector/embed/index/<hash>

The hash is unique for each content page.
E.g. ​https://app.screencast.com/jRnW7zEIqmf6w/e or
​https://app.screencast.com/connector/embed/index/jRnW7zEIqmf6w

[swissspidy]

What's the difference between Screencast Classic and the new one?

If this is a completely new app, then I think it would be good to fill out ​the questionnaire again.

A lot has changed in 8 years. From what I can see, there is no longer any API documentation whatsoever. The old URLs also have oEmbed discovery tags, whereas the new ones don't. If they had discovery tags, then maybe they don't even needed to be added to our allowlist because they just work.

Those are just 2 concerns I see at a glance.

[brhodes]

Here is an updated Questionnaire for this new version of Screencast.

Is the service popular enough for core developers to have heard of it before? Is it “mainstream?”

Developers may know of other TechSmith products such as Snagit and Camtasia which all integrate with Screencast to share images and video. ​Screencast Classic which is approved as an oEmbed provider by WordPress has been around for 15 years and hosts roughly 99 million pieces of content. The newer version of Screencast has been available for 2 years in October. We are in the process of moving all Screencast Classic users to the new Screencast and shutting down the Classic version at some future date.

If similar services are already supported, how does this service compare in terms of size, features, and backing?

The new Screencast currently has 440,000+ active monthly users and continues to grow as we migrate Classic Screencast Users to the new Screencast. As mentioned above, it integrates with many of TechSmith's other products including the latest versions of Snagit and Camtasia. Screencast is actively being worked on and supported by TechSmith.

Does this service have a large following on Twitter, Facebook, or other social media? Is its Twitter account verified?

Screencast itself doesn't have a Twitter account, but ​TechSmith does. The account is verified and has 31.9k followers. TechSmith also has a Facebook page ​here.

Is its oEmbed endpoint clearly established and properly documented? (Sometimes, they are just a developer’s pet project that may not be supported.)

The oEmbed API on Screencast is fully supported and is currently in use with the live service. You can find the documentation on the ​oEmbed API Here. This was created for this ticket.

Does the service make an effort to build relationships with developers, such as through robust APIs?

We have APIs that allow other TechSmith products like Camtasia and Snagit to integrate into Screencast. But these are not public.

How old is the service?

Modern Screencast is 2 years old in October.

Does it have a well-established Wikipedia article?

Screencast does not have its own Wikipedia article, but TechSmith Snagit has a Wikipedia article ​here.

Has anyone written a WordPress plugin that leverages the service in some way, whether adding it as an oEmbed provider, creating a shortcode, or leveraging other APIs of the service? Do these plugins have any noticeable adoption or traction that would indicate usage and demand?

No, not for the new Screencast. There is an old unmaintained Screencast Classic plugin.

Is the provider frequently proposed?

I believe this is the first request. We have customers of Screencast that use WordPress and would love for their media urls to embed correctly in their pages.

---

Let me know if you have further questions.

[swissspidy]

Tentatively moving to future release milestone for consideration.

Would it be possible to add this documentation somewhere on the provider's website? The point about providing documentation is not for the sake of this questionnaire, but generally for developers.

Developers will look at your website to see if oEmbed is supported. And right now this can't be seen.

There's also this question:

Does the oEmbed endpoint work with WordPress’ oEmbed auto-discovery?

Could you add those oEmbed auto-discovery tags to your content?

Then we might not even need to make changes in WordPress, as it would just work.

[brhodes]

Sorry I missed that other question. I believe we do include the tags for oEmbed auto-discovery? But you may be referring to something else. Our media view pages include these links in the header.
​https://app.screencast.com/xNlN9BMD8Emli

I tried to embed media url as a content block in your test site and it failed. When looking at your docs I see you have the (old) Screencast block.
​https://wordpress.org/documentation/article/screencast-block/

I'm wondering if this was updated to the new url format then oEmbed would just work?

[swissspidy]

I was looking at ​https://app.screencast.com/jRnW7zEIqmf6w/e, which you provided in the description, and it doesn't have the discovery tags. ​https://app.screencast.com/xNlN9BMD8Emli does have them though.

Both pages however return a HTTP 404 status, so WordPress does not attempt auto discovery. Is this something you can fix?

That's why the embed failed for you when you tried it.

And yes, the Screencast Block would need to be updated, but that's what this ticket here is for :-)

[brhodes]

When you say "Both pages however return a HTT 404 status" are these the pages you are referring too?

https://app.screencast.com/api/v1/oembed/.json?url=https://app.screencast.com/xNlN9BMD8Emli
https://app.screencast.com/api/v1/oembed/.xml?url=https://app.screencast.com/xNlN9BMD8Emli

We are in the process of fixing an issue where the url should be encoded. So wondering if that could be the issue?

[swissspidy]

When I visit https://app.screencast.com/jRnW7zEIqmf6w/e and https://app.screencast.com/xNlN9BMD8Emli they both return a 404.

$ curl -I https://app.screencast.com/xNlN9BMD8Emli
HTTP/2 404 

That looks wrong to me.

If they'd return a proper 200 status, then the discovery & embedding will probably work.

[brhodes]

Thank you for clarifying. I'll bring this back to my team.

[brhodes]

We have fixed HEAD requests on ​https://app.screencast.com. So those links should now return 200.

I wanted to clarify that for now we do want to keep the ​https://wordpress.org/documentation/article/screencast-block/ working as is for those users of our Classic Screencast site.

So our ask is the addition of the new Screencast media.

[swissspidy]

So our ask is the addition of the new Screencast media.

We'll get there :) But first we need to ensure your oEmbed endpoint is standards-compliant. Right now this isn't the case. Once it is, it will work with WordPress out of the box.

We have a certain standard for oEmbed providers in core. In order to add a new one to the existing allow-list, they must:

1. be well-established, popular, and mainstream services,
2. properly and fully implement the oEmbed specification,
3. and clearly be a trusted provider.

Right now at least (2) is missing.

Glad you fixed the HTTP status issue, but there are more problems.

Here are some of my observations:

Issue 1: Missing oEmbed discovery tags

​https://app.screencast.com/jRnW7zEIqmf6w/e does not contain any <link> tags with oEmbed discovery markup.

Weirdly enough, ​https://app.screencast.com/xNlN9BMD8Emli does contain them.

Why is that?

If both support embedding, you should add the discovery tags to both.

Issue 2: incorrect markup

The "+" (plus sign) character in the <link> tag's type attribute is mistakenly encoded.

This is the markup you serve at ​https://app.screencast.com/xNlN9BMD8Emli:

<link rel="alternate" type="application/json&#x2B;oembed" href="https://app.screencast.com/api/v1/oembed/.json?url=https%3a%2f%2fapp.screencast.com%2fxNlN9BMD8Emli" title="(9&#x2B;) frame_08.png - TechSmith Screencast - 2024-09-10_13-46-28 oEmbed Profile" />
<link rel="alternate" type="text/xml&#x2B;oembed" href="https://app.screencast.com/api/v1/oembed/.xml?url=https%3a%2f%2fapp.screencast.com%2fxNlN9BMD8Emli" title="(9&#x2B;) frame_08.png - TechSmith Screencast - 2024-09-10_13-46-28 oEmbed Profile" />

This should be type="application/json+oembed", NOT type="application/json+oembed". Ditto for type="text/xml+oembed", which should be `type="text/xml+oembed"

According to the screenshot you shared on ​https://app.screencast.com/xNlN9BMD8Emli?conversation=zTolDBzVZxpcYJUNWHzku0, this appears to have been correct at one point but regressed.

So this needs to be fixed.

Issue 3: incorrect oEmbed response (photo vs rich)

​https://app.screencast.com/api/v1/oembed/.json?url=https%3a%2f%2fapp.screencast.com%2fxNlN9BMD8Emli returns the following response:

{
  "type": "photo",
  "version": "1.0",
  "title": "(9+) frame_08.png - TechSmith Screencast - 2024-09-10_13-46-28",
  "author_name": "Benjamin Rhodes",
  "provider_name": "TechSmith Screencast",
  "provider_url": "https://app.screencast.com",
  "width": 1434,
  "height": 70,
  "html": "<iframe scrolling='no' frameborder='0' style='width: 1434px; height: 70px; border:0;' src='https://app.screencast.com/connector/embed/index/xNlN9BMD8Emli' allowfullscreen></iframe>",
  "url": "https://app.screencast.com/xNlN9BMD8Emli",
  "thumbnail_url": "https://app.screencast.com/xNlN9BMD8Emli/thumbnail",
  "thumbnail_width": 320,
  "thumbnail_height": 180
}

According to ​https://oembed.com/, the photo type must return URL to a photo file.

However, what you are returning is an html field with an <iframe> code.

If you want to keep photo, return a proper photo URL and remove html.
If you want to return an iframe embed code in html, switch to type: rich.

Additional recommendations

Some additional things I noticed when embedding those URLs. Not blocking for this ticket but I thought I'd share it nonetheless.

• Embeds throw errors trying to set cookies when the iframe is sandboxed
• Embeds should probably have a minimum height. Embedding ​https://app.screencast.com/connector/embed/index/xNlN9BMD8Emli with a height of 70px cuts off all the emoji reactons and the Screencast logo. See ​https://i.imgur.com/OehbtFJ.png for an example.
• There are console warnings for using document.write(), which is discouraged. See ​https://developers.google.com/web/updates/2016/08/removing-document-write
• There are console warnings for non-passive event listeners, which is bad for performance. See ​https://www.chromestatus.com/feature/5745543795965952

[brhodes]

Thank you for the detailed feedback. Addressing your first issue.

Issue 1: Missing oEmbed discovery tags

The site currently expects a user to share media in two ways.
1) User shares a link to the video / image, we want them to share the view page url.

https://app.screencast.com/(media_id)

2) A user can also get an iframe markup to embed in their site from the view page. This markup uses the follow link structure in the iframe source.

https://app.screencast.com/(media_id)/e

format. We don’t expect anyone to directly share the /e url and that is why we don’t include those links in that page.

We will work on the other issues you have pointed out.

[brhodes]

How are you looking at those link tags? I just checked this out in Chrome, Safari, Firefox and Edge devtools and the encoding is all correct for me.

​https://app.screencast.com/YAdPyx6PygL6N

[swissspidy]

I'm viewing the source code directly, not in devtools. That makes a difference.

[brhodes]

We have now fixed the encoding issue with the link types and changed our images to use 'rich' type instead of 'photo'

Thank you for pointing out those issues.

[brhodes]

Hello, I'm checking in to see if there is anything else we need to do to move this forward? Thank you.

[swissspidy]

Thanks for the ping. As per my previous comment, it's important that a provider and the oEmbed API is well-established and well-documented. Right now my impression is that the endpoint is still in its infancy and not yet mature. The fact that the endpoint didn't adhere to the discovery spec until it was pointed out here confirms that.

So regarding that point, my main guidance right now is to just wait and see this become more established and robust. We can then revisit this next year or so.

Note: That's also why I recommended moving the documentation from ​https://docs.google.com/document/d/1NzamkRo1NKYc6leCuu1wvAolQAU2L4hItzPN60e-BzU/edit to a public website.

Ideally another core contributor here chimes in as well so we can hear their thoughts. (cc @azaozz @peterwilsoncc)

---

The good news is with your latest fixes the oEmbed discovery now works for your content as expected! i.e. you can drop a Screencast URL in the editor and it gets embedded.

The downside is that the embed won't load. That's because the iframe is sandboxed (since the provider isn't allowlisted yet), and you are loading some JavaScript that tries to access document.cookie. That doesn't work because of the sandboxing and results in a SecurityError

Then there are also some console warnings about the page using document.write.

You can reproduce this using the following snippet that's generated by WordPress:

<iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" title="oEmbed link type encoding" scrolling='no' frameborder='0' width='500' height='75' src='https://app.screencast.com/connector/embed/index/YAdPyx6PygL6N#?secret=66UvUE2BUq' data-secret='66UvUE2BUq'></iframe>

If your content can at least be displayed in such a sandboxed iframe, that makes it easier for everyone on the web to leverage your oEmbed endpoint and help make it more established and stable.

[brhodes]

I do want to clarify that ​https://app.screencast.com isn't a new provider, but a rewrite and migration of www.screencast.com. We expect by the end of this year all the existing users of www.screencast.com will be migrated over to ​https://app.screencast.com and the old site will be shut down next year.

We have existing customers of Classic Screencast unhappy that now they are migrated to the new Screencast their media no longer works in WordPress.

We did have some issues with how we implemented oEmbed in app.screencast.com, but depending on the tool we used to test oEmbed these tools unfurled the media even with the errors you pointed out. But I'm glad we are in a better spot with oEmbed support.

To your point about sandboxing, if I understand you correctly when ​https://app.screencast.com is on the allowlist the iframe will contain:

sandbox="allow-scripts allow-same-origin allow-presentation"

"allow-same-origin" is required for our view page to work and testing out our Screencast Classic embeds that value is added to the sandbox attribute for those media.

We do not plan on getting our media iframe embeds working without "allow-same-origin".

The last point about public api documentation, this is something I believe we can make happen.

[swissspidy]

Slight correction: sandboxing is not applied for allowlisted embeds.

[brhodes]

Thanks for the correction, but in the case of our existing www.screencast.com media it was part of those embeds from my testing today. And if the sandboxing attribute is used for app.screencast.com we would need "allow-scripts allow-same-origin" for our media to work.

[brhodes]

Just a quick update. We have moved the oEmbed api documentation to a public Github repository ​https://github.com/TechSmith/screencast-public-api-docs/blob/main/sections/oembed.md.