Block Visibility: remove stale toolbar icon when block is shown again

[Mustafabharmal]

What?

Fixes a UI state bug where the Block Visibility icon in the block toolbar remained visible after visibility settings were cleared and the block became visible again.

Fixes #77237.

Why?

The issue reported that:

1. Hiding a block correctly shows visibility indicators.
2. Showing the same block again removes the List View indicator.
3. The toolbar indicator incorrectly remains visible.

This creates inconsistent UI feedback and can confuse users about the actual visibility state.

How?

1. Updated toolbar rendering logic in viewport-toolbar.js to remove stale latched state.
2. Kept focus-safe behavior by retaining the button only while the visibility modal is open for the same block selection.
3. Added regression tests in packages/block-editor/src/components/block-visibility/test/viewport-toolbar.js to verify:

• the icon is removed after hidden -> visible transition when modal is closed
• the icon remains while modal is open

Testing Instructions

1. Open the editor and select a block with visibility support.
2. Hide the block via block visibility controls.
3. Confirm the visibility icon appears in List View and in toolbar.
4. Show the same block again.
5. Close the visibility modal.
6. Confirm both indicators are removed.

Screenshots or screencast

Before:

Before.hide.icon.fix.mov

After:

after.hide.icon.fix.mov

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Focus] Accessibility (a11y), [Status] Blocked, [Package] Block editor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mustafabharmal <mustafabharmal@git.wordpress.org>
Co-authored-by: pbiron <pbiron@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

Thanks for the PR!

I agree that the current behavior is inconsistent, but it is intentional to prevent focus loss. Please refer to this comment:

gutenberg/packages/block-editor/src/components/block-visibility/viewport-toolbar.js

Lines 42 to 48 in c718e13

	/*
	* If the block visibility button has been shown, we don't want to
	* remove it from the toolbar until the toolbar is rendered again
	* without it. Removing it beforehand can cause focus loss issues.
	* It needs to return focus from whence it came, and to do that,
	* we need to leave the button in the toolbar.
	*/

This PR will cause a focus loss with the following operations. Use only the keyboard for all operations.

• Insert a block.
• Hide the block.
• The visibility button appears in the block toolbar.
• Clicking the visibility button to open the "Hide blocks" modal.
• Change the block to a visible state.
• The visibility button in the block toolbar disappears, causing focus to be lost.

df886d3d2e7ceab38b0f20be1f472254.mp4

When a popover is closed, focus should generally return to the element that triggered it.

Let's discuss what the ideal behavior is before moving forward with this PR.