iframe not working for some websites

[jsmorabito]

iframe working for:

• Todoist - {{iframe: https://todoist.com/app/today#}}
• Whimsical - {{iframe: https://whimsical.com/embed/K638EURkPFZjuzCDUZWtaw}}. It only works by copying the src but not the whole iframe
• Google calendar embed works if the calendar is available to public e.g. athensresearch google calendar {{iframe: https://calendar.google.com/calendar/embed?src=researchathens%40gmail.com}}

iframe not working for:

• twitter
• lucidchart
• miro
• figma
• youtube

[juniusfree]

Working:

• Todoist - {{iframe: https://todoist.com/app/today#}}
• Whimsical - {{iframe: https://whimsical.com/embed/K638EURkPFZjuzCDUZWtaw}}. It only works by copying the src but not the whole iframe

[juniusfree]

for google calendar https://discord.com/channels/708122962422792194/802652338619285594/831006411436589097

[jsmorabito]

thanks @juniusfree added these

[shanberg]

I imagine several of the not-working embedees don't actually want their stuff embedded in iframes, and that's why they provide things like publish/embed tools.

Twitter and LucidCharts look like likely cases of this.

[sid597]

@jsmorabito @shanberg Should this be closed? It makes sense what Stuart said, do we need more research on this to know if this is an issue and is solvable?

[shanberg]

@jsmorabito @shanberg Should this be closed? It makes sense what Stuart said, do we need more research on this to know if this is an issue and is solvable?

I think this is a separate issue, but there may be value in detecting whether embedding is allowed, and notifying users when it’s not supported for a given site. https://forums.asp.net/t/1902788.aspx?How+can+i+detect+if+iframe+source+url+can+be+loaded+or+not+

[dragonman225]

@jsmorabito @shanberg @sid597 I would like to share some of my findings here. Recently, I encountered the same issue when I was implementing an embed feature for an Electron app, and I searched across Github and StackOverflow to see how others solve it.

A short answer: if we want to fix it in an Electron app, it's possible. The simplest solution is to intercept Web requests with the WebRequest API, to add request headers that make embed work (e.g. referer is required for some YouTube videos), or remove response headers that prevent embed to work (e.g. x-frame-options, content-security-policy). [reference]

---

But beyond just "fixing it", there're some philosophic questions worth think about:

First, doesn't modifying headers seem like breaking the protocol? The answer can be yes, if you view the act of embed as "embedding a third-party resource" and you want follow the standard rules of <iframe>. But it can also be no, if you view the act of embed as "having a window showing a webpage like a browser", and you're just using <iframe> and Electron as technologies to create a solution.

Second, what do the users want? Could the users distinguish the concept of embedding a webpage from browsing a webpage? Or people just want to have a webpage appear inside a box along with their notes? If this is the case, then there's also BrowserView, which is like a full-blown browser window that can display anything without restrictions (but harder to deal with).

Sorry for the long and opinionated response! But I hope it'll help you make further steps. 😅

[shanberg]

@dragonman225 BrowserView is interesting, but I agree it looks way harder to deal with.

I'm getting the sense the best approach is a balance between natural user expectations (I have the url, why shouldn't I be able to embed it?) and in slightly enhancing the default capabilities to meet those expecations, within reason.

For instance, features like referrer might mean we should notify people that e.g. YouTube can track where the video is being embedded from.