Support prompt() and confirm() in preview pane

[ericandrewlewis]

Calls to window.prompt or window.confirm don't execute in the preview pane, and trigger this message in the console:

Ignored call to 'confirm()'. The document is sandboxed, and the 'allow-modals' keyword is not set.

[ericandrewlewis]

Adding allow-modals to the iframe's sandbox attribute would allow confirm() to run. Not sure about prompt().

[outoftime]

@ericandrewlewis this is more or less intentional—we don’t want to allow blocking pop-ups because of the live preview-as-you-type functionality. That’s why we override alert() to use a non-blocking SweetAlert when you’re in the preview.

@alexpelan I know we did some discussion of doing something clever prompt() and confirm() as well, particularly taking advantage of prompt() taking a second default argument. Any recollection of where that ended up?

[alexpelan]

We decided the SweetAlert wasn't particularly well suited for prompt - you can define a callback to run after the user presses okay, but there's no way to make it synchronously block like prompt() actually does in the browser, so we just swallow it (and return the second parameter so that we don't cause syntax errors if we reference the result of the prompt later on): https://github.com/popcodeorg/popcode/commit/31f069037f4bdb70b1c0420195971b4d25efc942

confirm() would be an easy fix for sweetalert - for confirms we would just have to pass sweetalert the showCancelButton argument as true.

[outoftime]

@alexpelan quite! somehow looking at the code in generatePreview yesterday I completely missed the fact that we’re defining prompt() too.

Good point about using SweetAlert for confirm()—of course we’d have to hard-code the outcome (probably true). Is it too weird to have a confirmation prompt on the screen when the code that is supposedly waiting for the response to that prompt has already executed? (I suppose that question applies equally to prompt() as implemented today)

Interested to hear your thoughts @ericandrewlewis