Snackbar: Display Snackbar on top of Modal Screen Overlay

[yogeshbhutkar]

Description

The z-index of the snackbar component currently matches that of the modal screen overlay:

gutenberg/packages/base-styles/_z-index.scss

Lines 113 to 117 in 064b879

	// Show snackbars above everything (similar to popovers)
	".components-snackbar-list": 100000,
	// Show modal under the wp-admin menus and the popover
	".components-modal__screen-overlay": 100000,

As a result, the snackbar is rendered behind the modal overlay. Since snackbars provide critical feedback for user actions, they should ideally appear above the modal overlay to ensure their visibility.

For example, when inserting a Pattern through the Explore all patterns modal, selecting a pattern successfully adds it to the post content and triggers a snackbar notification. However, because the snackbar is hidden behind the modal overlay, users cannot see the feedback. This behavior does not provide proper feedback to the user and forces them to close the modal to confirm the action manually.

This behavior is demonstrated more clearly in the attached video.

Step-by-step reproduction instructions

1. Navigate to the post edit screen.
2. Open the Block Inserter.
3. Navigate to the Patterns tab and open the Explore all patterns dialog.
4. Try selecting a Pattern from the Dialog.
5. Notice the snackbar got generated behind the Dialog.

Screenshots, screen recording, code snippet

issue.mov

Environment info

• WordPress Version: 6.8-alpha-59361
• Gutenberg Version: Trunk (5688333)
• OS: macOS Sequoia

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Mamaduka]

The current behavior might be intentional. When a modal dialog is open, the content behind it should be inert. Additionally, clicking on a "Snackbar" to dismiss will cause the modal to close, which I think isn't ideal behavior.

cc @t-hamano, @afercia

[yogeshbhutkar]

Displaying the snackbar behind the modal overlay may prevent users from receiving the intended feedback after inserting a pattern.

Additionally, clicking on a "Snackbar" to dismiss will cause the modal to close, which I think isn't ideal behavior.

If the snackbar is positioned behind the modal, wouldn’t attempting to interact with anything behind the modal naturally result in the modal closing?

[Mamaduka]

If the snackbar is positioned behind the modal, wouldn’t attempting to interact with anything behind the modal naturally result in the modal closing?

In normal flow, you just dismiss "Snackbar" and continue doing what you did. But with the modal, you'll have to re-open it, which could be inconvenient.

I don't have an answer to what's the best UX here; this is why I requested additional feedback before we try to solve anything.

[t-hamano]

When a modal dialog is open, the content behind it should be inert.

Given this, maybe the snackbar isn't the right choice.

Instead, should we show the notification inside a modal, like the font library modal?

Or, if the modal was to be closed when the pattern was inserted, the current snackbar would make sense.

When the pattern modal was first implemented, it seemed to close the modal when the pattern was inserted (see the video attached to #35773). It might be a good idea to first look into when and why this behavior was changed.

[afercia]

When the pattern modal was first implemented, it seemed to close the modal when the pattern was inserted (see the video attached to #35773). It might be a good idea to first look into when and why this behavior was changed.

I'd agree this should be investigated to understand what the reasoning behind the change was.
A modal dialog is supposed to prevent interaction with the rest of the page. That's why it is qualified as modal (which is a behavior, not a name). Either the snackbar should not be used in this case or the modal dialog behavior should be reconsidered.

Edit: In WordPress 6.6 the Patterns explorer modal dialog closes when inserting a pattern so the change in behavior must be pretty recent.

[afercia]

Raising this issue to Regression as the reported bug introduces a significant problem for keyboard interaction.

In fact, when using the keyboard and inserting a pattern from the modal dialog, the dialog stays open and focus moves to the inserted pattern in the editor canvas. As such, focus is outside the modal dialog, which is something that should never happen.

I do realize that when using the mouse this regression isn't immediately clear but this only proves that whatever the change that introduced this bug is, it hasn't been tested sufficiently with keyboard. This is far from ideal as largely untested changes keep being introduced in the UI often breaking basic interaction flows.
I'd greatly appreciate more caution when changing anything related to the UI and more importatnly I'd appreciate better testing. Cc @WordPress/gutenberg-core

To reproduce.

• Open the pattern explorer modal dialog.
• Use the keyboard to navigate to the list of patterns within the modal dialog.
• Once on the first pattern, you can use the arrow keys to navigate the patterns.
• Press Enter on a pattern of your choice.
• The pattern gets inserted in the editor. Observe the focus style around the pattern you selected disappears.
• Press the Tab key a couple times.
• Observe focus is on the 'Close Settings' button in the inspector, outside of the modal dialog.

Screenshot:

I'll update this issue title for better clarity.

Wondering whether we should close this issue and create a new one to report the root cause of the bug: the modal dialog should close.

[t-hamano]

When the pattern modal was first implemented, it seemed to close the modal when the pattern was inserted (see the video attached to #35773). It might be a good idea to first look into when and why this behavior was changed.

I would like to investigate this point first.

[t-hamano]

I identified this behavior as being changed in #63059.

The discussion in #61051 was about whether to keep the sidebar inserter open or not. It seems that they ultimately agreed on a policy of not closing the sidebar inserter when clicking on the canvas.

However, there was no mention of the Pattern Explorer modal, so the current behavior may not be what was intended.

Perhaps we need to decide which is the ideal behavior for the pattern explorer modal.

When we click on a pattern in the pattern explorer modal:

• Close the modal. Show a snackbar. Focus the inserted pattern.
• Don't close the modal. Notify in some way instead of a snackbar. Don't focus the inserted pattern.