Atom 1.7: bad scrollbar behavior

[PhiLhoSoft]

Windows 7, Atom 1.7.1 started in safe mode.

I load a medium-sized file, around 500 lines of JS code.
I jump to the end of the file with Ctrl+End.

The scrollbar thumb isn't at the bottom of the scrollbar.
I try to click on the middle of the thumb (to drag it). The thumb goes up. I can repeat this a few times, until the thumb goes in the first half of the bar. There, I can catch it...

Actually, I can drag the thumb if I aim at where it should be (the bottom of the bar).

[cristian-sima]

+1

[jscissr]

I have the same issue, since Atom 1.7.0 or 1.7.1:

The file is scrolled to the bottom, but the handle is not shown where it actually is. You can even drag the handle where it should be displayed.
When I open Devtools, and remove transform: translateZ(0px); from the scrollbar component, the issue is gone, but apparently this was added to fix a different bug on mac.
If this bug only affects Windows and the other one only Mac, maybe it could be worked around by only executing that line on Mac?

[lee-dohm]

@damieng Can you take a look at this?

[PhiLhoSoft]

Atom 1.7.3, I can still see the issue...
Very annoying. At least, I have the minimap to scroll correctly...
Note: I see that whatever the length of the file, from 100 to 700+.
Curiously, sometime I get the right behavior. Rare and hard to reproduce! (ie. bad behavior is more frequent / reproducible).

[Ben3eeE]

I can only reproduce this when using the https://github.com/atom/atom-light-ui theme all other themes seem to work fine.
Seems to randomly work sometimes as @PhiLhoSoft mentioned, can't determine under which circumstances it works or not.
Changing theme from atom-light-ui to atom-dark-ui and then back to atom-light-ui seems to temporarily fix the problem in all open files where this bug was encountered.

[leonexis]

I've been having an issue where the scrollbars are just not themed and seems to be a regression of #3559. I found out that if you disable the transform: translateZ(0px) part of the style attribute in the div.vertical-scrollbar using the debugging tools (Ctrl+Shift+I), the scrollbar goes back to the themed scrollbar and looks correct. This attribute is added by code in src/scrollbar-component.coffee at line 6:

 @domNode.style['-webkit-transform'] = 'translateZ(0)' # See atom/atom#3559

It is possible that the Chromium bug found in #3559 (see #3559 (comment)) has been fixed and the transform is no longer needed. The transform was originally added in bac9922 and only applied when hardware acceleration was enabled, however the current form of the code seems to add this in any case and is no longer conditional. This seems to be a hack since non-conditional styles applied to an element should be added to the CSS/LESS, not in code. I could have an easy workaround if was just a CSS change...

EDIT: Just wanted to mention that re-enabling the transform makes the styled scrollbars disappear again and returned back to its buggy state. Checking/unchecking in the debugger's Elements > Styles tab repeatedly makes the scrollbars go back and forth every time and is why I'm suggesting that this style might be the cause, or at least removing the style might work around whatever bug is causing this.

Sorry, missed that @jscissr already found the issue =P

[leonexis]

Not a Windows-only bug. I can reproduce in 1.7.3 on Ubuntu 14.04 LTS fully up to date. Since hardware acceleration might be an issue, here is the hardware info from About This Computer:

Memory: 31.4 GiB
Processor: AMD FX(tm)-8320 Eight-Core Processor x 8
Graphics: AMD Radeon HD 6450
OS type: 64-bit
Disk: 967.7 GB

I am using the proprietary AMD drivers from fglrx-updates (currently 2:15.201-0ubuntu0.14.04.1)

[leonexis]

tl;dr: my issue might be caused by a community package instead, but may point to a possible cause of the original issue.

After some testing with a local build of 1.8 beta 3 and reset sessions as a result, I think I found a way to trigger the bug, though for me it was triggered with the help of a community package and may be a bug in that package instead. If so, what I'm experiencing may not be related to the original. But so far, this is the only way I can find to reproduce the visual issue from a fresh .atom. It works in 1.7.3 and 1.8-beta3.

