My application is using a com.vaadin.flow.component.applayout.AppLayout with a header and a drawer (a standard layout inspired by misc. example programs). The lower right content part is populated with VerticalLayouts that have a #Route(value="foobar", layout = MainLayout.class) annotation, so when clicking on one of the "anchors" in the drawer the corresponding view is added.
That works all nice except for one thing that annoys me:
One of my views has four Accordion components (2 containing a couple of labels and a TextArea each, one containing some textfields and a chart. The forth contains some text fields and a button).
When I unfold these accordions then typically when expanding the third or fourth there is suddenly a second vertical scrollbar appearing just inside the outer, normal scrollbar. Already two opened accordions are higher than what fits a typical browser window, but here the size and the scrollbar is adjusted correctly. Sometimes, but strange enough not always, the scrollbar also adjusts properly with three opened accordions. Sometimes already with the 3rd, but definitely always with the 4th accordion that second scrollbar appears. The combination of opened accordions does not seem to play a role, i.e. there is no accordion that ALWAYS triggers that scrollbar appearing.
I find this second scrollbar most irritating and annoying when navigating the page. Any idea what could cause this? And how to force a single scrollbar only?
BTW: I experimented with wrapping the entire content inside a Div but that didn't change anything - the second scrollbar still appears as described above.
Related
The bounty expires in 4 days. Answers to this question are eligible for a +50 reputation bounty.
Allen Y wants to draw more attention to this question.
My app's main screen is relatively simple - a header, a main body that's primarily a text input, and a footer. It's set up like this (I'm simplifying the code to just call out the major structural items):
SafeAreaProvider
SafeAreaView // flex: 1
KeyboardAvoidingView // behavior="height", flex: 1, children also have flex: 1
Header // fixed height, no flexGrow
Swipeable // This lets the user swipe the input left or right; set to flexGrow: 1 and children have style flexGrow: 1
View
TextInput // multiline
Footer // fixed height, no flexGrow
The bug is that this combination of elements isn't working as I'd expect. First, when the screen first loads, it looks like this, with an empty gap between the footer and the keyboard:
Moving to a different screen then back results in the keyboard showing, but the footer getting pushed all the way to the bottom of the screen, ie into the part where SafeArea is supposed to prevent it from going and hidden by the keyboard:
Why is that white gap showing on screen load, and why does the footer go into the SafeArea when the keyboard is dismissed?
Addendum: frustratingly, this bug does not repro when running the app locally on Expo Go - the Footer is flush against the top of the keyboard.
Addendum 2: A mystifying thing about this bug is that it doesn't seem to be consistent. For example, the observation from my original post about going to another screen and back resulting in the footer being too far down into the safearea exclusion part does not happen consistently. Now when I'm loading the app (I haven't changed anything), going to another screen and back results in the Footer being above the safearea exclusion zone as I'd expect.
I wonder if this inconsistency suggests it's some kind of race condition between different parts of the frontend?
can you add this prop in KeyboardAvoidingView
keyboardVerticalOffset={-80}
adjust with your requirements
Vaadin Version: 23.3.3
I have a fairly complex Vaadin table, ~100 rows, each of which contains ~12 columns, each column containing a layout with ~10 elements. The table is not lazy in any way, and is configured to show all rows at once.
It takes the browser 5+ seconds just to render the table after the request is complete (a topic for a different question) but even once the table is rendered I experience some weirdness when scrolling.
When holding the mouse outside the table, or using the scroll bar, the page always scrolls as expected. But when I hold the mouse inside the table I get inconsistent results. If I have first scrolled the page all the way to the bottom then there appears to be no issue regardless of mouse position. But If I have yet to scroll to the bottom, then the table scrolls in place, pushing rows underneath the header (see screenshot). It's as if the browser/vaadin is not yet completely aware of the size of the table?
Is there something I need to be doing to force vaadin to render the entire page?
Edit: Upon some further testing I noticed even stranger inconsistencies. My table cells have two possible layouts depending on user actions. One is simple, containing: div > span > span. The other is more complex, containing a div > span > span + vaadin-icon + tooltip. The issue only appears when the table is rendered with the "simple" layout. Something about the added vaadin-icon and tooltip seems to make vaadin draw the table without scroll issues.
I'm doing some UIAutomation testing using Xcode Instruments and have an issue accessing a staticText which I want to verify.
The situation:
I have some buttons that display different scroll views that contain multiple charts. These scroll views have 5+ items in each so when i initially do target.logElementTree() it only shows the visible ones. If i scroll down with window.scrollViews()[0].scrollDown() and again get a logElementTree() the bottom elements are shown however whenever i try to access them it keeps referring to the ones from the top of the scroll view.
Any ideas?
Cheers.
As per as my experience, whenever you do "taregt.logElementTree()", it will display you all the elements (visible & hidden or which are present even at the bottom of screen) which you can access by its name or index or position once scrolled down. But if you still face problem, I will recommend you to access the element by its position after scrolling down to make it visible.
Using jquery-ui's sortable plug-in, I have two connected lists that have scroll bars. I would like to be able to scroll as i drag an element from either list. Current behavior of the Sortable plugin is that if you have the scroll:true option, and no ui-helper (or a ui-helper that is appended to its original list) then the scrolling and dragging will only happen in this list and not the ones connected to it. If you have it appended to a div that contains all connected lists, then it won't scroll as you drag at all. Does anyone have a work around for this?
Here's my specific situation in more detail:
I have two connected list one below the other. The one on the top has a scroll bar. If I a drag an element from the top list to the bottom list, the scroll bars don't scroll down with the element, but the element's placeholder still stays in that list (just the hidden part that is not scrolled to). So, if i drop it there, it gets dropped in the top list rather than in the bottom list. This especially happens if the bottom list is empty.
I have a ui-helper appended to a div that contains all the connected lists.
Is there a way to make the scroll area scroll with the element? A less desirable, but still acceptable, alternative would be a way to make it prefer (on dropping) the list that is visible.
I came across this question. I see that both stickyHeader and scroller works kind of the same in the way that they both keep the header row visible and there's a scroller bar on the side. Could someone please kindly explain the difference between them?
The stickyHeader widget makes the table head "stick" to the top of the browser, or table container (if options are set), window as the user scrolls down the table; this is similar to the sticky menu some sites use for site navigation. Check out this demo especially the last one on that page which is an example of nested tables stacking the sticky headers while you scroll down the document. There is also a css3 version of this widget which uses css3 transforms to position the table head at the top of the browser window.
The scroller widget, on the other hand, has to make a copy of the table header placed above the table, hides the original table header, then makes the tbody of the table scrollable, within a fixed height. So, the browser window position doesn't change which the user is scrolling through the table content, just a scrollable window of content is seen. If you look at this demo, you'll see that the table body is scrollable, but the head does not "stick" to the browser window (unless you set the scroller_jumpToHeader which forces the table head to become visible while scrolling up the document.