Vertical ScrollView in web app build

Vertical list scrolling doesn’t appear to work in a webapp build viewed on my Samsung.

I was hoping that webapp views would behave like the mobile view does in the simulator app on my phone but vertical scrolling affects the entire page (even though I have scrolling disabled at the page level).

Is this a known issue?

BTW, horizontal scrolling in rows nested inside a vertical scrolling list DOES work in a web app build … with the exception that vertical scrolling attempts scroll the entire page in which the rows horizontally scroll.

Answered here: Adding a non-REST data resource

But I started to think that if after you try to limit Scroll view size in some ways scrolling still doesn’t work, send a few screenshots of the configuration here and maybe share your app ID so I could see if I can figure out a way to make this work (I such exists to begin with which I think it does)

Thanks! I’ll give that a try. Maybe I can do that via percentage-based dimensions since I want this to be multi-device.

I don’t actually know where the appID is but I’ll look for it and share.

:+1: Let’s hope you’ll find a solution

App ID is part of the Composer URL when you have the app open: Where can I find my APP ID

Thanks! Great to have such fast and on-target responses!

I’ll find the appid and add it to the thread today.

Tried an 80% height on the scrolllist container with no obvious effect on the webapp build … but I’m wondering if the webapp builder is using my latest saved version in Composer? … and how to tell?

The build seems to show a list of historical builds but only shows the Composer version used … not the app version and no date time stamp on the builds.

Might be very helpful to have those. :slight_smile:
My appID is 159674

Having built a few now I see the list is “latest build first” and adds a “queued” label for pending builds. Good … but the detail would be better, I think.

Regarding the container limit, that seems to have fixed the whole page scroll problem in the desktop preview … but at the cost of dropping out the last x of 13 items in my list; x being dependent on vertical height of the display area of the device … and had no effect on the desktop latest build view which still scrolls the whole page.

So, it seems there’s some interplay of container height, scroll list height, and device display. This makes sense since they are percentages of percentages of a variable … but it makes it tricky to understand and control the scroll list’s ability to actually show all items on the list.

Probably needs some attention.

Next step is to set the list ietms’ height to percentage as well … and then remove the empty container at the end of the scroll list (suggested elsewhere as a fix) and try to sort out the interplay of these settings.

Thanks for you responses!
Cheers :slight_smile:

Ahhh…some accidentally found info!

If I scroll the whole page in the webapp preview, the scrollist shows all items in the list.
If I DON’T scroll the whole page view, the scroll list truncates as noted above.

So the items are “there” … but the scroll list doesn’t scroll completely unless the whole page is scrolled.

This is the case on the Composer desktop preview of the webapp.

Checking on mobile webapp…

I should add that these are minor difficulties within a Composer system that is, in my view, INCREDIBLY well-conceived and executed … and it seems some easy tweaks can be made to make it even more seamless in deployment across devices/OS’s!


The mobile version of the latest webapp build with container %height. on my Samsung Galaxy scrolled the first 12 items … so one item short.

Waiting on the build that has both container AND scroll list %height.

So, the bottomline seems to be that setting the percentage height in the scroll list container and/or the scroll list itself SORT OF fixes both the missing items in the list AND the list scrolling problem … but with a consistent caveat:

The list will scroll to its the last row of a truncated list in the display (whether desktop preview from Composer, Appgyver preview app preview, or mobile build) but when the end of the truncated list is reached continued scrolling affects the whole page and missing rows come into view.

On the desktop build, the whole page still scrolls if there’s no empty container at the bottom of the scroll list.

I’ll work with this more tomorrow to see if the percentage height setting for the scroll list affects how many row items are seen before the whole page scrolls to reveal the rest.

I’ll attach the results on my Samsung with the current app design. It varies between the Preview app view, the built view of the same webapp in Chrome, and the built view of the same webapp in DuckDuckGo.

Here’s the recording of the webapp on my desktop in Chrome:

The latest update:

After some hours had passed, the above-recorded variations of things like viewable scroll list size went away (maybe a propagation timing issue? I had cleared my cache before loading and recording the webapp above. I’m in Bulgaria so maybe there’s some sort of lag in the built version propagaing across servers??) and things became pretty consistent.

The Appgyver app selector preview on mobile behaves as intended with the scroll list scrolling within a stationary page.

The built webapp in the browser and the Composer preview scroll a partial list first then scroll the whole page to display the rest of the list.

Recordings attached.