I just noticed the horizontal scrollbar is missing in my AppImage of Manager.
I normally run at full screen on my 1920x1080 monitor, but today I was running it on a 1280x1024 screen at a customer’s office. This made the missing horizontal scrollbar painfully obvious.
So then I came back to my monitor and ran Manager in a window instead of fullscreen, and can replicate the missing scrollbar.
I first noticed it on AppImage version 21.9.29, so I upgraded today to 22.1.3, but the problem persists.
Not sure if this is related, but the vertical scrollbar is not right-aligned, but is about 1/4" away from the right edge of the window.
I realize this might be an AppImage issue rather than a Manager issue since no one else has reported this error in the forums. I did a web search for AppImage related settings, but found nothing helpful. I thought you brainy ones would perhaps know where to point me to solve this.
Thanks Tut, for trying it.
This is what I see. There are 5 fields to the right of Qty, yet no way to scroll to them. And the vertical scrollbar I highlighted with my mouse is not right-justified. Note the blue bar on top of the field emphasizes the gap from right edge of window. When I move the mouse pointer to the bottom of the window, no scrollbar appears.
I just discovered … it scrolls left-to-right anyway!!! That is, if I position the mouse exactly where I estimate the horizontal scrollbar should be, then it scrolls! But no scrollbar ever appears, so I have to guess where it is. Interesting. Good Jedi training tool. The force is strong with this one.
I’m open to suggestions.
In OpenSuse Tumbleweed with KDE, I switched from the default to Breeze Dark and a handful of others, and nothing changed in Manager for any of them. It’s as if the AppImage was unaffected by the theme. I appreciate your suggestion.
To my shallow knowledge on Linux – and I stand to be corrected – but I always thought that Opensuse isn’t the most stable of distros, so I can’t rule out this issue being an OS bug rather than a Manager bug.
I’m sure there’s going to be a fix for this issue at some point but for the time being you still want to be able to scroll. Have you tried opening a browser instance of Manager instead of running the app? That could be a temporary fix.
Thank you, Ealfardan.
I’ve been running OpenSuse for close to two decades. And it’s true, back in the early days, every once in a while an update would break something. But with Tumbleweed, I can’t think of the last time an update has broken anything. Tumbleweed is a rolling release, which means I get to stay current with the kernel and the desktop environment et al instead of having to risk jumping from version to version.
However you’re spot on that obviously something is different since the previous poster Mark said it worked in Mint and he was able to get a workaround for Ubuntu-mate. So that’s three distros, and three different experiences.
I’m running the single-user standalone version of Manager, and am unaware how to access it through the browser. If you have any info on that, I’m willing to try it.
At the point where we run out of things to try here, I can post in the OpenSuse forums and see if anyone has any ideas. If they do, I’ll be sure to pass the answer on here.
I opened the AppImage to start Manager, and then I switched to my operating system’s web browser and went to http://127.0.0.1:55667
and I now have a horizontal scroll bar and the vertical scroll bar is fully right-aligned!
Thank you very much.
At this point I have a fully functional workaround. Should I consider this case closed, or does this help identify the bug for future releases? I’m willing to do further tests as needed.
My default browser was Firefox, but I’ve been using Brave. So I changed default to Brave.
After a reboot, accessing the data through the AppImage browser still fails on the scroll bars.
I’m a web developer and I have multiple browsers installed (Firefox, Brave, Chromium, Opera). I used all four of them from the operating system to access my company file, and all four of them presented correct scroll bars.
Patch mentioned, “The desktop version runs the same code, the difference is it is preconfigured to use a particular browser.”
Is this different than choosing the default browser application of the operating system?
If that did not work on another forum they delve deeper. A solution proffered is:
The fix will come in the form of a fonts-config package update. The default settings in /etc/sysconfig/fonts-config was changed in Tumbleweed long ago, but this change of default values was never translated to SLE (nor Leap), so current values in that file are not appropriate for the newer freetype2 library if someone tries to use rgb subpixel hinting (which xfce is enforcing, ignoring the fontconfig configuration).
Just a thought. - I wonder if Wayland might be the culprit here.
Is this happening when the desktop session is run under Wayland ?..
Or perhaps when using a different (internal or external) GPU (say Nvidea for example), again with or without Wayland ?
It might be worth trying to run Manager in a Wayland session and then an X11 session in order to compare any differences in performance and presentation
Forcing font dpi to 96 did nothing.
Fonts-config already had the settings you mentioned.
I watched services starting with the Manager AppImage, and found WebKitWebProcess and WebKitNetworkProcess
For fun I deleted webkit from my installation, and when I ran Manager AppImage, it failed to start, requesting that I install libwebkit2gtk. Once I re-installed that and its dependencies, Manager AppImage started again.
So Webkit is the hard-coded “browser” in Manager AppImage on Linux.
I’m running the X server. For fun I tried to launch it with Wayland, but it failed and sent me back to the login screen.
Good detective work!
Which means there is an issue with Webkit rendering of web pages produced by Manager.
I’m not familiar with WebKit but with other web browsers used by Managers desktop version, the underlying web browsers default setting can be changed to enable changes to how Manager desktop behaves (for example default printed headers and footers). Perhaps a useful configuration option is available for Webkit. Alternatively perhaps there is a version incompatibility. For a more general incompatibility I would expect more Linux desktop users to report the issue (unless you are just the first to update your software).
On my OpenSuse system, I have three versions of Webkit - Version 4, 4.1, 5.0.
I just tried all three, and Manager only works with Version 4. Here’s a picture of Manager’s error message:
From my Package Manager, I get the following description for Webkit:
libwebkit2gtk-4_0-37 - Library for rendering web content, GTK+ Port
WebKit is a web content engine, derived from KHTML and KJS from KDE, and used primarily in Apple’s Safari browser. It is made to be embedded in other applications, such as mail readers, or web browsers.
@juliejohn Try downloading and running the server version. Then open your preferred browser to 127.0.0.1:8080. Run in full screen on FF.
You will have the evaluation warning at the top of the screen but no loss of functionality.
I use this as webview2 still has issues running with Windows Explorer.
The scrollbar problem is related to Suse Linux, Webkit and the CSS used by Manager. You did not indicate with which version of Manager you did not have this problem and at which version it started occurring. I suspect it may have to do with a main css change in post 57 of the following discussion:
I appreciate the feedback and I know all of you want to make Manager better. I accept the criticism that if business has a lot of tabs, the constant scrolling is unbearable. So I came up with the following improvement in the latest version (21.4.64)
As such it may be useful if you could install a Manager version older than 21.4.46 from https://github.com/Manager-io/Manager.AppImage/releases. Beware that it may be important to temporary move the data folder to another location so the older version won’t access them. You have to do that before the install of that older version. If it works with the older version than @Lubos may need to revise the CSS to be compliant with webkit and render the scrollbar as expected.