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

Better recognition of touch devices #1653

Merged
merged 6 commits into from
Apr 21, 2020

Conversation

dmtrKovalenko
Copy link
Member

@dmtrKovalenko dmtrKovalenko commented Apr 13, 2020

This PR closes #1649
Also closes #1664

Description

Use media (pointer: fine) (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer) which is the best way to determine touch devices. So use it to render mobile wrapper and hide focus outline.

P.S. It is not supported in IE but it is fine because we are falling back to desktop mode :)

@vercel
Copy link

vercel bot commented Apr 13, 2020

This pull request is being automatically deployed with ZEIT Now (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/mui-org/material-ui-pickers/ei6e89ngg
✅ Preview: https://material-ui-pickers-git-bugfix-desktop-responsive-breakpoint.mui-org.now.sh

@cypress
Copy link

cypress bot commented Apr 13, 2020



Test summary

73 0 1 0


Run details

Project material-ui-pickers
Status Passed
Commit 7c61217
Started Apr 21, 2020 11:09 AM
Ended Apr 21, 2020 11:10 AM
Duration 01:12 💡
OS Linux Debian - 9.11
Browser Chrome 78

View run in Cypress Dashboard ➡️


This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@codecov
Copy link

codecov bot commented Apr 13, 2020

Codecov Report

Merging #1653 into next will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##             next    #1653   +/-   ##
=======================================
  Coverage   89.76%   89.77%           
=======================================
  Files          73       73           
  Lines        2315     2317    +2     
  Branches      402      420   +18     
=======================================
+ Hits         2078     2080    +2     
  Misses        190      190           
  Partials       47       47           
Impacted Files Coverage Δ
lib/src/DateRangePicker/DateRangePicker.tsx 97.95% <100.00%> (ø)
lib/src/constants/dimensions.ts 100.00% <100.00%> (ø)
lib/src/wrappers/DesktopPopperWrapper.tsx 84.90% <100.00%> (+0.29%) ⬆️
lib/src/wrappers/DesktopWrapper.tsx 100.00% <100.00%> (ø)
lib/src/wrappers/ResponsiveWrapper.tsx 96.29% <100.00%> (-0.14%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2323a4b...7c61217. Read the comment docs.

Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder about a potential inconsistency this prop can bring. In the CSS we will use sm, with no way to have it configured. Do we need to expose a desktopModeBreakpoint prop? What if it was hard coded?

lib/src/wrappers/ResponsiveWrapper.tsx Outdated Show resolved Hide resolved
@oliviertassinari oliviertassinari changed the title Change breakpoint when desktop mode will be enabled for ResponsiveWra… Reduce responsive breakpoint from md to sm Apr 13, 2020
@dmtrKovalenko
Copy link
Member Author

What do you mean by? For example somebody can decide to show the mobile picker for tablets

In the CSS we will use sm, with no way to have it configured

@oliviertassinari
Copy link
Member

oliviertassinari commented Apr 13, 2020

Ok, so we have two different concerns:

  • Logic consistency. Would it be weird to have a mobile version with small day cells or a desktop version with large day cells? Should we make sure that the CSS media query match the version of the component?
  • Threshold. What's the tablet's screen width? What version should we display for a tablet?

It seems that it's should be the touch vs mouse pointer support that should determine what version to display. Maybe we are no looking at the right media query. What if we were using @media (hover: none) instead of the screen width? The more I think about it, the more I like this approach. However, I have seen cases (in Galaxy phones where it doesn't work, there is an issue in the core). So I think that we would also need to add a condition for small screens.

@dmtrKovalenko dmtrKovalenko changed the title Reduce responsive breakpoint from md to sm Better recognition of touch devices Apr 16, 2020
@dmtrKovalenko
Copy link
Member Author

@oliviertassinari really, it is the best way to recognize touch devices. It works really nice for our case. Thanks for this idea! 💪

@dmtrKovalenko
Copy link
Member Author

Todo figure out visual regression

@oliviertassinari
Copy link
Member

Regarding the limitation with Samsung phones, here is it: mui/material-ui#15000. You can use BrowserStack to try that out.
I believe something like this @media (hover: none), (max-width: 600px) would allow to cover most of the cases.

@dmtrKovalenko
Copy link
Member Author

@oliviertassinari also I want to handle the case when the user is on desktop, but the window is small (e.g. iframes or just resized window)
image

Maybe we can make a hook isTouchDevice and place it in @materail-ui/core/utils with all the required logic to recognize touch device?

@oliviertassinari
Copy link
Member

oliviertassinari commented Apr 17, 2020

Maybe we can make a hook isTouchDevice and place it in @materail-ui/core/utils with all the required logic to recognize touch device?

@dmtrKovalenko Given that we only have a use case, for now, in the date picker, I think that we should keep the solution scoped to the date picker. Once 1. we find a solution, 2. that we stress test with the users of the date picker, 3. that we see a need outside the date picker, then, yes, definitely, I think that it would make a great addition to the /core or /utils package.

@oliviertassinari
Copy link
Member

oliviertassinari commented Apr 17, 2020

This approach seems to do it.

   const ResponsiveWrapper: React.FC<ResponsiveWrapperProps> = ({
-    desktopModeMediaQuery = '(hover: hover)',
+    desktopModeMediaQuery = '@media (pointer: fine)',
     okLabel,
     cancelLabel,
     clearLabel,

I have included @media to ease pattern search in the repository (between JS and CSS)

The global document listener approach would be challenging if we need to wait for a first pointer interaction: https://stackoverflow.com/questions/23885255/how-to-remove-ignore-hover-css-style-on-touch-devices

@dmtrKovalenko

This comment has been minimized.

@oliviertassinari

This comment has been minimized.

@dmtrKovalenko
Copy link
Member Author

Confirmed for galaxy s* (pointer: fine) is working just fine
image

Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. I'm excited, I can't wait to try it out in real life (publish) and the implication for updating the styles for desktop #1648 :)

Comment on lines +12 to +14
/** Css media query when `Mobile` mode will be changed to `Desktop`
* @default "@media (pointer: fine)"
* @example "@media (min-width: 720px)" or theme.breakpoints.up("sm")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of this variation to better match the style of the mono-repository for the description of the props?

Suggested change
/** Css media query when `Mobile` mode will be changed to `Desktop`
* @default "@media (pointer: fine)"
* @example "@media (min-width: 720px)" or theme.breakpoints.up("sm")
/**
* CSS media query when "mobile" mode will be changed to "desktop".
*
* @default "@media (pointer: fine)"
* @example "@media (min-width: 720px)" or theme.breakpoints.up("sm")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mobile and Desktop are used as prefixes for specific components (e.g. MobileDatePicker) so it should be more clear for users. Isn't it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mobile and Desktop are used as prefixes for specific components (e.g. MobileDatePicker) so it should be more clear for users. Isn't it?

Copy link
Member

@oliviertassinari oliviertassinari Apr 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using Mobile feels like it's a piece of code that can be used on its own. What about 1. MobileDatePicker or 2. "mobile", I think that we would lose value if we try to compromise between these two options.

*/
desktopModeBreakpoint?: Breakpoint;
desktopModeMediaQuery?: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you considered a shorter name for the prop?

Suggested change
desktopModeMediaQuery?: string;
desktopMediaQuery?: string;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the shorter variant is less expressive. What "desktop" means?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be interpreted as "a media query for desktop", definitely not as good as the information we can provide in a description. Adding mode definitely provide extra context. I don't know. I was wondering about this tradeoff of information vs length for the props, e.g. openPickerIcon, vs pickerIcon.

@oliviertassinari
Copy link
Member

Also closes #1664

Are you sure about this one? Yes, it solves the issue on mobile, but what about desktop?

@dmtrKovalenko
Copy link
Member Author

Yeah, because it needs for desktop a11y. We need to render outline for the focused element. (This is a problem of trap focus actually😮)

And it is not a problem for desktop, because we are not doing missclicks thanks to mouse. On desktop you will probably never see it if not navigating through the Tab. But on mobile it is appearing all the time.

@oliviertassinari
Copy link
Member

I have added an extra description on #1664 to describe what I have observed.

@spider9375
Copy link

@oliviertassinari sorry for bringing this up, but i'm confused. The documentation states:

fine
The primary input mechanism includes an accurate pointing device, such as a mouse.

This means that this media query matches desktop, and not mobile devices.

And at the same time the name of the constant is
IS_TOUCH_DEVICE_MEDIA which when true means that it is in fact not touch device and instead one with a mouse? Or am i understanding this wrong?

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

Successfully merging this pull request may close these issues.

The responsive logic triggers too early for mobile
3 participants