I'll clarify: I suggest to stop moving the page itself up or down. Let the filter search bar stay where it is the moment one clicks on it (leave it static, but preserve the scaling of the list of filters). And let the users decide where they want to see it by using a mouse wheel

@Piramidion thanks for your input. I am having trouble picturing your suggestion. Maybe it would help if you can explain what problem you're attempting to solve?

In T175697#3601069, @jmatazzoni wrote:

@Piramidion thanks for your input. I am having trouble picturing your suggestion. Maybe it would help if you can explain what problem you're attempting to solve?

When you click on the search bar, wherever it is visible on your browser, the bar don't move. If the bar is at the top, it remains at the top, if it is located like this, it remains like it is when the filter list dropdown opens. At the moment, the search bar always moves to the top.

@Pginer-WMF, the issue here is that the users don't want the menu to scroll up when you click on it. But of course, many users do prefer this. Do you have a thought about this?

In T175697#3601378, @jmatazzoni wrote:

@Pginer-WMF, the issue here is that the users don't want the menu to scroll up when you click on it. But of course, many users do prefer this. Do you have a thought about this?

The proposal was for the scrolling to happen only when the user was close to the top of the page, scrolling down (i.e., moving the rest of the page up) so that the filter panel uses the most space of the viewport. I mentioned this in T158118#3028729:

• The page should scroll to maximise the available viewport for the filters when needed. If there are elements visible on top of the filter area, the page scrolls as soon as the search bar gets focused. Note in the prototype that the page never scrolls up, only scrolls down. Note also that it only scrolls down when there are a significant amount of pixels to scroll down, avoiding moving for just few pixels. There are more details about this in T149435, and an animation in F4687875

You can compare the current scroll behaviour in Recent Changes with the prototype.

Currently the scroll behaviour does some additional movements that may contribute to the feeling of being jumpy. I'll add some examples where automatic scroll should and should not happen:

When the filters are far from the top of te viewport, automatic scroll should happen to move the filters to the top of the viewport, as it currently happens:

However, if the distance to be scrolled is small (~20px) it is better not to do automatic scrolling. For example, this should not happen:

Never move the viewport up. If the user scrolled down, making the filer panel to be partially above the current viewport, thee should be no automatic scrolling. For example, this should not happen:

Change 377911 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Only selectively scroll to popup when it's focused

https://gerrit.wikimedia.org/r/377911

I have +2 the patch above but I would invite @Pginer-WMF and others to try it in betalabs. The second case (don't scroll up if we are close enough to the top) may need some tweaking. It feels like it's always scrolling up unless you are in that tiny range.

Change 377911 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Only selectively scroll to popup when it's focused

https://gerrit.wikimedia.org/r/377911

In T175697#3610333, @SBisson wrote:

I have +2 the patch above but I would invite @Pginer-WMF and others to try it in betalabs. The second case (don't scroll up if we are close enough to the top) may need some tweaking. It feels like it's always scrolling up unless you are in that tiny range.

The general behaviour in beta looks good. The idea of the second case is to have a "safety area" to prevent the automatic scroll to enter into action when it adds little value. For example, when scrolling up the list of filters you reach to the top and some scrolling propagates to the page. If the current distance feels too little we can extend that a bit.

It seems that the cases that should not happen are, in fact, not happening.

if the distance to be scrolled is small (~20px) it is better not to do automatic scrolling.

If the user scrolled down, making the filer panel to be partially above the current viewport, there should be no automatic scrolling

So, the self-adjusted position is as following - notice the space at the top of the viewport:

When a user scrolls the page down, so the upper part of the view port is the beginning of the Filter search box is partially overlaps, then the page won't be moved when a user clicks in the Filter search area. So, the static states (nothing is moved) make it possible to see the following.

Note: Reading the original discussion, I think that the feedback on the "jumping" calls for the totally static state.

QA Recommendation: Product should weigh in

@Pginer-WMF can you please review this one? I'm not sure I understand all the desired behavior.

In T175697#3620143, @jmatazzoni wrote:

@Pginer-WMF can you please review this one? I'm not sure I understand all the desired behavior.

I checked it on beta and works well. The desired behaviour is to scroll only when the viewport is too close to the beginning of the page that it would result in very little room for the filter menu. Before, it used to scroll in additional cases where that was not the case.

Reading the user comments I noticed another automatic scrolling behaviour we want to prevent.

Currently when switching tabs in the browser the scroll position is updated. In the example below, I manually scrolled the Recent Changes page to a specific position, but after moving to another tab and back, the scroll position is not respected.

Automatic scroll should not happen when switching tabs or those getting or losing the focus. It should only happen when the user opens the filter panel and the viewport position is close to the top of the page.