Auto Scrolling Glitch

tmangan

Trying to scroll through my projects in a to do list on comfortable and the lists will glitch and rapidly scroll up and down without stopping. Had Smartsheet engineers and IT try everything and they can not duplicate it nor figure it out. Anyone have a fix?

prime_nathaniel

@tmangan I am like 99% certain scrolling is via your browser not via the app.

You can see from developer tools that the desktop body element is using standard styling and events to manage scrollbars. This means there is nothing SMAR can do about your scrolling as it is actually implemented by Chrome, Edge, or whatever browser you are using.

That said, it is most likely a physical mouse error or a driver error.

Try replacing your mouse or using a trackpad interface for a bit, it likely will not do it on that setup. If it doesn't you know its related to the peripheral.

tmangan

It doesnt happen to all spreadsheets only when i am in comfortable mode, in a board. Everything else is fine.

Bekah_TX

@tmangan / @prime_nathaniel I also experience this glitching when in Board view using either Chrome or Edge. Seems to occur anytime the number of cards exceeds the visible pane based on browser zoom. I zoomed way in to force scrolling when only a few cards were present - glitching occurred. I zoomed way out to eliminate the need to scroll - no glitching. Occurs in both Comfortable and Compact mode, irrespective of mouse used (USB or onboard trackpad). I use Card view exclusively due to this glitchiness.

tmangan

thank you. Smartsheet support couldnt figure it out and couldnt duplicate it.

prime_nathaniel

@Bekah_TX / @tmangan I just tried it with zoom in and zoom out and my cards still scroll fine even in the multi thousand record ranges. I also tried scrolling top of list, middle, and bottom area. What I did notice that was interesting is that cards are scrolled via async javascript so it is possible to be an issue in the SMAR front end code that could potentially scroll you back up.

All these requests here are triggered during the scroll events. It is plausible that when that data comes back something may actually reset in the browser state to force your scroll position back up top somewhere.

In the logging-service event there is also a specific mention of scrolling metadata

{
"context": {
"client_event_id": "71",
"client_event_value": "6.965111125182043",
"client_event_success": "true",
"performanceEventName": "CARD_VIEW_SCROLL_FPS",
"gridId": "3001177843087",
"isPerfEvent": "true",
"orgId": "1596462"
},
"logLevel": "INFO",
"messageTemplate": "Performance Event (CARD_VIEW_SCROLL_FPS) complete for gridId 3001177843087\nMetadata: {"gridId":"3001177843087","elapsedTimeMs":1579.3}",
"appName": "core_views_ui",
"appVersion": "407.0.0",
"featureArea": "CARD_VIEW"
}

So I would assume then if there was a race condition on async handling where an old scroll event logged AFTER a new scroll event it is maybe possible that it "completes" your 2nd or 3rd scroll request after your 1st. Or something of that nature.

I'd say you'll want to continue to log it as a ticket as it comes up as there won't be much more community can do regarding it.

Bekah_TX

@prime_nathaniel thanks for the redirect to submit a ticket. I'll take action on that.

prime_nathaniel

@Bekah_TX you should be able to include the details from my browser / screenshot atleast then it has a better chance of getting to the right team