Random zero-length horizontal scroll bar in flexgrid

Posted by: daniel.feryance on 11 December 2024, 5:55 pm EST

  • Posted 11 December 2024, 5:55 pm EST

    We’ve been seeing a strange issue in the Wijimo flexgrid since we upgraded to 5.20241.19. We have a few fixed size columns and the last column is a star-sized column. Sometimes we see the horizontal scrollbar display in the grid even when there is enough space horizontally where scrolling isn’t needed. It isn’t possible to scroll with this bar as there is nothing to scroll to. We cannot set it to hidden because there are cases where users do need to scroll.

    I was able to trace the problem to being triggered by the last star-sized column. Getting rid of it solves the problem, but we do need that in place. I get the sense that the sizing calculations that resize the star-sized column are so close to the exact grid width that the browser sometimes decides to show the scroll bar anyway.

    Reproducing is tricky and strange, sometimes if we change something else in the DOM, it shows up or hides. Usually we see it show up and hide while scrolling. Just poking around in the chrome dev tools sometimes causes it to hide. This is why it feels like a precision issue or possibly related to browser sub-pixel handling.

    Is there anything we can do to still have the star-sized column but give it a little extra horizontal space? Maybe always subtract a pixel from the calculated size? I tried adding paddings or margins but it seems the sizing calculations already take that into account. There is an event handler for when the star sized gets resized but it seems that gets triggered after the sizing is done which is too late.

    Or any other ideas what we can try? I’ve been working on trying to create a more minimal way to reproduce than our full application. It is tricky due to unrelated DOM elements seeming to impact it.

  • Posted 12 December 2024, 6:36 am EST

    Hi Daniel,

    When star sizing is used in the Flexgrid columns then while decreasing the size of the grid, a horizontal scrollbar appears for a fraction of time, if this is the issue you are facing then this behavior is expected, as the grid re-calculates the column size at that time and updates the column size, after which the scrollbar disappears.

    If the scrollbar doesn’t disappear in your case, then it might be a bug in flexgrid, please share the sample in which you are trying to replicate the issue, when complete so that we can investigate the issue further and assist you accordingly.

    Please refer to the following sample in which we tried to replicate the issue - https://stackblitz.com/edit/js-w8fyk1f7?file=index.js

    You can also modify the above sample to replicate the issue and share it with us.

    Also, there is an event that is triggered when any column in grid is auto-sized due to star sizing, i.e. starSizedColumns event. Here’s the API link for the same - https://developer.mescius.com/wijmo/api/classes/wijmo_grid.flexgrid.html#starsizedcolumns

    Regards

  • Posted 18 December 2024, 2:13 pm EST

    Hi Vivek,

    The visibility behavior of the scroll bar is strange. Sometimes it disappears right away, sometimes it stays and sometimes it flashes visible / hidden quickly. I found a way to reproduce it in a minimal example project I have attached. It seems to depend on some specifics of the CSS layout which I cannot safely change in the project I am on. I made sure to have this example match the layout where it mattered.

    I can reproduce this in Chrome 131.0.6778.86 on Windows. When dragging the middle portion of the scroll bar, you see the horizontal scrollbar flash visible and hidden constantly. When scrolling with the mouse wheel, the extra scrollbar usually shows up, unless you resize a column or do something else.

    angular-grid.zip

  • Posted 19 December 2024, 8:50 am EST

    Hi Daniel,

    Thank you for sharing the sample, we are investigating the issue. Currently, it seems to be occurring due to some specific CSS configuration. It may take some time to find the root cause of the issue, we will share an update soon. For now, as a workaround use the following CSS on flexgrid -

    .wj-flexgrid{
      width: fit-content;
      min-width: 100%;
    }

    The CSS seems to be working in the sample you shared, however, please let us know if this doesn’t resolve the issue in your actual project.

    Regards

  • Posted 19 December 2024, 11:24 am EST

    Thanks for looking into this. The CSS workaround you suggest doesn’t work because our grid is resizable being nested in a splitter control. The grid will grow when resizing but won’t shrink with this CSS set.

    Yeah, I’ve been quite puzzled by this problem for a while. It took a lot of trial and error on removing code to get it to that minimal example. I wouldn’t rule out a Chrome bug or behavior change too. It seems to work ok in Firefox. I suspect it has something to do with flexbox as I haven’t been able to reproduce it without flexbox. But I haven’t been able to find a workaround without making a change that breaks our project in some other way.

  • Posted 20 December 2024, 9:22 am EST

    Hi Daniel,

    We are still investigating the root cause of this issue, it might be possible that it is a browser-specific issue, we are able to replicate the issue in Chrome and Edge browsers. We will share more updates with you soon.

    Regarding the workaround, please try setting the ‘width’ property of the parent element of the FlexGrid, setting the width to 100% on ‘.guide-panel’ class worked in the sample you shared, or you can also try setting the ‘overflow: hidden’ on ‘.guide-panel’ class if that works for you.

    Regards

  • Posted 23 December 2024, 7:07 am EST

    Hi Daniel,

    We have forwarded this issue to the engineering team for further investigation. We will share an update with you as soon as we have an update from the engineering team.

    Regards

  • Posted 27 December 2024, 7:00 am EST

    Hi Daniel,

    Could you please confirm if the workaround we shared in our previous comment is working fine in your project or not?

    Also, the engineering team wants more detailed information about your use case, as this issue is replicable in a very specific scenario. It will help us evaluate the issue better and take appropriate steps to address the issue as needed.

    Regards

  • Posted 31 December 2024, 9:58 am EST

    Hi,

    I haven’t been able to get the workaround to fix it. Yes, it works in the sample app I provided, but in the main application I still see the problem. I tried propagating the css up to some of the parent containers but still see the problem. The one css workaround I found that does solve it is to move the grid container to position:absolute. But we’ve found that it breaks some of our other code.

    For the use case, we use the wijimo grid in several different applications and usages. We have it wrapped in a shared library which makes it difficult to make significant of changes as it can impact all our applications. We display the grids primarily within splitter panes. So the size of the grids are often changed by the users. All grids have pixel-sized columns but the last column is a filler that is star-sized. We use flexbox column layout as the panels containing the grids often have toolbars or footers too. Everything requires vertical scrolling (with dynamic data loading). Horizontal scrolling is needed depending on the data and the splitter position.

    I traced some of the logic into the wijimo bundle where it is calculating the star-sized column. There is some rounding code there. Maybe an additional fudge factor would work? I suspect there is some inconsistency between the calculation of the available width left for the star-sized column and what the browser will allow. Possibly related to floating-point sizes? I noticed that with the splitters, we do not have the grids at integer pixel boundaries.

    Hope that helps.

  • Posted 2 January 2025, 8:38 am EST

    Hi Daniel,

    Thank you for sharing the additional information. After doing some more investigation, it seems the issue arises due to CSS in a very specific scenario. We have prepared a workaround that updates the overflow visibility on the root part of the grid by handling the ‘updatedLayout’ event of the FlexGrid. This will make sure that the scrollbar only appears when needed. Please refer to the following code snippet for the same -

    initialized(grid: FlexGrid) {
        grid.updatedLayout.addHandler((s, e) => {
          let host = s.hostElement.querySelector('div[wj-part="root"]');
          if (host) {
            let clientWidth = host.clientWidth;
            let scrollWidth = host.scrollWidth;
            wjcCore.toggleClass(host, 'hide-scrollbar', scrollWidth <= clientWidth);
          }
        });
    
        grid.onUpdatedLayout();
      }
    
    // CSS
    .hide-scrollbar {
      overflow-x: hidden !important;
    }

    Regarding the star-sizing, it seems star sizing not actually creating the issue, the same behavior could be observed after setting a specific width to the columns and resizing the grid, to nearly the same or slightly greater size as of the columns. The issue replicates with star-sizing each time because columns are resized to fit the grid width.

    Also, we tried to replicate this behavior in older Wijmo versions and found that the same behavior was observed in older versions also, you can verify it in the following sample with different wijmo versions - https://stackblitz.com/edit/js-gsvpwxcr?file=index.js.

    We are not really sure about the Wijmo version that you were using earlier in which the issue was not observed. Please let us know, if there is any specific wijmo version after which the issue could be observed.

    We will update you when we have more information from the engineering team. Meanwhile, please confirm whether this new workaround works as expected or not.

    Regards

  • Posted 3 January 2025, 6:17 pm EST

    Hi Vivek,

    Thank you for the help on this. So far, your latest workaround appears to be working! The fix hasn’t made it’s way to QA yet, so we have more testing to do, but it seems quite promising. I had to remove the direct grid.onUpdatedLayout call as it was causing issues in some of other other code but it is working fine without it.

    One challenge is that we upgraded multiple packages at the same time. We upgraded bootstrap, angular, wijimo and a couple other packages. So it is possible (even likely) that these upgrades changed our CSS layout which triggered this problem. A lot of the issues we encountered when upgrading was CSS related. It also is possible this is triggered by more recent Chrome builds. So that would explain why you may see this with older versions.

    The version of wijimo that we were using was 5.20202.724. So this was a large jump of an upgrade.

    I’ll let you know if we encounter any issues with the workaround but so far I am quite happy with it. The solution seems low-risk to our existing code and makes sense.

    Thanks,

    Dan

  • Posted 6 January 2025, 2:41 am EST

    Hi Daniel,

    Thank you for sharing this information, we have shared all this information with the engineering team. We will share an update with you when we have an update from the engineering team. The internal tracking ID for the case is - WJM-35475, we forgot to mention it in our previous comment.

    Regards

  • Posted 7 January 2025, 12:49 pm EST

    Hi Vivek,

    This is tricky due to the timing of several upgrades we did all at once, but at this point I think Chrome is the likely cause. I went back and ran older builds of our software using the older grid and angular code and I still see the scrollbar issue. While I know for sure we didn’t have this problem when that was the version we shipped. This points to some kind of chrome change possibly being the trigger.

  • Posted 8 January 2025, 4:51 am EST

    Hi Daniel,

    It might be possible that the Chrome version upgrades have triggered the issue. We have an update from the engineering team, that behavior in Wijmo FlexGrid across all Wijmo versions seems consistent, and the issue seems to be occurring only due to other package upgrades or CSS changes and does not seem to originate from Wijmo. So, the engineering team has suggested to use the workaround to avoid this issue.

    In case, you have any further details that could indicate that the issue originated from FlexGrid itself, then please let us know.

    Regards

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels