Mousewheel scrolling error in cms page

[ghost]

This is a new error, I have only started seeing this from v458 onwards - though maybe not version related. CMS is currently running V459.

I'm seeing this on the following browsers:

p.s. I'm using special browsers so I'm ahead of everyone, e.g. Chrome stable is V77 right now and I'm on V79

Also as this is on more than one browser - I'm filing this as an issue.

Here is a screenshot of what I'm seeing:

• Sorry filenames are blanked out as it's live on a client website. Gif taken on Firefox.

The error allows a user to scroll forever downwards, when using the mouse wheel.

Normally you just scroll down to the last file and the slider stops in this case seems to go on forever.

[re-sign]

A similar problem after updating Chrome to version 77.0.3865.75 in different versions of October.
October 446
October 458

[MaxNozhkin]

+1 after updating chrome to version 77.0.3865.90

[ghost]

Ok PR submitted.

There were two issues causing the error, these are as follows:

1. The issue was the position using absolute and not sticky, which caused a forever scrolling action. Position: sticky has fixed this issue.

2. The issue here was because the scrollbar javascript in the media manager needs to have the right sidebar displayed and the css was using display: none, switching it over to opacity: 0 allows the javascript to scroll the container. If you set the display to none you will see the data-visible attribute keep trying to set it to true and the screen starts flickering! The right sidebar in the media manager is the place where the media file previews are displayed.

Please can some people test out my PR and shout at me - when needed, pr is here: #4632

[Gugerty]

Thanks to @AyumiHamasaki I was able to impliment a temporary solution within OctoberCMS under:
Settings > Customize Backend > CSS

Added this CSS:

#layout-body > div > div > div > form > div > div.layout-row.whiteboard > div > div > div:nth-child(2) > div > div:nth-child(2) > div > div:nth-child(1) > div > div:nth-child(1) > div {
position:sticky;
}

[w20k]

Can't reproduce this issue anyhow...Hm, will try with media finder once again.

Latest build v459 (latest Chrome, not Canary: Version 77.0.3865.90 (Official Build) (64-bit)) Nothing for CMS page, media finder is still glitching.

Nothing in FF (70.0b8 (64-bit)).

[ghost]

@w20k Can you try with Chrome V79 and Firefox 71 please.

[w20k]

@ayumihamasaki2019
Chrome Version 79.0.3922.0 (Official Build) canary (64-bit), no plugins, clean build as well.
Still can't reproduce your bug.
Same for Nightly FF 71.0a1 (2019-09-24) (64-bit). FF is clean.

ScreenShots:

[ghost]

@w20k Nothing new lol - I think all the bugs follow me about.

Here is a video demo'ing the issue, sorry video quality is not good, trying to downscale the video from 4K screen to 1920px.

See here: https://youtu.be/cDJ17xbydlI

1. I show the latest firefox nightly.

2. October CMS is a brand new install on local host - no plugins - upgraded to v459.

3. I first scroll using mousewheel - which has the issue.

4. I next grab the scrollbar and move my mouse - which has the issue.

5. As you can see position:sticky works fine and position:absolute doesn't.

Important notes

If you change the position to sticky and go to media manager and scroll without the preview (right sidebar) open you will get data-visible true issues! Due to the right panel using display:none and not opcaity:0 if you look at the source code it even tells people:

<!-- This element is required for the scrollpad control -->

So I'm not sure why someone has added display:none in the first place!

Not sure how to get this issue and the other issue sorted out - due to all the admins not being able to reproduce the errors and all non-admins can (way too many people have reported these issues now).

Also note I'm seeing this issue as well in dev-tools:

This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”.

[everyx]

For me, it just work fine

div[data-control="media-manager"] .control-scrollpad {display: contents;}

.layout.control-tabs.oc-logo-transparent:not(.has-tabs), .flex-layout-column.oc-logo-transparent:not(.has-tabs), .layout-cell.oc-logo-transparent {display: flex !important;}

[ghost]

@everyx

I'm not going to be using display: contents for several reasons and you shouldn't use it!

It seems that browsers are going through 4 stages of support for accessible content and display: contents:

A) No support. display: contents is not recognized.

B) Partial support. display: contents is recognized, but none of the content is available to the accessibility tree.

C) Partial support. display: contents is recognized, the content is available to the accessibility tree, but a user can't get to it with focus (or other a11y bugs).

D) Full support. All accessibility bugs are fixed.

It looks like Firefox is in stage C, not D (as previously believed). Chrome / Edge 75+ and Safari are in the process of going from B to C. (Sorry, I'm not sure what's shipped when exactly.)

None of the browsers have reached D.

Can I use: https://caniuse.com/#feat=css-display-contents

To conclude:

1. display: contents behaves differently between cross browsers.

2. display: contents is not finished and subject to changes.

3. Very poor support and little backwards compatibility.

4. Has a huge number of bugs in many browsers still open.

My advice is NOT to use display: contents right now! It may seem to work in Google Chrome right now, but not at all in other browsers! October CMS is meant to work in various browsers not Google Chrome only.

[ghost]

Before I get anymore comments of various css fixes, I have already finished the pull request and tested it over various browsers you can see the results here: #4632 (comment)

I just need testers - not people commenting ideas.

[w20k]

@ayumihamasaki2019 sorry, even though I appreciate your fix, but from my point of view - can't accept it (@LukeTowers & @bennothommo might have different thoughts about your PR).

It'd better fix it in the scrollbar.js where scrollAmount & thumbPosition, shouldn't be more than canvasSize. And that should fix your issue without adding up new feature like css: sticky & pollyfills.

Need to test this out, but should be fairly simple. Somewhere here if canvasSize < thumbPosition set_to = max_position:

october/modules/backend/assets/js/october.scrollbar.js

Line 276 in 3118660

Scrollbar.prototype.calculateProperties = function() {

[ghost]

Let me know your findings, also please test it to see if it fixes the media manager at the same time! Restricting the canvasSize limit won't fix both issues! Because your suggestion doesn't cover the data-visible attribute issue.

[w20k]

Css: sticky won't be needed. You're limiting the scroller to go over you canvas size, which is, pretty much, your container div.

[github-actions]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.

[bennothommo]

Given that the original reporter is no longer available, and it has been reported that Chrome 78 and above have resolved a lot of scrolling issues, we are closing this. Please feel free to comment if the issue persists.

[xpectmore]

i've solve scrolling problems like this
https://stackoverflow.com/a/57641938/5781320