Spreadsheet shows touch indicators when using on desktop with mouse and keyboard.

[Peppe]

Spreadsheet has to modes: touchMode=true and touchMode=false. Which one is used is determined by asking GWT's TouchEvent class. https://github.com/vaadin/spreadsheet/blob/master/vaadin-spreadsheet/src/main/java/com/vaadin/addon/spreadsheet/client/SpreadsheetWidget.java#L196

setTouchMode(TouchEvent.isSupported());

This means that desktops with touch screens will be reported as touch devices. This can't be overriden in any way - it is done on the client side.

The side effect of this is that desktop devices with touch screens will show a bunch of touch indicators which are obtrusive when working with Spreadsheet. The biggest culprit of them all is the mobile-device-oriented "fill"-button that pops up every time you select a row. It block reading data above the cell you are typing in. Link to code that puts it on the screen here.

There is no way to configure the boolean touchMode, and you can't hide the popup with CSS as it does not have any spreadsheet specific class names and it is within body in the DOM.

• The feature needs to be better targeted towards primary touch devices
• Touchmode should be possible to disable by server side api
• The popup should have a unique class name
• The gesture for opening the menu should not be a simple touch, a long touch would for example work better.

Relevant discussion on the forum.

[OlliTietavainenVaadin]

Related issue: https://github.com/vaadin/spreadsheet/issues/430

[QNENet]

This problem seems to have been ignored. A fix is important as the Spreadsheet is unusable as is with mobiles. This is a paid for Pro item and needs attention.

[WoozyG]

The nice thing about JavaScript, there is no real "private" anything. If you know what logic you want, you can subclass Spreadsheet, make your own SpreadsheetConnector, and use native JS to to flip the flag dynamically.

[WoozyG]

Long-press is a nice way to dynamically adjust state on a touch device, but since cells already support a right-click menu, moving the "Fill" option to a context menu won't work without significant disruption for existing customers, and there would be training involved, as users wouldn't know they had options unless they are the type to try long-pressing everything just to see what happens (like me).

I'd solve it by adjusting the logic in the client-side code to set the touchMode flag only if the OS is iOS or Android. Those are guaranteed to have touch, and very few people use Android with a mouse (Android-x86, for example, or Android apps on ChromeOS).

However, it fails to account for devices like a Surface tablet, where the user may disconnect the keyboard/mouse/touchpad and use it as a touch-only tablet. According to the Internet, browsers don't report different User-Agent values for the two Windows modes.

This comment sums up the issues nicely, with no silver bullet.

I'd be in favor of doing the mobile OS check as a default, and allowing apps to set the mode explicitly for a VaadinSession. Then apps that need to do so can do things like define their own detection algorithm based on their user base, or add a UI element or user/session preference item allowing the end user to decide for themselves their preferred behavior.

Short of a Vaadin change to allow this sort of dynamic control, my comment above about doing it on the client via GWT with direct JS is the best I can think of.