SplitterLayout: SplitterElement size not retained when resized
Closed this issue ยท 16 comments
Describe the bug
Our SplitterLayout has two SplitterElements.
By default the width of the Splitter is 1rem. But our application requirement is 4px. So, we have added a style to make the splitter 4px.
.splitterLayout > div[class*="Splitter-splitter"] {
width: 4px;
min-width: 4px;
background-color: #dedede;
}
Since the drag button is still 1rem, it is draggle over that area. I have added a border to the drag button in the repro to show the area where its draggable.
Problem:
When the button is dragged from left side of the draggable area that is outside of the Splitter width, the SplitterElement is reset to its min size every time
Isolated Example
https://codesandbox.io/p/github/vishnuvardhan-sairam/ui5-webcomponents-splitter
Reproduction steps
1.Resize splitter from left side of the Splitter Button
2.Notice that the SplitterElement is resized to its min-width every-time
Expected Behaviour
It should retain the size of the SplitterElement
Screenshots or Videos
UI5.Webcomponents.Issue.mov
UI5 Web Components for React Version
1.26.0
UI5 Web Components Version
1.23.1
Browser
Chrome
Operating System
MacOS 14.3.1
Additional Context
No response
Relevant log output
No response
Organization
SAP
Declaration
- Iโm not disclosing any internal or sensitive information.
we moved to StackBlitz as our preferred web IDE/sandbox as it's not possible anymore to edit (fork) codeSandboxes with a free plan.
The Splitter is implemented according to our design guidelines and customizing it is not supported.
If you still want to change it you can probably overwrite the value of the internal CSS variable --_ui5wcr-SplitterSize
. When doing so, please keep in mind that internal styles are not subject to semantic versioning and can therefore change without notice.
Hi @Lukas742
Thanks for the quick response. For some reason StackBlitz was not loading for me in office wifi but noted.
I understand that overriding the CSS is causing the issue. Is there anyway that the library can provide a way to customise the width of the Splitter and the Splitter icon size. Because, I see no other direct ways to fix this issue that we are facing.
Thanks,
Vishnu.
the styling is not intended to be changed, the main reasons for this are i.a.
- Apps using different technologies (e.g. SAPUI5/React) should still have the same look and feel
- UX could suffer as some styles can look broken if CSS is changed, especially if the app supports different content density modes or theming.
- It could lead to problems for a11y, e.g. contrast ratio
Also, I mentioned a way for you to overstyle the size of the splitter:
If you still want to change it you can probably overwrite the value of the internal CSS variable --_ui5wcr-SplitterSize. When doing so, please keep in mind that internal styles are not subject to semantic versioning and can therefore change without notice.
Did you try that already?
Thanks @Lukas742 . I understand. And yes, I had tried changing the CSS variable. It changed the style properly, but the issue still exists!
Did you check if the selector has a higher specificity? Otherwise it won't overwrite the css var of the component, because of injection order of css-modules.
https://stackblitz.com/edit/github-7x8sx6?file=src%2FApp.tsx,src%2Findex.css
Hi @Lukas742 , sorry for getting back late. Yes, my styles are injected and the width is changed. However, the issue still exists in the stackblitz repro you provided and I understand its because of trying to change the default width of the Splitter.
Spliter.Resize.mov
Let me know if this can be fixed from your end in any way, because from my side, I don't see any solution :(
The issue happens when I grab from left side of the splitter icon, and it doesn't stay at the position dragged.
I tried to reproduce the behavior with different browsers, but unfortunately wasn't able to. Could you please provide information about your:
- OS
- Browser
- Screen Resolution
- Viewport size (dimensions of the window)
Also please check if this behavior occurs for all viewport sizes and when rendered outside of an iframe ("Open Preview in new Tab")
OS: MacOS 14.3.1
Browser: Chrome, Safari
Screen Resolution: 16-inch (3456 ร 2234)
Viewport size: 1728 x 885
The issue is consistently reproducible when we grab from left of the grabber icon. You can refer the previous video the place where I start dragging the grabber.
Thanks @vishnuvardhan-s I now was able to reproduce this issue. It turns out that this behavior also occurs with our standard implementation, but only in a 1px range which is probably the reason why it wasn't discovered earlier.
This PR will fix the issue.
Since the bug isn't mainly due to custom implementations, I'll reopen the issue and link the PR for easier tracking.
Thanks Lukas! Much appreciated. I see you have pushed a fix.
How can I test out this change?
Hi @Lukas742 ,
I was not able to get your changes via npm, so I manually did changes myself and tried out
Unfortunately the issue still exists :(
I put logpoints in the line where the cursor position and the splitter offsetLeft is compared in the video for better understanding.
Looks like cursor position can be less than the splitter offsetLeft and still be draggable.
How to reproduce?: I downloaded your stackblitz changes and the made the changes manually
in the node_modules and then deleted .vite folder from node_modules before starting dev server again.
Thank you for fixing it in the first place, but can you please handle this scenario as well.
Splitter.size.not.retained.mp4
You are correct, locally the changes I made did fix the issue, but for some reason this is not the case when bundled. I'll try to find another way to fix this.
๐ This issue has been resolved in version v1.27.0 ๐
The release is available on v1.27.0
Your semantic-release bot ๐ฆ๐
Hi @Lukas742!!
After upgrading to 1.27.0, the issue is no longer there๐
Thank you so much for fixing this
@Lukas742 can we have this fix backport to 1.26.1 + Patch?
we usually only downport fixes for critical bugs. Please let us know why you need this fix downported and especially why you can't update to v1.27.0.