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

DOM Test Fixtures: Add caveats for IE9 range inputs (and other unsupported things) #11131

Closed
nhunzaker opened this issue Oct 6, 2017 · 8 comments
Assignees

Comments

@nhunzaker
Copy link
Contributor

It can be confusing to recall that the range input type is not supported in IE9, invalidating a few of our test cases. For example:

screen shot 2017-10-06 at 7 03 18 am

This test case verifies that changing a range slider with arrow keys works as expected, however it looks like a standard input in IE9. If we plan to make these test fixtures more public, I wonder if it would be worth adding some caveat language or marking a test as invalid for a certain browser.

Maybe this would be annoying, but I thought it might be nice to collect the opinion of others.

@nhunzaker nhunzaker self-assigned this Oct 6, 2017
@aweary
Copy link
Contributor

aweary commented Oct 6, 2017

@sophiebits mentioned in #9301 that IE9 was maybe, probably OK not to support. If we can get confirmation on that, this would be a non-issue.

@jquense
Copy link
Contributor

jquense commented Oct 6, 2017

yo it would be awesome to not support ie9

@nhunzaker
Copy link
Contributor Author

FWIW, all of this works in IE9. IE9 just doesn't have range inputs, so the range input test case doesn't test arrow keys. I just want to add a disclaimer in case someone comes to this page as a public site and gets confused and blames React.

@aweary
Copy link
Contributor

aweary commented Oct 6, 2017

@nhunzaker should we do the same for unsupported browsers? Maybe we can add some browser detection logic and then render a message like:

This browser is not officially supported by React. If you discover an issue that only occurs in this browser it's likely expected behavior.

And then we can reuse the detection logic for other browser-specific quirks like this.

@aweary
Copy link
Contributor

aweary commented Oct 6, 2017

We could use something like bowser for browser detection.

@jquense
Copy link
Contributor

jquense commented Oct 6, 2017

might be worth pulling in like modernizer and attaching supported prop or something with a fn running a test? Not going crazy but for obvious cases like () => modernizer.supportsRangeInputs or whatever for clear cases

@stale
Copy link

stale bot commented Jan 10, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 19, 2020

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

@stale stale bot closed this as completed Jan 19, 2020
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

4 participants