Also avoid media query partial obstructions

This issue isn't closed yet is it? Since there's still the sliver half of it.

It was closed because I put partially fixes in my PR.

We've also run into this problem. We are using a PersistenHeader for our app bar, so it would be good if a solution would not just work with SliverAppBar but can also be used for custom headers.

Another note for clarity: In our case we have several slivers below the header that are all scrollable (not just a single SliverList)

For future reference: we decided to implement a SliverScrollbar because it's hard to retrieve some metrics from outside of the viewport. For example if there's a persistent header sliver, detecting the amount of scroll extent it is blocking (which may change as the viewport scrolls) is tricky from outside.
A SliverScrollbar that takes a single sliver child should be able to get its own maxPaintExtent and paintExtent etc. easily.

One thing that makes the SliverScrollbar not as useful as it could be currently is that we do not have a "multi sliver adaptor sliver" kind of thing available in the framework right now. For example, putting a CupertinoSliverRefreshControl and a SliverMultiboxAdaptor in a SliverScrollbar would be impossible because it can't take more than one child. /cc @Piinks

SO cross-link:
https://stackoverflow.com/questions/56640482/how-to-show-scrollbar-in-sliverlist

I'm wondering is there a workaround for this issue(maybe even in some hacky way)?

Any update on this ?

@LongCatIsLooong I remember you started working on the sliver part. Did you have a draft PR or notes from your previous try?

@xster no unfortunately.

Any progress?

Also somewhat relevant for #87370 to avoid drawing the scrollbar on top of pinned header rows, for example.

any progress?

I have a proposal for this that should be up for review this week.
I just noticed this is also something the MaterialBanner would want to support. Currently it would overlap a SliverAppBar, just like a Scrollbar does. I need to test this new use case to make sure it works too before pushing the changes.
I'll probably land the ability to surface this information to these widgets, and then update each widget in a separate follow up change.

Closing this to consolidate in #107322
In researching a solution, I found a pattern of the same issue across multiple widgets in the framework. There is a full list in that tracking issue, including scrollbars.

I have a proposed solution in #107182 that will fix this consistently across all affected parts of the framework. That PR will be split up into multiple PRs to address each widget that needs this fix, just finishing the many test cases now. Please continue to follow in #107322, I expect all of thees changes to be landing soon.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.