Sticky shadow position without toolbar

Hi @kksandr Can you add steps to reproduce this issue along with screenshots to understand it clearly?

We are facing the same issue for users without access to the toolbar but with access to the admin theme.

Here is a screenshot of the result :

To reproduce, simply give access to the admin theme without access to the toolbar.

Thanks for looking into this.

@LeDucDuBleuet I could replicate the issue and created a patch to fix it.

@swatidhurandhar Thank you very much, we're getting there!

Now with this patch, the header does not get cut off and shows correctly but the sticky shadow is still too low as you can see in this screenshot :

This theme attaches conditionally attaches styles that define toolbar variables depending on the toolbar type setting.

The problem was that the styles are attached in the page prequery, that is, they are always attached.
I moved this to the toolbar preprocessing, now the styles for the toolbar are not attached at all if the toolbar is not rendered, so the toolbar height variable will be 0. Changes in the merge request.

@kksandr This sounds great but I am not able to apply the patch from the MR like I usually do with other modules.

In my composer.json I put :

            "drupal/gin": {
                "Issue 3403123 Sticky shadow position without toolbar":"https://git.drupalcode.org/project/gin/-/merge_requests/340.diff"
            },

I run :

composer update --prefer-source drupal/gin

And I get the following error:

Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/gin/-/merge_requests/340.diff

Am I doing something wrong?

Or could you provide a standard patch here that I could include more easily in my composer.json please?

Thanks!

You need to use the .patch extension: https://git.drupalcode.org/project/gin/-/merge_requests/340.patch

Ok the dev version did the trick, now the patch applies cleanly with the .diff extension and the .patch extension as well.

Now the shadow sits where it should but the header is not sticky anymore and we loose the right column content.

Thanks!

I did not notice at first but the patch also makes the secondary toolbar disappear when we have access to the toolbar and it leaves some empty space in the header.

Screenshot of the dev version without the patch :

Screenshot of the dev version with the patch :

I got a little confused with attaching the library for the secondary toolbar; it should not be used for the “Classic” version of the toolbar. This is fixed, could you check the patch again?

OK, the patch with the new commit corrects the issue in comment #12 when the user does has access to the toolbar, all is well now with the secondary toolbar. But we still have the same behaviour as before when the user does not have access to the toolbar reported in comment #11. We loose the sticky header when scrolling down with the shadow at its right place and the right column is not shown at all.

We're getting there, thank you!

Okay, the default values of zero in the variables were missing for correct calculations, I fixed that.

OK, now with the new commit, the right column is back and the shadow is still in its right place but the sticky header is still missing when scrolling down without toolbar access as you can see in this new screenshot :

And all is well when the user has toolbar access.

Thanks again!

Sticky region styles have their exceptions for form pages, which seems to be fixed now.

Same result as before, the sticky header is not sticky.

Also I do not think devel module should be added in composer.json require section?

Sorry, did you check before or after the last commit? Since I forgot to rebuild the css.

I deleted the composer.json changes, it happened by accident.

You were right, I tested right before the b1762dc7 commit.

So I tested again on Firefox and Chromium with success! The header is now sticky again with its shadow following properly and the right column displayed. I tested on desktop and mobile with and without toolbar access and all is well now!

Thank you very much for you time, I believe this fix is ready to be included in the next release.

I am re-opening this issue since I just noticed a side effect that the latest patch introduced.

We are loosing the primary tabs on the edit entity form when the "Primary tabs" block is placed in the default "Header" region.

Moving the "Primary tabs" block in the "Pre-content" region solves the problem but this is not a good solution since by default the primary tabs won't show when editing an entity.

Sorry for not catching this sooner...

Perhaps you are talking about this problem? Primary local tasks not rendering on entity routes due to striptags filter 🐛 Primary local tasks not rendering on entity routes due to striptags filter Fixed
I rebased the changes from the current development branch and my action block returned:

You are right, this is working perfectly now, thank you very much!

I believe this is ready to release!

Thanks y'all 👏

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