Problem/Motivation

Since Drupal 10.4, we saw that the button edit icon (in top right) that allow to toggle others edit button in the page, is displayed correctly during the first browser request, then it was hidden during other page refresh

Steps to reproduce

Install drupal 10.4.8
Admin toolbar 3.x

first display: https://ibb.co/Hfxz4nwf
second display: https://ibb.co/fdwqj4v0

Proposed resolution

If I removed session storage of my user, the button is back for the new browser request and was hidden after.
I think there is a problem in session storage, introducing during the core version 10.4.x, I tested :
10.3.13 -> Ok
10.4.0 -> Nok
10.4.8 -> Nok

Disable cache didn't fix the problem, only remove session storage.

CommentFileSizeAuthor
#5 admin_toolbar.png85.81 KBzaurav

Comments

tichris59 created an issue. See original summary.

tichris59’s picture

tichris59 commented

In my case, on the page /admin/content, I if remove the key session storage:

Drupal.contextual.entity.view.edit_form:view=content:location=page&name=content&display_id=page_1&langcode=fr

fix the problem for the next reload and after the problem come back

dydave’s picture

dydave commented

This issue is starting to run a bit behind:

Could you please try upgrading to the latest admin_toolbar-3.6.3 release and let us know if the problem still occurs?

It's been almost 6 months since this issue was created and no one else seems to have encountered the same or a similar problem.

Were you able to fix the issue or find what could have caused it?

Feel free to let us know if you have any questions on this comment or this issue in general, we would certainly be very happy help.
Thanks in advance!

boddy’s picture

boddy commented

Drupal core 10.4.6 with Admin Toolbar 3.6.3 - the problem still exists
Drupal core 10.6.3 with Admin Toolbar 3.6.3 - the problem still exists
The Edit link appears once after editing and saving an entity, after refreshing the page it gets '.hidden' class for some reason.

Drupal core 11.2.9 with Admin Toolbar 3.6.2 / 3.6.3 - no problems, everything works fine

zaurav’s picture

zaurav
Primary language English
Location Oakton, VA
commented
StatusFileSize
new admin_toolbar.png85.81 KB

I don't see the edit button at all!

Drupal version : 10.6.3
PHP version : 8.4.17
Install profile : standard
Admin toolbar 3.x (f0a73d2)

Admin Toolbar works

boddy’s picture

boddy commented

It is an Edit page on the screenshot, so you shouldn't see a button.

The Edit button appears on the View entity, not in the Edit one.

sriram_s’s picture

sriram_s commented

I dug into this one and I'm fairly confident it's actually a Drupal core bug rather than an Admin Toolbar issue.

The giveaway: it still happens with Admin Toolbar completely uninstalled — just core toolbar + contextual on Drupal 10.6.12. Load a page that has contextual links and the edit toggle shows up fine; reload, and the `.contextual-toolbar-tab` picks up the `hidden` class even though the contextual links are all still there. Admin Toolbar isn't really involved — it just happens to be the toolbar everyone's looking at when the button goes missing.

Here's what's going on: the edit toggle decides whether to show itself from a `contextualCount` value in core's `Drupal.contextualToolbar.StateModel`. That count only ever updates from the contextual collection's `add`/`remove`/`reset` events — it never counts the links that are already there. On a cached load, the links get restored from sessionStorage and added to the collection before the toolbar model is set up and listening, so those `add` events fly by unheard, the count stays at 0, and the toggle stays hidden. That lines up exactly with what @tichris59 spotted in #2 — clearing that one `Drupal.contextual.entity.view.edit_form:...` key brings it back for a reload because it forces the un-cached Ajax path, which arrives late enough for the model to catch it.

And that's also why @boddy saw it working on 11.2.x — 11.x replaced this old Backbone code with `contextualToolbarModelView.js`, which counts the existing links right in its constructor. 10.4/10.5/10.6 still run the old code, so it needs a small 10.x-only fix to match what 11.x already does.

I've filed it in core with a one-line fix and a regression test: https://www.drupal.org/project/drupal/issues/3611072 (MR !16330 against 10.6.x). Might be worth closing this one out as a core bug and following along there.

Thanks @tichris59 for the original report and the sessionStorage clue — that's what made it easy to track down.