[Bug-13304]Dragging popup prevents text area input on tablet

I can type into a text area on a popup fine, but if I drag that popup at all I can no longer interact with that same text area. Numeric Entry Fields do not give this problem.

Using a Sony tablet, with 8.0.0-beta0 (b2019032502)

EDIT: I believe this only happens when I drag the popup partially out of the screen.
EDIT: Same result on PC when dragging partially out of screen.

If a Popup is partially off-screen, then ā€œinputā€ into the Popup is disabled until the Popup is dragged back into the screen.

This is probably less-than-ideal fro mobile devices (depending on Popup size) but was important for desktop environments, where users can configure and drag the Popup in such a way that the Close Icon and ā€œDrag-barā€ are off-screen; users could click anywhere in the popup (even on components) to drag the popup to a usable space.

If you drag you popup back into the screen, the input is still usable.

As youā€™re on a mobile device (tablet) youā€™ll need to make sure that any popups you open are entirely visible, otherwise youā€™ll essentially be locked-out of the Popup.

That makes sense, though it does cause a bit of a problem on my tablet implementation. Specifically Iā€™m displaying a popup that does fit the tablet screen but when the keyboard opens for typing into a text field, the remaining screen space shrinks and the popup no longer fits in that space.

Is it possible to make a popup size scale (similar to how regular screens can be in percent mode)? That way I wouldnā€™t have to worry about the popup ever being too large.

A Popup is just a View, so you can put it into percent mode (assuming the Popup is a Coordinate Container). Instead, you could also set the root.props.style.overflow property to ā€œscrollā€ā€¦ but I donā€™t know how the mobile virtual keyboard would affect popups which arenā€™t at the top of the pageā€¦

I think the best idea for now is to make sure that your popups always open at the top of the screen (enable set the Popupā€™s ā€œtopā€ property and leave it at ā€œ0ā€). Enabling this property and applying the overflow setting should result in a popup that always opens at the top of the screen, and which ā€œshrinksā€ to fit the available length of the screen, providing scrollbars when compressed.

My popups are Coordinate Containers but they donā€™t seem to be behaving as Iā€™d expect. I did some playing around and hereā€™s what I found:

  • Switching to percent mode Iā€™d expect the popup to fill the available screen space but it retains its defaultSize properties as it would in fixed mode.

  • Possibly related, popups ignore headers/footers so it seems like theyā€™re not even aware of the actual amount of space available. (Ie the popup overlaps the headers/footers)

  • The perspective.openPopup ā€˜resizeableā€™ parameter, I cannot get to take affect.

  • I was able to position the popup at the top of the screen using the perspective.openPopup ā€˜positionā€™ parameter (ā€˜topā€™:0), but changing root.props.style.overflow property to ā€œscrollā€ didnā€™t seem to do anything (I tried on the popup View, and also just one of my regular Views)

Any insight would be appreciated

Switching to percent mode results in the internal child components displaying as a percent of the available space (A Table 400px wide in a 800px wide Container/root would have a width of 50% if the Container/root were switched to be in percent mode). This allows for a View to display components at relative sizes, rather than induce scrollbars and hide components.

A popup would ignore a ā€œHeaderā€ if the Header has Display set to Cover (ā€œFootersā€ ALWAYS have Display set to Cover). If a Header has Display set to Push, ten the Popup will open at the bottom of the Header.

ā€œResizeableā€ appears to be a typo - it should be ā€œresizableā€. Iā€™ll reach out to the documentation team to get it cleaned up.

Scrolling:
Hmmm. I wasnā€™t positive it would work, because I donā€™t know if we can tell that the virtual keyboard is covering anything. Iā€™ll reach out to our mobile Dev and see what he has to say about it.

Ahh yes ā€˜resizableā€™ is working! And now that I can resize the popup I am able to see the effects of switching to percent mode take place - the components size are a percentage of the popups size, similar to what Iā€™ve done in other Views.
My only remaining question for this is how do I get the actual popup to scale its own size? It sounds like Iā€™d want to set the popupā€™s parent to percent mode, but Iā€™m not sure what its parent would be.

Display set to Cover: I was not aware of this, but that explains the behavior.

Scrolling: Now that I can resize the popup, I can put the popup into fixed mode, shrink the size and am able to scroll through the inner components of the popup (regardless of the root.props.style.overflow state), which is a good, but I just need a way to automatically shrink the size of the popup based on the amount of space available in general, not just regarding the tablet keyboard.

While Views adjust their size and display properties/configuration based on their dimensions in the Viewport, there is currently no visibility into those properties; this is one of the biggest requests weā€™ve been seeing in the last couple of weeks, but itā€™s also very difficult to shoe-horn in at this point. Eventually there will be something like session.props.display.width and height, but thatā€™s pretty far down the road.

As for setting the Popupā€™s ā€œparentā€ to percent mode: Popups donā€™t have ā€œparentsā€ so you canā€™t do this; Popups donā€™t take up space in a Container, so no Container can directly influence their size. You ARE able to pass parameters to Popups, but passing parameters which are dimensions based on viewport size requiresā€¦ that you have visibility into the viewport sizeā€¦

1 Like

Thanks for the explanation! Although it doesnā€™t provide me an immediate solution I think I have my head wrapped around it well enough to come up with an alternative implementation now.

2 Likes

Iā€™m happy to announce that starting tomorrow the 8.1.3 nightly builds will feature functionality that should resolve this issue.

system.perspective.openPopup and togglePopup will now have an optional viewportBound keyword argument which is used for two things:

  1. A Popup with this property set to True will be shifted to open in the bounds of the viewport, even if relatively positioned in a manner which would have opened partially off-screen. If the Popup also happens to be too big to open fully in-bounds, then the Popup will be resized to dimensions that allow for opening within the viewport bounds.
  2. A Popup with this property set to True will only allow itself to be dragged up to the boundary of the viewport and no further. This will prevent instances where Popups could have been positioned in such a way that their close Icon was rendered off-screen.

The Popup Action has this same property available to it in the bottom-right of the Action screen as ā€œViewport Boundā€.

Please note that this property is False by default so as to not interfere with existing usages. To take advantage of this functionality, you must update current usages.

5 Likes