Add a viewport size threshold for fullscreen mode

[Saulis]

The fullscreen mode should not depend on any user agent detection. The viewport size is the only thing that should trigger it (but it does not need to adapt when the item display is open).

The threshold should detect both viewport width and viewport height, and take the smallest of those. If either is under 600px, then use fullscreen.

[tomivirkki]

Determining fullscreen should not rely on screen size only. If your desktop browser height/width is below 600 initially for some reason, then you're stuck with fullscreen comboboxes even if you resize the browser. So how about using the current approach (checking if a touch device in use) but enforce it with the size check?

[jouni]

Can’t the check be made each time the list is opened?

[tomivirkki]

Seems like it's not a problem changing the "fullScreen" property dynamically so should work ok

[jouni]

If we want to use the "desktop" mode for iPad, we need to consider that we can no longer use position: fixed; for the dropdown.

[tomivirkki]

Problem with IOS devices that need desktop mode: iron-dropdown relies on the overlay having position:fixed and iron-fit-behavior calculating the top/left values for it automatically. Works fine until you focus an input field (which is what vaadin-combo-box does on dropdown open) on an iOS device and all fixed elements become absolute all of a sudden. Top and left values are not updated so the overlay gets misplaced.

What we could do is to force the overlay to position:absolute on IOS devices in all cases (not just fullscreen as it currently is) and position it with CSS (left: 0; top: 100%; bottom: 100% when aligned to bottom).

One remaining problem is that with top-aligned dropdown much of it stays visible but some of it might get hidden under the opened virtual keyboard (because the keyboard height isn't reduced from viewport height while iron-fit-behavior determines the available remaining space for the dropdown).

One solution would be to hide the keyboard whenever the list is scrolled in IOS non-fullscreen (as we do in fullscreen mode currently) – this would however require iPad users to re-focus the input field for additional filtering.

[jouni]

Instead of just top and bottom alignments, we could consider left and right aligned dropdowns as well (as in my original mockup designs from over a year ago). It will still require some tricks to either reduce the keyboard size from the viewport height or hiding the keyboard when scrolling the list. But I think overall it might be a better option, especially in landscape orientation.

[tomivirkki]

+1 Just need to figure out the keyboard problem. Measuring its height might not be an option. Took another look into it but still can't figure out a way to get the accurate measurements.

[jouni]

Targeted behavior:

• Use Math.min(viewport width, viewport height) to determine when to use the fullscreen layout (instead of the current TouchEvent sniffing)
  • Export viewport threshold so that the developer can customize it
  • Use this property for testing (no need to add new devices to Sauce Labs)
• Use the same solution as for iPhone on iPad as well, that the keyboard is hidden when the user scrolls the list
• Split from this reseach: Support left and right alignment for the dropdown

[jojule]

iPad Pro looks quite ridiculous in full screen mode.

[jouni]

Exactly. Will be addressed as described in my previous comment.

[Saulis]

Running desktop mode in touch devices has proven to have some UX challenges because of the virtual keyboard. On Android, the input field can get hidden under the virtual keyboard & on iPad the scrollable list can get mostly or even totally hidden. Since <iron-dropdown> disables scrolling the viewport, the user has to either close the dropdown to enable scrolling or hide the keyboard. On both devices, I'd say the usability especially when filtering suffers a lot.

This got me thinking, instead of running desktop mode for large touch devices, should we instead continue running them in "fullscreen" mode, but improve the current UX simply by having a max-width for the list? This way the user would be able to still see the page location, but at the same time the viewport height would be used optimally.

[jouni]

@Saulis: interesting idea, which we should prototype.

[platosha]

Prototype branch: https://github.com/vaadin/vaadin-combo-box/tree/feature/fullscreen-dropdown-max-width

Currently the dropdown width is set equally to combo-box width. This is just for a quick UX evaluation, could be easily changed to any specific max-width, just a matter of changing two style lines.

[platosha]

The fullscreen dropdown is now horizontally centered inside the viewport. Another option to consider: open the fullscreen dropdown at the combo-box horizontal position, in order to minimise the user interaction context jump.

[platosha]

Known issue of the prototype: when opened on Android, the dropdown is still using full page width, max-width has no effect. Please use iPad for the prototype evaluation.

If we decide to go with max-width for fullscreen instead of the viewport threshold, it would make sense to make fullScreen property read-only. The current implementation in the master doesn't play well with on-the-fly modifications anyway. Changing fullScreen causes bugs, some of them were discovered and fixed in the viewport threshold branch

Since our touch device detection could be not perfect for everyone, we also need to provide a way (and documentation) on how to turn the fullscreen mode on and off explicitly during load/initialisation.

[Saulis]

Will be fixed by removing Fullscreen mode altogether in #105.