Consider a more substantial shortcuts placeholder

Not a direct result, but this was found while working on 📌 Add performance testing Active .

After checking the MR I realized the resultant code was very similar to the original one we had in Navigation before merging it into core.

There were concerns about this approach expressed in a MR comment that were addressed in the following commit.

Are this concerns still valid and should we think in a different approach for this MR?

So this is what I was worried about in that MR comment:

  '#lazy_builder' => ['navigation.user_lazy_builder:renderNavigationLinks', []],
      '#create_placeholder' => TRUE,
      '#cache' => [
        'keys' => ['user_set_navigation_links'],
        'contexts' => ['user'],
      ],

e.g. the cache context for the placeholder itself was user-specific (I think to show the username). In the shortcuts case, we can always show 'Shortcuts' there, so it's the same for everyone and won't affect cache granularity.

I did have a vague memory of that MR too and kept thinking I was missing something here while working on this, but so far it seems like for the shortcuts link it's always going to be the same for everyone. This might need some before/after manual testing when a user doesn't have access to shortcuts but does have access to navigation, or when their shortcuts are completely empty? But from reading the code if there's an issue with that it might be pre-existing.

Attaching before/after screenshots. Per slack this is seen when clearing cache but you can see even after the cache clear and MR applied the shortcut link block still flickers.

Let know if I tested wrong

I think you tested right and found a bug.

The placeholder markup looks like this:

<button data-component-id="navigation:toolbar-button" data-index-text="s" data-icon-text="Sh" class="toolbar-button toolbar-button--icon--shortcuts toolbar-button--expand--side toolbar-button--collapsible invisible toolbar-popover__control">
                                <span class="toolbar-button__label" data-toolbar-text="">Shortcuts</span>
                            </button>

This doesn't get rendered at all.

The replaced markup looks like this:

<button aria-expanded="false" aria-controls="navigation-link---2" data-toolbar-popover-control="" data-has-safe-triangle="" data-component-id="navigation:toolbar-button" data-index-text="s" data-icon-text="Sh" class="toolbar-button toolbar-button--icon--shortcuts toolbar-button--expand--side toolbar-button--collapsible toolbar-popover__control" data-once="safe-triangle" style="--safe-triangle-cursor-x: 73px; --safe-triangle-cursor-y: 94px;">
      <span data-toolbar-action="" class="visually-hidden">Extend</span>
              <span class="toolbar-button__label" data-toolbar-text="">Shortcuts</span>
      
<div data-safe-triangle=""></div></button>

The placeholder markup had the 'invisible' class, grepped for that, found a template and hook_theme() template that needed deleting outright.

For me it actually works now.

The block no longer appears to flicker. I do see the arrow flicker but imagine that's a separate issue.

Yeah that's trickier, we'd have to fake having some shortcuts items for that. It is probably doable, but not by me in the ten minutes I just spent trying to get it to work.

📌 Render the navigation toolbar in a placeholder Active should help with this issue generically - if we make the shortcut block placeholder content render cacheable (it already might be), then on cache hits, bigpipe wouldn't be involved in rendering it at all, so zero flicker when browsing around with a warm navigation cache then.

I read the IS and the comments. I didn't find any unanswered questions or other work to do. Updating credit.

Merge conflict

Conflicts solved and tests are still green. Moving back to RTBC.

Committed a9ebc0c and pushed to 11.x. Thanks!

nod_ → closed merge request !10532

we might want that for 11.1.x too, cherry pick isn't clean

nod_ → closed merge request !11025

Committed bc08b60 and pushed to 11.1.x. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.