Problem/Motivation

The shortcuts links are rendered via a placeholder (and hence bigpipe), which is good.

However due to the &nsbbp; placeholder the parent link pops in after the page is loaded. Because it is generally quite high above the fold, this can be quite obvious.

Steps to reproduce

Proposed resolution

Can we just render the shortcuts top level link as a placeholder? This doesn't need any special caching and it means there is no visual effect when the placeholder/lazy builder is replaced.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3493410

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

catch created an issue. See original summary.

catch’s picture

Status: Active » Needs review
Issue tags: +Performance

catch’s picture

Not a direct result, but this was found while working on #3491405: Add performance testing.

plopesc made their first commit to this issue’s fork.

plopesc’s picture

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 these concerns still valid and should we think in a different approach for this MR?

catch’s picture

Issue tags: +Needs manual testing

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.

smustgrave’s picture

Status: Needs review » Needs work
StatusFileSize
new6.35 MB
new5.57 MB

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

catch’s picture

Status: Needs work » Needs review

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.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs manual testing
StatusFileSize
new4.56 MB

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

catch’s picture

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.

#3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe 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.

quietone’s picture

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

nod_’s picture

Status: Reviewed & tested by the community » Needs work

Merge conflict

plopesc’s picture

Status: Needs work » Reviewed & tested by the community

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

nod_’s picture

Status: Reviewed & tested by the community » Fixed

Committed a9ebc0c and pushed to 11.x. Thanks!

  • nod_ committed a9ebc0c6 on 11.x
    Issue #3493410 by catch, plopesc, smustgrave: Consider a more...

nod_’s picture

Version: 11.x-dev » 11.1.x-dev
Status: Fixed » Patch (to be ported)

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

  • nod_ committed bc08b608 on 11.1.x
    Issue #3493410 by plopesc, catch, smustgrave: Consider a more...
nod_’s picture

Status: Patch (to be ported) » Fixed

Committed bc08b60 and pushed to 11.1.x. Thanks!

Status: Fixed » Closed (fixed)

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