Responsive navigation: menu does not appear when hamburger clicked on

[bobbingwide]

Description

In Gutenberg 11.0.0 the ability to view the navigation menu when it's reduced to a hamburger menu has disappeared.

It worked in 10.9.1.

It appears that the front end script is not being loaded in 11.0.0

<script type='text/javascript' src='https://s.b/wp55/tt1/wp-content/plugins/gutenberg/build/block-library/blocks/navigation/frontend.js?ver=5.7.2' id='core_block_navigation_load_frontend_scripts-js'></script>

Step-by-step reproduction instructions

1. Using TT1 blocks Edit site and change the Navigation menu to responsive
   OR add a new Horizontal navigation menu and set Enable responsive menu toggle to on.
2. View the site and reduce the width until any responsive menu switches to a hamburger menu.
3. Try clicking on the hamburger to display the drop down menu.

Expected behaviour

Menu appears when hamburger clicks.

Actual behaviour

Menu doesn't appear.

Screenshots or screen recording (optional)

Display during step 2.

Hamburgers appears.
With 11.0.0 you can't get any further.

Expected result - with 10.9.1

Code snippet (optional)

WordPress information

• WordPress version: 5.7.2
• Gutenberg version: 11.0.0
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? TT1 blocks

Device information

• Device: Desktop
• Operating system: Windows
• Browser: Chrome Version 91.0.4472.124 (Official Build) (64-bit)

[bobbingwide]

The problem occurs in my Windows development machine.
It doesn't occur on my Linux hosted servers where the JavaScript seems to be different.

<script type='text/javascript' src='https://cwiccer.com/wp-content/plugins/gutenberg/build/block-library/blocks/navigation/view.min.js?ver=5.7.2' id='wp-block-navigation-view-js'></script>

This is defined in block.json

"viewScript": "file:./view.min.js",

[bobbingwide]

It's a problem with Windows directory separators in gutenberg_block_type_metadata_view_script()
For the core/navigation block $metadata['file'] is
C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks/navigation/block.json"

gutenberg_dir_path() returns C:\apache\htdocs\wp55\wp-content\plugins\gutenberg/

strpos( $metadata['file'], gutenberg_dir_path() ) is false, not zero, so the script isn't enqueued.

Disabling the test, the enqueued script is

<script type='text/javascript' 
src='https://s.b/wp55/thisis/wp-content/plugins/gutenberg/C:/apache/htdocs/wp55/wp-content/plugins/gutenberg/build/block-library/blocks/navigation/view.min.js?ver=5.7.2' id='wp-block-navigation-view-js'></script>

https://s.b/wp55/written/wp-content/plugins/gutenberg/C:/apache/htdocs/wp55/wp-content/plugins/gutenberg/build/block-library/blocks/navigation/view.min.js?ver=5.7.2

[bobbingwide]

Possible fix

Change gutenberg_dir_path() to call wp_normalize_path().
For this scenario it would return C:/apache/htdocs/wp55/wp-content/plugins/gutenberg/

Also wrap $metdata['file'] and $view_script_path with wp_normalize_path()
for the strpos() and str_replace() calls involving gutenberg_dir_path().

C:\apache\htdocs\wp55\wp-content\plugins\gutenberg>git diff -w lib/compat/wordpress-5.8/blocks.php
diff --git a/lib/compat/wordpress-5.8/blocks.php b/lib/compat/wordpress-5.8/blocks.php
index 54a9864a..528d5d12 100644
--- a/lib/compat/wordpress-5.8/blocks.php
+++ b/lib/compat/wordpress-5.8/blocks.php
@@ -23,12 +23,13 @@ function gutenberg_block_type_metadata_view_script( $settings, $metadata ) {
                ! isset( $metadata['viewScript'] ) ||
                ! empty( $settings['view_script'] ) ||
                ! isset( $metadata['file'] ) ||
-               strpos( $metadata['file'], gutenberg_dir_path() ) !== 0
+               strpos( wp_normalize_path( $metadata['file'] ), gutenberg_dir_path() ) !== 0
        ) {
            return $settings;
        }

        $view_script_path = realpath( dirname( $metadata['file'] ) . '/' . remove_block_asset_path_prefix( $metadata['viewScript'] ) );
