-
-
Notifications
You must be signed in to change notification settings - Fork 40
Description
Raising as an issue (3 months later 😅) as requested in a Discord conversation that can be found here.
It seems that the Whimsical (https://whimsical.com) and Custom Frames have a few quirks when in combination. I've recapped the original issue and solution from 3 months ago, but I uncovered more information about the quirks and found a working solution to my problem while I was writing this up, which I've laid out below.
The original issue
Couldn't seem to be able to get Whimsical embeds to work using the urlSuffix feature of a Custom Frames (base URL as https://whimsical.com/). We landed on using the whole URL in a Custom Frame, and therefore generating a new Custom Frame for each unique Whimsical.
What we tried/identified 3 months ago:
- The URL Suffix with and without a leading slash (
/embed/[string]) - The main page works as a CustomFrame works and it's possible to log in
- Established that the board identifiers are just numbers and letters (no odd characters)
- Enabled Obsidian Web Viewer, disabled iframe mode from testing which got a successful Whimsical login in Custom Frames
- Checked Dev tools - no red boxes for Custom Frames, but 403 errors for Whimsical's whimsical.com/api/items.get:1
- Embedding the main page as a Custom Frame and locating to the desired link worked
- Established that the
urlSuffixwas not entered in quotation marks - Tried Custom Frames 2.4.7 to check if
urlSuffixhandling would make a difference, but still got the same error with and without leading slash on theurlSuffix - Settled on using each URL as a Custom Frame for now
- This was all on a Windows laptop, the most recent Obsidian version at the time which would have been 1.8.7
However when I went to recreate the problem to grab the console output for this issue, the old base Whimsical Custom Frame (URL as https://whimsical.com) + urlSuffix had started working but not as intended.
After some experimentation I think I identified the quirk that was causing the problems and one or two others. Follow up findings reported in the Discord here, more detail below:
Console Output
Running pre-existing Custom Frames, and creating and embedding a Custom Frame using the full embed link did not generate any issues in the console, but creating and embedding one using a base Whimsical Custom Frame (https://whimsical.com) and the urlSuffix /embed/THRcVYKd5QK2me8s7N1NnY generated this in the console:
This is on Obsidian 1.9.1 but still with Custom Frames 2.5. On Mac OS 12.7.6 (the original troubleshooting happened on Windows but I no longer have access to that computer).
Base frames not working as intended
Whimsical generates a specific embed link that displays differently to the editing window - without the editing toolbars and the frame doesn't autoscroll when scrolling on a page it's embedded on.
I've made a test board for your own experimentation, here: https://whimsical.com/embed/THRcVYKd5QK2me8s7N1NnY
This board is public, but the ones I was testing on were private, and I was using Custom Frames to stay logged in.
- Creating a Whimsical Custom Frame with the entire link
https://whimsical.com/embed/THRcVYKd5QK2me8s7N1NnYcreates the expected embed view, which matches the view when pasting the link into the browser. Pictured below:

- Creating a base Whimsical Custom Frame (
https://whimsical.com/) and using theurlSuffix(embed/THRcVYKd5QK2me8s7N1NnYor/embed/THRcVYKd5QK2me8s7N1NnY) creates an embed that looks like the public view if not logged in, or the editing view logged in with the Whimsical toolbars and menus in place, and the frame scrolls as I scroll down the page. Recreating this with the example link should give you the public view which looks like the image below:

The embed link and the editing link are not similar, but I have since found that a Whimsical embed link without the /embed portion redirects to the editing view. I think this means that the /embed portion is being removed from the urlSuffix as the link is parsed in Custom Frames. I'm assuming the redirect is a recent addition and that's why the base Whimsical frame suddenly started 'working'.
I tested a couple more orientations and found:
- Creating a Custom Frame with
https://whimsical.com/embedas the URL thenTHRcVYKd5QK2me8s7N1NnYor/THRcVYKd5QK2me8s7N1NnYwork asurlSuffixes and everything works as intended! - But if I set the base frame to
https://whimsical.com/embed/it doesn't work with eitherurlSuffix.
Working solution for displaying Whimsical Embed views in Custom Frames
- Creating a Custom Frame with
https://whimsical.com/embedas the base URL (but NOThttps://whimsical.com/embed/) will allow you to useurlSuffixto get a Whimsical board embed view, with or without a preceding/.
