Table gets wrong selection mode on laptops with touch screens

[vaadin-bot]

Originally by @vaadin-marcus

---

VScrollTable sets the multiselect mode based on a check if a device supports touch events. As many business laptops are now equipped with both touch screens and physical keyboards/mice, this isn't optimal.

    private void setMultiSelectMode(int multiselectmode) {
        if (BrowserInfo.get().isTouchDevice()) {
            // Always use the simple mode for touch devices that do not have
            // shift/ctrl keys
            this.multiselectmode = MULTISELECT_MODE_SIMPLE;
        } else {
            this.multiselectmode = multiselectmode;
        }
    }

---

Imported from https://dev.vaadin.com/ issue #16808

[vaadin-bot]

Originally by juanitae@fireapps.com

---

For our application, we would like to indicate the primary input devices, which are the mouse and keyboard. Because of the complexity of the UI, we do not expect our users to use their touchscreens very much, if at all, when interacting with our application.

[vaadin-bot]

Originally by freddyertl

---

What happens with this issue? This renders multiselection useless on touch-enabled laptops. There should be at least a way to override the behavior.

[vaadin-bot]

Originally by @samie

---

Looks to me that this has been disabled by purpose at the time. On Winows/iOS/Android test:

• Enable multiselection regardless of isTouchDevice
• Check if ctrl/shift selection could also work when keyboard

[vaadin-bot]

Originally by freddyertl

---

If it cannot be determined whether you have a real touch-only device or just a touch-enabled computer, you have to leave it to the developer to decide what to do with it. Making such a decision deep in the code without the possiblity to override is not good.

[vaadin-bot]

Originally by juanitae@fireapps.com

---

For our application it would work quite well for us to set the primary input mode. In our case the mouse and keyboard are primary and we do not want the application to adjust behavior based on the existence of a touch screen.

In general, it is a valuable framework implementation technique to consider what a user potentially may want to adjust, and design your classes so that the adjustment is possible whether via parameterization or inheritance. You can find many design articles about the contract between subclass and superclass, and what considerations should be given.

[vaadin-bot]

Originally by juanitae@fireapps.com

---

Attention: Increased problem scope. Originally we only experienced this problem with Chrome browsers on laptops with touch screens. Now with recent changes inn Windows software stack, we have the same problem on Windows 10 with both Edge and IE11 browsers.

Please modify the Table framework to allow application developers to specify primary input mode, as described previously.

[vaadin-bot]

Originally by @TatuLund

---

Changed type of ticket to "enhancement", since current behavior is as specified. Hybrid devices is a new emerging device group and hence supporting these is categorized as enhancement.

[stale[bot]]

A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time. No further work will be done on this ticket. If the ticket seems to be still actual, please verify the problem existence over latest framework version and then open a new ticket in vaadin/framework with all the suitable information.

[TatuLund]

In version 7.7.20 setMultiSelectTouchDetectionEnabled(boolean) was added so that Table can be forced not to detect touch mode.