1. Start atom with a fresh session (remove/backup .atom, or use --portable with local .atom generated from the skeleton from atom/dot-atom)
2. Open settings and UNcheck Open Empty Editor On Start to enable saving sessions.
3. Go to Install and install and enable the browser-plus package.
4. Open a large source file, for example, atom/src/application-delegate.coffee. Scrollbar will be normal.
5. Press Ctrl+S to save without changing (this may not be required, but unedited tabs seem to be ephemeral now).
6. Press Ctrl+Q or go to File -> Quit
7. Start Atom back up and the scrollbar will be unstyled for the saved tab in the session.
8. Open another file in a new tab and the scrollbar in that tab appears normal.
9. Quit atom and restart, scrollbars are bugged.
10. Disable the browser-plus package and quit/restart atom
11. Scrollbars are normal

I don't know if that helps or not. So far, I cannot reproduce without the browser-plus package and the issue does not appear in safe mode for atom. However, removing the transform: translateZ property in the devtools does fix the scrollbars here as well, and re-enabling that transform makes the scrollbar bugged again.

As for the original bug, this might be a race condition between two internal components that are trying to adjust styles (CSS order) or causing different Z positions based on element appears first. I'm not sure.

One other thing to note here is that, unlike @Ben3eeE's being only able to reproduce in the light-ui theme, this reproduces with both the stock One Dark and Atom Dark themes (both UI and syntax).

HTH

[Ben3eeE]

So this seems to happen when the scrollbars are non themed? Are the scrollbars in atom-light-ui supposed to be themed same as the other three themes in Atom? They look like native scrollbars now anyway.
Just to confirm: @leonexis are you able to reproduce the original issue here of the scrollbar getting stuck before the end on Linux and not the non-themed scrollbar issue caused by browser-plus? It seems like you are mixing up two different but slightly related issues.

@leonexis I also have all kinds of problems with the https://github.com/skandasoft/browser-plus/ package same as you describe. browser-plus seems to throw error messages to the console all the time nowadays so I have disabled it.

It started with font-awesome.min.css net:ERR_FILE_NOT_FOUND errors that I reported skandasoft/browser-plus#69. After that I started to get exceptions when opening the browser plus window (Only in the console) and non themed scrollbars when relaunching atom with the package enabled. I never bothered to report any of the other errors and just disabled it instead.

Console output when I get with browser-plus enabled.

file:///C:/Users/lineri/AppData/Local/atom/app-1.7.3/resources/app.asar/static/font-awesome.min.css Failed to load resource: net::ERR_FILE_NOT_FOUND
C:\Users\lineri\AppData\Local\atom\app-1.7.3\resources\atom.asar\common\api\lib\deprecate.js:102 (electron) getUrl is deprecated. Use getURL instead.
C:\Users\lineri\AppData\Local\atom\app-1.7.3\resources\app.asar\src\state-store.js:33 Uncaught (in promise) DOMException: Failed to execute 'put' on 'IDBObjectStore': An object could not be cloned.(…)dbPromise.then.db @ C:\Users\lineri\AppData\Local\atom\app-1.7.3\resources\app.asar\src\state-store.js:33
C:\Users\lineri\AppData\Local\atom\app-1.7.3\resources\app.asar\src\state-store.js:33 Uncaught (in promise) DOMException: Failed to execute 'put' on 'IDBObjectStore': An object could not be cloned.(…)

[leonexis]

@Ben3eeE, I was not able to reproduce the original problem in linux as described in the original report. However, I was able to reproduce it in Windows 10 (MSEdge VM from modern.IE in Virtualbox 5.0.10, 2D/3D acceleration enabled) with a fresh install of Atom. It required that I switch to the Atom Light theme as you mentioned. I then opened ~\AppData\Local\atom\app-1.7.3 as the project directory, then selected app-1.7.3/locales/resources/app/apm/node_modules/async/lib/async.js as the file to open. After pressing Ctrl+End, sure enough the handle did not go to the bottom. Clicking on the handle to drag it made it jump up a page as if I were clicking above the handle, reproducing @PhiLhoSoft's original issue. Reproducing in Windows did not require installing any packages or changing any settings other than setting the theme to Atom Light. As best as I can tell, Atom Light chooses not to override the standard blink scrollbars, which I think is perfectly valid.

Now that I've seen the original bug in action in Windows, I attempted to reproduce in Linux using the same steps as above. I could not reproduce in Linux. The scrollbar appeared to work normally in Atom 1.7.3 on Ubuntu 14.04. My issue appears to be unrelated to the original. It just so happens that removing translateZ appears to fix it as well.

If I had a mac, I would try removing the translateZ to see if it regresses the original bug that caused it to be added, but I don't have one. I can say that this does appear to be a Windows-only problem and should probably be re-tagged as such. Sorry for my confusion =)

