Full Page SPFx App ("SharePointFullPage" host) - scrollable region that contains web part on page now always shows scrollbar

[tandrasi]

trafficstars

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [ ] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• browser version latest
• SPFx version 1.16.1, 1.17.4, 1.18.0, 1.18.2
• Node.js version 16.19.1 and 18.18.0 (depending on SPFx version above)

Describe the bug / error

Since a recent SPO update, there is now a faint scrollbar that is present on all our full page apps, even across on multiple tenancies.

I wasn't sure were to post this bug report to be honest.

This is because there has been a change and the scrollable area which houses the SPFx web part has had its styles updated from "overflow-y: auto" to "overflow-y: scroll".

It has changed to "overflow-y: scroll" and has effectively made it so the scrollbar always appears regardless of content.

In many of our apps, we use absolute positioning and height calculations to animate the content the user is seeing. Now we are stuck with multiple scrollbars

Steps to reproduce

1. Load up an SPFx webpart that supports the SharePointFullPage host;
2. See faint inactive scrollbar to the right due to "overflow-y: scroll"

Expected behavior

I expect the scrollbar to appear when necessary (i.e. "overflow-y: auto") rather than it always appearing even when it is disabled.

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[chr-sad]

We experience the same issue. Are there any news on this topic? It would be interesting to know if the new behavior is by design and will stay that way or if it is a bug that will be fixed in a future update.

[tandrasi]

We experience the same issue. Are there any news on this topic? It would be interesting to know if the new behavior is by design and will stay that way or if it is a bug that will be fixed in a future update.

No, no news yet unfortunately. This is annoying to say the least and breaks our seamless design pattern. I wish we'd get a response as I don't understand the change!

[chr-sad]

I am not sure if anyone is aware of this ticket because of "ghost" (deleted user)? I am sure, there are some "more important" tickets in the issue list, but I would highly appreciate if someone can tell, if this ticket was read and if there is a plan, to resolve this issue or if it will stay as it is now?

[tandrasi]

I am not sure if anyone is aware of this ticket because of "ghost" (deleted user)? I am sure, there are some "more important" tickets in the issue list, but I would highly appreciate if someone can tell, if this ticket was read and if there is a plan, to resolve this issue or if it will stay as it is now?

I'm not sure where things are up to, but I have found that for newer projects, we're now setting the scrollable region to hidden by traversing up the DOM tree via this.domElement present in the webpart file (that initializes the app). This at least fixes current projects but older projects are still left in the dirt unless we fix and redeploy.

[chr-sad]

We do that too :) At the moment only in our internal test versions, because we had hoped that it would be corrected and we don't really want to do something like that in production. But now that it's working, and I don't expect there to be any news soon, we have to solve it that way. Thanks for your reply!

[Amey-MSFT]

Hello @tandrasi, Thank you for bringing this issue to our attention. Could you please confirm if the issue still persists for you?

[Amey-MSFT]

We are closing this issue for now. If the problem persists, feel free to reopen it or open a new one.