Object Page Layout height constantly increases when placed in a Wizard Step

[EvilPlacebo]

OpenUI5 version:
1.129.0-SNAPSHOT
Browser/version (+device/version):
Version 128.0.6613.138 (Official Build) (64-bit)
Any other tested browsers/devices(OK/FAIL):

URL (minimal example if possible):
https://jsbin.com/cebabezuna/edit?html,js,output
User/password (if required and possible - do not post any confidential information here):

Steps to reproduce the problem:

1. Create simple sap.m.Wizard with renderMode is "Page" and Dynamic Page as a container.
2. Place Object Page Layout as a content of the first Wizard Page.

What is the expected result?
Object Page Layout height is stable and is correspondive to its content height
What happens instead?
Object Page Layout height has infinite growth
Any other information? (attach screenshot if possible)
Hi Team,
Basically this issue is a successor of #2514 but the surrounding container is different and I'm not sure that the same solution could be applied here. Additionally as you can see in the code example https://me.sap.com/notes/0002390659 did not help either, as setting View height to 100% give no effect.

Regards,
Ivan

[i556484]

Hello @EvilPlacebo ,
Thank you for sharing this finding. I've created an internal incident DINC0269380. The status of the issue will be updated here in GitHub.

[stephania87]

I would rather suggest you a redesign which is not nesting 3 different page layouts into each other (DynamicPage> Wizard> ObjectPageLayout ). The ObjectPageLayout can have a fixed height property or it expects height from its container while the Wizard will resize or add scrollbars based on its content size (renderType and scroll area based on the height property). The DynamicPage is also a responsive control that can get the size of the viewport or the content (check fitContent property in the public API).

If you keep that structure, then each container will have to provide size for its content for the scrolling to work, where for the ObjectPageLayout as inner-most container the option is only fixed height value. Multiple scroll containers can occur though per container, which is usually undesired by UX. Adding a top-most container like sap.m.App is also required for the used page layouts. And currently, WizardStep is not an individual scroll container, the whole wizard is a scroll container.

So this question can be turned into a feature request for the option to have different WizardStep rendering options for future, which will allow you to turn a WizardStep container into a scrollarea or fixed height container. Clarify if we shall proceed with that.

[EvilPlacebo]

So this question can be turned into a feature request for the option to have different WizardStep rendering options for future, which will allow you to turn a WizardStep container into a scrollarea or fixed height container. Clarify if we shall proceed with that.

Hi @stephania87,
Thanks for the detailed answer. I would vote for a feature request, as from my point of view, Wizard Step rendering options need some love. As I have another scenario where TreeTable is placed inside the WizardStep and with rowmodes:Auto option, it renders always minRowCount amount of Rows leaving big gap between the TreeTable and footer. That's another story, but I assume those issues both have a root cause in WizardStep rendering options.

[stephania87]

It is the same reason, yes. The WizardStep doesn't provide height, rather it expects height from the content. Thus auto row height for grid tables cannot be calculated. If you use grid tables in ObjectPageSubSection, there will be the same case, even though there are CSS options to stretch a sub section ( see public API for sapUxAPObjectPageSubSectionFitContainer).

The question about the WizardStep as a container is under review by devs.