fix(q-layout): Update scroll regardless of scroll prevented #12994

[kalvenschraut]

Fixes #12994

Problem as I described in my issue is due to the fact the loading plugin uses the prevent scroll plugin. Due to this if the loader is ever active when a scroll event would be triggered the scroll position change would be ignored. This issue was specifically a problem for me clicking on a button at the bottom of a long page which then redirected to a page with no scroll. My pages uses the loading plugin and suspense to show a global spinner and the next page is loaded. In this scenario since I use the reveal header prop when I am scrolled all the way down to click on the navigation button, the header is hidden. Then the loader appears and sets prevent scroll true, scroll event fires since page body has changed and it isn't long enough to need a scroll bar. Due to the previous steps the header never reappears since the prevent scroll true is preventing the updating of the scroll object it is watching.

As I mentioned in my issue I couldn't consistently reproduce this outside of my applications environment. Seems to be a very specific race condition which are always fun to try and reproduce. Hope I described it thoroughly enough so the problem can be easily seen just by code inspection alone.

Alternative solution to this problem would be to only update scroll if it has a changed value when scrolling is prevented but not sure if that is really any better then always updating it on change event. Open to other possible ways to fix my scenario, figured I would make a PR for mine since my issue wasn't getting any response.

What kind of change does this PR introduce?

• Bugfix
• Feature
• Documentation
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes
• No? I don't think this is breaking but can't be sure

The PR fulfills these requirements:

• It's submitted to the dev branch (or v[X] branch)
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested on a Cordova (iOS, Android) app
• It's been tested on a Electron app
• Any necessary documentation has been added or updated in the docs or explained in the PR's description.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to start a new feature discussion first and wait for approval before working on it)

Other information:

[rstoenescu]

Hi,

Thank you for contributing!
Unfortunately, this fixes your specific issue but breaks the exact problem that was fixed by adding that bit of code.

Will look at your ticket and try to find a fix for that scenario instead.