SmartClient Version: v13.1p_2026-04-24/AllModules Development Only (built 2026-04-24)
Hi, I noticed an issue with column freezing in grids when using the filterEditor.
Try an example like this: https://smartclient.com/smartclient-13.1/showcase/?id=fetchOperationFS , then click on “show filter row”, widen the columns until you get a horizontal scrollbar, and then freeze any column.
If you try to scroll horizontally, you’ll see that the filter editor moves even for the frozen column.
hi Claudio, thanks for the report.
This was a bug where the frozen property was not being propagated to the separate field definitions in the filter-row.
It’s been fixed in affected branches for tomorrow’s builds, dated April 28 and later.
Hi @all,
it’s even worse. I tried that online example (v13.1p_2026-04-24, FF150 Win11) and when you widen a column until you get a horizontal scrollbar, you can’t use that scrollbar with the mouse. Scrolling right/left with the arrow keys still works. Same if you just start the fieldPicker sample. Same in 14.1p and 15.0d.
OK in 15.0d in Egde 147, with does not have floating scrollbars.
I tried here with floatingScrollbars:false, nativeAutoHideScrollbars:false, showCustomScrollbars:false in FF150 and it did not make any difference. Not sure this is expected.
Best regards
Blama
Thanks Blama - we see this issue with non-functional h-scrollbars in LG in Firefox and we’re taking a look
This has been fixed for tomorrow’s builds - it was a regression resulting from a recent fix for animateScroll() terminating early on macOS.
Hi @Isomorphic,
that’s great.
What about floatingScrollbars:false, nativeAutoHideScrollbars:false, showCustomScrollbars:false in FF150 having no effect (set on the ListGrid in the sample). Is that expected? Am I missing something?
Best regards
Blama
There were two issues here, which we’ll fix shortly:
two of those three properties are not being propagated from the ListGrid to it’s GridRenderer children
ironically, your showCustomScrollbars: false is what causes this situation - there is logic in GridRenderer that catches showCustomScrollbars: false, reverses it and switches to the NativeScrollbar mechanism, including setting floatingScrollbars in Firefox. It shouldn’t do this when nativeAutoHideScrollbars is false.
If you want to test that, you can make the showcase sample work by setting your properties on the body as well as the grid:
// showCustomScrollbars: true is necessary - false uses native scrollbars
floatingScrollbars:false, nativeAutoHideScrollbars:false, showCustomScrollbars:true,
// set on the body as well, to defeat missing propagation
bodyProperties: {
floatingScrollbars:false, nativeAutoHideScrollbars:false, showCustomScrollbars:true
},
Hi, thanks, but there are no new 13.1 builds after the one from April 24.
Thanks Claudio - we’ve made a build-process tweak to address this and you should find new 13.1 and 14.1 builds today - we’ll keep an eye on it, just in case.
SmartClient Version: v13.1p_2026-05-02/AllModules Development Only (built 2026-05-02)
Hi, everything is working fine for me now.
Hi @Isomorphic,
I think the issues you mentioned in #7 are still open (v14.1p_2026-05-02).
Best regards
Blama
hi Blama - those issues have been addressed and we see things working as expected at the link you showed in Firefox.
As we noted in #7, it won’t do anything if you set showCustomScrollbars to false as you did in your original note, because that will use Native scrollbars, which do auto-hide on Firefox.
Otherwise, if you set floatingScrollbars:false and nativeAutoHideScrollbars:false, Firefox will show the scrollbar permanently.
Hi @Isomorphic,
so many setters 
I’m trying with Win11 FF150 here (v14.1p_2026-05-02) and these settings on the ListGrid only (not also on bodyProperties):
floatingScrollbars:false, nativeAutoHideScrollbars:true, showCustomScrollbars:true,
I don’t see any visual difference whether I set floatingScrollbars false or true. Is this expected?
And last issue: It seems that with these settings, the scrollbars are quite often not working.
I think it only happens when both scrollbars are visible and then affects the 2nd scrollbar you want to use.
Best regards
Blama
hi Blama, thanks for the feedback.
Yes, in FF, it is expected that setting floatingScrollbars doesn’t do anything. We’ve made a bunch of JSDoc changes for the three properties discussed previously to make clear how they interact in different environments, along with situations when they are either defaulted by showCustomScrollbars or useNativeAutoHideScrollbars, or when they are non-functional. These are now better interlinked with the MinimalScrollbar class, which is what you need to use as scrollbarConstructor if you want Firefox-like auto-hiding scrollbars on Windows/Chrome.
By way of specifics:
for fixed scrollbars on macOS / Firefox on Windows: Set nativeAutoHideScrollbars: false on the grid to override the skin default and force standard custom scrollbars that reserve space beside the content.
for auto-hiding scrollbars on any browser: set nativeAutoHideScrollbars: false, scrollbarConstructor: “MinimalScrollbar” on the grid to get JS-driven auto-showing/auto-hiding scrollbars regardless of platform. In this case, floatingScrollbars is defaulted to true, but you can set it to false if you want - however, it doesn’t look good and we recommend against this in docs - it’s not useful and just leaves blank scrollbar-space around content, in which the auto-show scrollbars will appear when needed.
As to the bug about scrollers not working sometimes - this should be addressed now. Also, there were several misbehaviors with MinimalScrollbar - a) scrollers didn’t appear on widget mouseOver, but only on scroller-mouseOver. b) mouse-events were not consumed, so grids would show rollover styles and select records as a part of mouse interactions with the scroller.
The doc changes are in today’s 15.0 builds, the fixes will hit all branches in tomorrow’s builds dated May 7.