Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DatePicker doesn't work on legacy hybrid PCs (laptops with touch screens) if touch is primary pointer #169

Open
FlowIT-JIT opened this issue Sep 21, 2022 · 1 comment

Comments

@FlowIT-JIT
Copy link
Collaborator

FlowIT-JIT commented Sep 21, 2022

Severity: Low (unlikely scenario and work around is available).

Problem in short: A DatePicker control does not work properly on a PC with touch if the device considers touch to be the primary input experience, and if the device is running an outdated desktop browser.

Detailed explaination: If the device has touch as its primary pointer device then Fit.Device.OptimizeForTouch becomes true and controls are optimized for touch experiences (e.g. uses native calendar and time widgets). However, if the device also has mouse support, then the DatePicker tries to support both touch and mouse input. Unfortunately it will not work on outdated desktop browsers due to lack of support for showPicker(). We need this function to trigger the native calendar widget when clicking anywhere on the control.

On many mobile devices we can work around lack of support for showPicker() by blurring and re-focusing the control which will make the native calendar widget emerge on screen. Unfortunately this does not work on desktop browsers.

One might think this could easily be resolved using device/feature detection, and simply fall back to the desktop experience in such cases. But unfortunately this becomes harder and harder as user agent strings are simplified and we walk away from unreliable user agent parsing, and as mobile devices and traditional computer devices becomes more and more similar. For instance an iPad with a pen attached has the same pointer capabilities as a PC with a touch screen and a mouse - they both have a coarse pointer (touch) and a fine pointer (pen or mouse). The difference is that the iPad is a real mobile device where we can work around the lack of showPicker() by blurring and re-focusing the control (showPicker() will be introduced with Safari 16 though), while there is no such work around for the PC device running a desktop browser without support for showPicker().

Severity: LOW. It is unlikely that a bybrid PC will treat touch as its primary pointer device, so for the most part such devices will get controls optimized for the desktop experience where there is no problem. Secondly it's unlikely that such devices are not capable of running more recent versions of browsers that actually works properly (Chrome 99+, Safari 16+, Firefox 101+, Edge 99+ which supports the showPicker() function).

Helpful references to code relating to this issue:

Device.js is where support for touch and mouse input is detected.

This is where mouse support is added when experience is optimized for touch:

@FlowIT-JIT
Copy link
Collaborator Author

FlowIT-JIT commented Sep 21, 2022

Work around: Make sure Fit.UI does not enable touch/mobile optimizations on affected devices:

if (Fit.Device.OptimizeForTouch && Fit.Device.HasMouse && Fit.Dom.CreateElement('<input type="date">').showPicker === undefined)
{
    console.log("Disabling mobile/touch optimizations due to lack of showPicker support");
    Fit.Device.OptimizeForTouch = false;
}

This must be done before creating any controls - preferably immediately after Fit.UI has finished loading.

Downside:

  • It will disable mobile/touch optimizations for all controls, not just the DatePicker control.
  • It will affect iPad with a pen (and likely other similar devices) as these are also considered hybrid (touch + mouse/pen)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant