Skip to content

Quirks with Whimsical Custom Frames #148

@humanpurrito

Description

@humanpurrito

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 urlSuffix was not entered in quotation marks
  • Tried Custom Frames 2.4.7 to check if urlSuffix handling would make a difference, but still got the same error with and without leading slash on the urlSuffix
  • 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:

Image

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/THRcVYKd5QK2me8s7N1NnY creates the expected embed view, which matches the view when pasting the link into the browser. Pictured below:
    Image
  • Creating a base Whimsical Custom Frame (https://whimsical.com/) and using the urlSuffix (embed/THRcVYKd5QK2me8s7N1NnY or /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:
    Image

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/embed as the URL then THRcVYKd5QK2me8s7N1NnY or /THRcVYKd5QK2me8s7N1NnY work as urlSuffixes and everything works as intended!
  • But if I set the base frame to https://whimsical.com/embed/ it doesn't work with either urlSuffix.

Working solution for displaying Whimsical Embed views in Custom Frames

  • Creating a Custom Frame with https://whimsical.com/embed as the base URL (but NOT https://whimsical.com/embed/) will allow you to use urlSuffix to get a Whimsical board embed view, with or without a preceding /.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions