Gutenberg: Consider replacing usages of Window.confirm() with Modal

Created on 15 Jul 2019  路  4Comments  路  Source: WordPress/gutenberg

We're currently using Window.confirm() in four places. This isn't an ideal experience as we're unable to customise the OK button to have a more descriptive label.

Moving these instances to use a Modal component might provide a better experience. Here's an example of a Modal being used this way, from @kjellr's mockup in https://github.com/WordPress/gutenberg/issues/16315#issuecomment-507331101:

Screen Shot 2019-07-15 at 16 03 13


1. Switching a published post to draft

Current:

Screen Shot 2019-07-15 at 15 57 17

Proposed:

Switch to Draft

Are you sure you want to unpublish this post?

[ Cancel ] [ Unpublish ]

2. Switching a published post to private

Current:

Screen Shot 2019-07-15 at 15 57 42

Proposed:

Privately Publish

Are you sure you want to privately publish this post now?

[ Cancel ] [ Privately Publish ]

3. Deleting a reusable block

Current:

Screen Shot 2019-07-15 at 15 58 12

Proposed:

Delete Reusable Block

Are you sure you want to delete this Reusable Block? 

It will be permanently removed from all posts and pages that use it.

[ Cancel ] [ Delete ]

4. Pressing _Reset the template_ when template doesn't match post content

Current:

Screen Shot 2019-07-15 at 15 59 21

Proposed:

Reset Template

Resetting the template may result in loss of content, do you want to continue?

[ Cancel ] [ Reset Template ]
General Interface Needs Accessibility Feedback [Type] Enhancement

Most helpful comment

This is technically impossible to implement, at least for the confirmations shown on beforeunload (i.e. the unsaved changes prompt when reloading or navigating away). The browser does not give you an opportunity to prevent navigation except by the standard prompts.

All 4 comments

Do we currently use modals as a stand-in for standard alerts elsewhere? I do find modals like the one pictured to be a little less alarming than the standard browser one, but I'm definitely be curious about any a11y considerations for this.

This is technically impossible to implement, at least for the confirmations shown on beforeunload (i.e. the unsaved changes prompt when reloading or navigating away). The browser does not give you an opportunity to prevent navigation except by the standard prompts.

@aduth: None of the confirm()s shown above are triggered when reloading or navigating away 馃檪

@aduth: None of the confirm()s shown above are triggered when reloading or navigating away 馃檪

You're totally right! I skimmed the text of the last screenshot and the "result in content loss" had me jump the gun on assuming that's what we were discussing.

For the ones which don't involve navigation, it's totally possible to re-style. I guess it's worth clarifying at least that it _cannot_ be applied for the prompt which asks the user to confirm unsaved changes before navigating away or refreshing a "dirty" post.

Was this page helpful?
0 / 5 - 0 ratings