+
        if ( file_exists( $view_script_path ) ) {
                $view_script_handle = str_replace( 'core/', 'wp-block-', $metadata['name'] ) . '-view';
                wp_deregister_script( $view_script_handle );
@@ -41,7 +42,7 @@ function gutenberg_block_type_metadata_view_script( $settings, $metadata ) {

                $result = wp_register_script(
                        $view_script_handle,
-                       gutenberg_url( str_replace( gutenberg_dir_path(), '', $view_script_path ) ),
+                       gutenberg_url( str_replace( gutenberg_dir_path(), '', wp_normalize_path( $view_script_path)  ) ),
                        $view_script_dependencies,
                        $view_script_version,
                        true

This should resolve the problem with the hamburger menu not appearing and
also problems with the file block in a Windows environment.

[annezazu]

cc @jasmussen as a heads up in case you can replicate this/have more context!

[jasmussen]

Thank you for the ping Anne. @vcanales does this ring any bells?

[vcanales]

This happens because TT1-blocks loads scripts before the body in the DOM, which means that when the responsive menu initialization was ran, it couldn't find any menus. Fixed here.

This does bring up an interesting question about lazy loading; it would be necessary to load any lazily loaded menus in this manner as well. Something to keep in mind for the future.

[vcanales]

Something else to note is that the error may have been caused by failures to load the file in earlier versions, but that has been handled.

[chthonic-ds]

I can confirm I'm seeing the same issue in a Windows environment. I didn't realise there was supposed to be a front-end script for the navigation toggle, so my theme has been supplying its own solution. Testing now in a Linux environment, I see view.min.js is present.

WordPress 5.8.1
Gutenberg 11.4.1

[bobbingwide]

I've got the same symptoms again with WordPress 6.1 and Gutenberg 14.4.0 & 14.5.0.
Clicking on the hamburger menu does nothing in a Windows local development environment.
Clicking on the hamburger menu works for sites hosted on Linux.
Currently investigating as bobbingwide/written#19

[paaljoachim]

Reopening isse as @bobbingwide Herb reported that the problem has showed up again in Gutenberg 14.5.0 and WordPress 6.1 in a Windows environment.

[bobbingwide]

Problem reproduced today with TwentyTwenty-Three.
Neither /navigation/view.min.js nor navigation/view-modal.min.js are being enqueued.

[t-hamano]

I also tested it in a local environment on a Windows OS.
In my case, when I activate the Gutenberg plugin, only view-modal.min.js is not enqueued.

• OS: Windows 11
• WordPress Version: 6.1
• Gutenberg Plugin Version: 14.5.0
• Theme: Twenty Twenty Three

Without Gutenberg Plugin

With Gutenberg Plugin

[t-hamano]

I have identified the cause of the problem.
As you can see from this comment, in places the path separator characters did not match.
I will submit a PR in the near future.

[bobbingwide]

@t-hamano thanks for the confirmation.

I've proposed a new fix in bobbingwide/written#19 (comment)
It's not quite the same problem as in my original quick fix.
I found I needed to use wp_normalize_path() more than before.
Would you care to try it? I don't have the capability to create a PR right now.

[t-hamano]

@bobbingwide
Thanks for the detailed analysis!
I am about to write a description of #45773 and am making almost the exact same changes you suggested.

[vcanales]

Thanks for looking into this! I'll be around to review :)

[t-hamano]

@bobbingwide @vcanales

The PR #45773 is ready. If you can test this PR in a Windows environment, I would be glad to have you review it.

[draganescu]

Closed by #45773