Return friendly page for missing embed slugs

[skaphan]

Summary

• When an embedded visualization URL (/ve/<slug>) references a slug that no longer exists, return a user-friendly HTML page (200) instead of Django's default 404
• This displays cleanly inside iframes, avoiding cross-origin error handling issues that make the default 404 invisible to embedding pages
• Cache-Control headers prevent the friendly page from being cached, so the real visualization appears immediately once re-created

Test plan

• Added test_embedded_404_returns_friendly_page to testSimple.py
• Verified manually: embed iframe shows friendly message instead of blank/broken page when slug is missing

🤖 Generated with Claude Code

[artoonie]

Should we still return an error code 404, even with a custom 404 page? Would that display cleanly in iframes? I fear returning a 200 OK for a nonexistent page.

[skaphan]

Hi Armin, Browsers deliberately block cross-origin error detection in iframes — the embedding page can't tell whether an iframe loaded successfully or got a 404. There's no onerror event, no way to read the response status, and even postMessage requires cooperation from the loaded page (which doesn't exist if it's a 404). So the only way to show the user a helpful message is to return it from the server as a normal 200 response. That said, I'm fine if you don't want this change, but for my local instance I will probably keep it since I don't have a persistent database and if rcvis instances come and go, I don't want users to see a sad face in the middle of the iframe with no explanation, which is the alternative. Just let me know either way, please. Shel

…

On Mar 4, 2026, at 1:09 PM, Armin Samii ***@***.***> wrote: Should we still return an error code 404, even with a custom 404 page? Would that display cleanly in iframes? I fear returning a 200 OK for a nonexistent page.

[artoonie]

I'm not sure I fully understand why returning the same content with 200 vs 404 acts any differently in an iframe. My understanding is that it will work the same way. The only differences are in how Cloudflare and crawlers treat the page. (If I return 200, that page might show up in search engines if there are broken links from other websites, for example.)

Can you test the small change I made and see if this does everything you need it to?

[skaphan]

Tested — the friendly HTML renders correctly in iframes with 404 status. You're right that the status code doesn't affect iframe rendering. Good call on using 404 for Cloudflare and crawlers. LGTM, please merge.

[artoonie]

Running Heroku CI on #606

[artoonie]

Looks like it's failing two tests:

FAIL: test_create_scrapable_page (electionpage.tests.ElectionPageTests.test_create_scrapable_page)
With proper permissions, can create a scrapable election page
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/app/electionpage/tests.py", line 228, in test_create_scrapable_page
    self.assertIsNone(submit_with_num_elections_and_get_error('2', True))
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: '' is not None

and

FAIL: test_embedded_404_returns_friendly_page (visualizer.tests.testSimple.SimpleTests.test_embedded_404_returns_friendly_page)
When an embedded visualization slug doesn't exist, return a friendly
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/app/visualizer/tests/testSimple.py", line 302, in test_embedded_404_returns_friendly_page
    self.assertEqual(response.status_code, 200)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 404 != 200

[skaphan]

Fixed the second error which was triggered by the change to returning 404 status. The first one (electionpage) appears to be unrelated. Not sure what is causing it.