Fix Share > Export as PDF doing nothing when clicked

[shangxinyu1]

Summary

In the Share menu, clicking Export as PDF does not trigger any visible action.

The user opens Share, clicks Export as PDF, and nothing appears to happen. There is no download, dialog, loading state, or error feedback.

Current behavior

• The user opens the Share menu.
• The user clicks Export as PDF.
• No visible export action starts.
• No file is downloaded or saved.
• No loading state, progress indicator, or error message is shown.
• From the user perspective, the action appears unresponsive.

Expected behavior

Clicking Export as PDF should either start the PDF export successfully or fail with clear feedback.

Suggested improvements:

• Trigger the PDF export flow immediately after the menu action is clicked.
• Show a visible loading or exporting state while the PDF is being generated.
• Provide success feedback when the export starts or completes.
• Show an explicit error message if PDF export fails.
• Prevent silent no-op behavior on export actions.

Steps to reproduce

1. Open a design in Open Design.
2. Click Share.
3. Click Export as PDF.
4. Observe that no visible action occurs.

Notes

A screenshot is attached showing the Share menu with Export as PDF highlighted in the failing flow.

Why this matters

Export is a high-intent user action. If the PDF export option appears clickable but does nothing, users cannot trust the Share workflow and may assume their work cannot be exported at all.

[lefarcen]

Root cause identified: exportAsPdf at apps/web/src/runtime/exports.ts:241 opens a new window via window.open(url, '_blank', ...). When the browser blocks the popup (line 247), it silently fails with no user-facing feedback.

Fix needed: Add error handling when win is null — either:

1. Show a toast/error message telling the user to allow popups, OR
2. Fall back to a download-style PDF export (though browser print dialog won't work in that case)

Related: This is similar to the PPTX export issue in #60 (also by you) where Export actions don't give clear feedback on failure.

[lefarcen]

This looks like a good first issue for someone new to the project.

If you'd like to work on it, comment /claim below. The first /claim after the latest release gets it. Any comment, linked PR, or progress note keeps the claim active.

[PratikRai0101]

/claim

[lefarcen]

Claimed by @PratikRai0101. Thanks for picking this up.

A rough ETA helps us know when to check in, but it is optional. Any comment, linked PR, or progress note will keep the claim active.

[lefarcen]

Linked PR opened: #676

Root cause identified: the popup blocker check in apps/web/src/runtime/exports.ts had an empty handler (if (!win) { /* empty */ }). When window.open returned null due to browser popup blocking, execution silently continued without user feedback.

The fix adds an explicit alert notifying the user to allow popups, plus an early return to halt execution cleanly.

Implementation and review are being tracked in #676. This issue stays open until the fix lands and the author validates the resolution.

[lefarcen]

Hi @PratikRai0101, quick check-in. Are you still working on this? Any comment, question, or linked PR is enough signal; we will wait another 8 hours.

[PratikRai0101]

hey @lefarcen yes I have pushed the required fix and there aren't any blocking changes, the fix here is complete, let me know if any changes are required!

[lefarcen]

Thanks @PratikRai0101! 🎉

Your fix is being tracked in PR #676. The PR implements the alert-based approach we discussed — detecting when window.open returns null and showing a clear message to the user.

Keeping this issue open until #676 is reviewed and merged.