[Ben3eeE]

@damieng Add Windows label again? ☝️

[jscissr]

So just now it happened that I had two panes open, the left one had the bug, the right one not. I opened DevTools:

And it looks like the width: 15px is the culprit: change it to 17 and the problem is gone.
The 15 is from here, and when I set a breakpoint there and open a pane, cornerNode.offsetWidth and clientWidth are 0. The reason it works sometimes is this line.

It seems like the scrollbar dimensions are measured too early, but while Atom is initializing, onAllThemesLoaded is called, which fixes the problem for just this pane.

[Ben3eeE]

I tried changing the lines @jscissr mention to

    width = (cornerNode.offsetWidth - cornerNode.clientWidth) or 17
    height = (cornerNode.offsetHeight - cornerNode.clientHeight) or 17

And the problem does seem to have disappeared.

[niklasfink]

@Ben3eeE Where to change those lines when Atom-UI-Light is enabled?

[Ben3eeE]

@niklasfink Changing these lines is likely not a correct solution or workaround for this issue, my comment was to test the information that the cause seems to be centered around these lines as @jscissr had investigated.
If you still want to change them you would have to build Atom from source.

[rejhgadellaa]

+1 && /sub

Also: still a problem in 1.8

[cristian-sima]

I had to change the theme as long as there was impossible to work with it

[rkingsbury]

Still occurs for me on 1.9.8, Windows 10, with Atom Light theme. Switching the theme to One Light and back to Atom Light provides a temporary fix.

[XaserAcheron]

Dunno how helpful "+1"s are, but it's been happening to me too. Win7, Atom Light. Matches all the symptoms.

@leonexis provided a good repro case, looks like. Anything else we can do to help identify+solve it? Aside from the usual "fix it and make a PR" bit. ;)

[skywind3000]

+1 still a problem in 1.9.8

[Download]

I'm seeing the same issue on 1.9.9 on Windows 10 Home.

When I open a file from the tree view, I can scroll down using the scrollbar.
But the scrollbar never reaches the bottom. When the file is at the bottom, the scrollbar still has an inch or so to go. Then, after I've reached the end of the file, the scrollbar seems to get 'stuck', only 'wiggling' a couple of pixels when I click it. I can't use it to scroll anymore. I can use the scroll wheel, that still works...

I can only reproduce this when using the https://github.com/atom/atom-light-ui theme all other themes seem to work fine.

I am also using atom-light-ui. Will test if switching themes helps.

Also, I have Line Numbers enabled. Not sure if it matters.

[Download]

Switched to Atom Dark for both UI and Syntax themes and it resolves it. I hate dark themes however so .... mmm...

EDIT:
One more test. I switched just the UI theme back to Atom Light, keeping the syntax theme the same. The bug reappears. So I guess we can confirm that the issue is somewhere in the theme code.

EDIT 2:
Using One Light UI theme and Atom Light Syntax theme, the bug does not occur. This means I can use a light theme and not have this bug, which is great!!!

Workaround

Switch the UI theme to One Light (or any theme but Atom Light it seems) and the bug is gone.

[winstliu]

/cc @simurai regarding Atom Light.

[simurai]

And it looks like the width: 15px is the culprit: change it to 17 and the problem is gone.

👍 Nice find, @jscissr

If I change it to 10px (or anything smaller than 15px), I can also reproduce it on macOS. Not when reloading Atom, but when opening an existing file.

Maybe the native scrollbars have different widths on Windows vs macOS. That will somehow cause the scrolling to be off. This post seems to confirm the 17px number.

The reason why it seems to work in Atom dark UI is because it uses a custom scrollbar. There the width is just 10px.

So possible solutions might be:

1. Also use a custom scrollbars for this light theme. PR here: Custom scrollbars atom-light-ui#34
   • Downside is that it would only fix it for this theme.. there might are other themes that use the native scrollbars.
2. Have a different width/height for each platform. Windows: 17px, macOS: 15px. Linux seems fine with 15px too.

Ideally, there shouldn't be a need for those "fallback" sizes, but I guess that's a lot harder to fix. I can merge option 1, in case nobody wants to try option 2.

[skywind3000]

+1 still a problem in 1.10.2

[simurai]

Merged atom/atom-light-ui#34. So atom-light-ui will get a custom scrollbar in Atom 1.12.

But it's still an issue for themes that use the native (unstyled) scrollbars.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!