Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preferences: The back button in the preferences modal doesn't appear to work #65109

Closed
2 tasks done
andrewserong opened this issue Sep 6, 2024 · 6 comments · Fixed by #65141
Closed
2 tasks done

Preferences: The back button in the preferences modal doesn't appear to work #65109

andrewserong opened this issue Sep 6, 2024 · 6 comments · Fixed by #65141
Assignees
Labels
[Package] Preferences /packages/preferences [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@andrewserong
Copy link
Contributor

Description

While testing on a narrower viewport, I noticed that the back button in the Preferences modal doesn't appear to work. Tapping / clicking the button doesn't appear to get the user back to the top level of the hierarchy.

Step-by-step reproduction instructions

  1. Open the page editor in a narrower viewport
  2. Open the block editor settings / preferences
  3. Go to one of the sections
  4. Press the back button within the modal
  5. Notice that it doesn't do anything

Screenshots, screen recording, code snippet

2024-09-06.16.17.26.mp4

Environment info

  • GB Trunk

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
@t-hamano
Copy link
Contributor

t-hamano commented Sep 8, 2024

The preferences modal navigation in the mobile layout is implemented here. I then identified that this problem was caused by #63317.

After a bit of research, it seems that the issue can be resolved by explicitly adding slashes to the path prop of the NavigatorButton and NavigatorScreen components:

diff --git a/packages/preferences/src/components/preferences-modal-tabs/index.js b/packages/preferences/src/components/preferences-modal-tabs/index.js
index f70430367c..d87e565f5e 100644
--- a/packages/preferences/src/components/preferences-modal-tabs/index.js
+++ b/packages/preferences/src/components/preferences-modal-tabs/index.js
@@ -110,7 +110,7 @@ export default function PreferencesModalTabs( { sections } ) {
                                                                        return (
                                                                                <NavigatorButton
                                                                                        key={ tab.name }
-                                                                                       path={ tab.name }
+                                                                                       path={ `/${ tab.name }` }
                                                                                        as={ Item }
                                                                                        isAction
                                                                                >
@@ -142,7 +142,7 @@ export default function PreferencesModalTabs( { sections } ) {
                                                return (
                                                        <NavigatorScreen
                                                                key={ `${ section.name }-menu` }
-                                                               path={ section.name }
+                                                               path={ `/${ section.name }` }
                                                        >
                                                                <Card isBorderless size="large">
                                                                        <CardHeader

Maybe it has to do with stricter pattern matching, as this comment suggests.

cc @ciampo @tyxla

@ramonjd
Copy link
Member

ramonjd commented Sep 9, 2024

Nice sleuthing @t-hamano

@andrewserong if you don't have time, I can get a quick PR up this morning

@andrewserong
Copy link
Contributor Author

@ramonjd, I'm happy to do it! I'll give you a ping when it's up 🙂

@andrewserong
Copy link
Contributor Author

Fix here: #65141 — thanks so much again @t-hamano! 🙇

@tyxla
Copy link
Member

tyxla commented Sep 9, 2024

Thank you folks 🙌

@ciampo
Copy link
Contributor

ciampo commented Sep 11, 2024

Thank you, folks! The need for a URL-like path is documented in the README, but I appreciate that it may be easily overlooked by consumers of the component. I've opened #65231 to add a runtime check, which should hopefully help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Preferences /packages/preferences [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants