If you’re seeing horizontal and/or vertical scrollbars around the main part of the WME window (as opposed to within the sidepanel or anywhere else you’d expect to see them), then this is usually an indication that something is pushing part of the window contents further off to one side than the page design can cope with, and your browser is then left with no option but to provide scrollbars in order to give you access to the bits that’ve fallen off the edge of the intended view…
Now, given how much stuff FUME does to manipulate the WME UI - moving stuff around, changing sizes etc. - it’s a reasonable assumption that FUME is the guilty party here.
However, it’s worth remembering that other scripts may also add their own UI elements, which FUME will then do its best to accommodate. But there are limits to this - I can’t test with every single combination of scripts or screensizes, so I just have to work on the presumption that most people will be using a combination that is close to the norm in terms of screen size and additional UI changes, and tailor FUME’s modifications accordingly.
So, having already taken the first step to troubleshooting - i.e. disabling FUME and seeing if the problem goes away - the next step you need to take is to try disabling everything else except FUME, and then see if the problem is still present. If it is, then we know the problem is definitely within FUME itself, and definitely related to how it’s interacting with the native WME UI. THIS is the sort of problem I definitely want to know about, because it’ll potentially affect everyone.
If however you can’t reproduce the problem with just FUME, the next next step would be to start re-enabling other scripts and seeing when the problem returns - at that point you’ll know that it’s the interaction between what FUME is doing generally to the UI, and what the most recently re-enabled other script is also doing to the UI for its own needs, and I can try to reproduce the problem here by installing that script if it’s not one I’ve already got.
A further wrinkle with UI-based stuff is in how your host OS handles screen rendering - this is particularly relevant if you’re using a high DPI screen (e.g. 3K or above) and have then enabled OS-level scaling either to reduce your effective desktop resolution, or to increase the size of UI elements. In these cases, the interaction between the native resolution of the display and the effective post-scaling resolution can cause the browser to get confused over how large or small things actually need to be, such that you end up seeing display oddities that aren’t present on systems where the display hardware is natively limited to the effective resolution you’re using - e.g. running your desktop at 1920x1080 can give a different effect to running your desktop at 3840x2160 with 200% scaling, even though effectively the latter is also 1920x1080… So knowing what your physical and effective desktop resolutions are is also useful when trying to resolve problems like this, and it’s worth experimenting with those settings yourself to see if reducing the resolution at the OS level and letting your display scale up to fit, rather than keeping the resolution higher at the OS level and then using OS-level scaling, makes a difference.
Thanks.
