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

Fix #1790. Disabled input still clickable in IE11. #1820

Closed
wants to merge 1 commit into from
Closed

Fix #1790. Disabled input still clickable in IE11. #1820

wants to merge 1 commit into from

Conversation

nhunzaker
Copy link
Contributor

This PR Takes some code from ReactDOMButton in order to solve the same problem and brings it over to ReactDOMInput.

I'll admit to complete duplication here with how this was solved in ReactDOMButton. Where would the best place be to put the black list of mouse events for when an input/button is disabled?

Fix #1790


// Store a reference to the <input> `ReactDOMComponent`.
var input = ReactDOM.input;

var mouseListenerNames = keyMirror({
onClick: true,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd like to bring up the question again here, shouldn't all input events be in the list? Such as onTap, etc?
PS. Could probably also benefit from putting this in a separate file and reusing for both locations (including the filter logic).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a fair question -- I'd need to hunt down the specification for disabled elements to speak with any confidence. As for placing this in a separate file... yes -- but is there an existing location it should go?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Pure joy...

screen shot 2014-07-13 at 8 43 50 am

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, excellent. Perhaps it should be explained in a comment then.

@nhunzaker
Copy link
Contributor Author

@syranide I added touch event coverage and pulled the filtering into a separate file. This was sort of a stab in the dark, let me know if I'm on the right track and I'll throw in test coverage for touch events.


for (var key in props) {
if (props.hasOwnProperty(key) &&
(!props.disabled || !disabledEventBlacklist[key])) {
Copy link
Contributor

Choose a reason for hiding this comment

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

!props.disabled should probably be moved to the top and return the original props if it isn't disabled?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Though we still need to clone the props. A couple of tests actually fail if we don't.

@nhunzaker
Copy link
Contributor Author

Leaving a public note for myself: Are keyboard events properly trapped too? If not, what events should actually fire on a disabled input/button?

@nhunzaker
Copy link
Contributor Author

Also I think I need to check coverage for <select> and <textarea>

@nhunzaker
Copy link
Contributor Author

Okay! Here's how I tested:

https://gist.github.com/nhunzaker/688708c06e775228afeb

I verified that events fired as would be expected without the disabled attribute, then added it and tallied the results. I don't have complete confidence in my testing mechanisms (a sad and lonely road of browser compliance), but they got results. These are the events that I found actually trigger:

Chrome/Safari:

Allow all keyboard events and focus/blur events.

Android 4.4/iOS 7.1

Allow focus/blur, keyboard, and touch events.

So basically, Webkit desktop + all touch events

Firefox

Mousemove, wheel

IE9-11 (emulated, windows 8)

None

IE8 (windows 7)

None


Across the board, mouse events did not trigger. If we do anything, we should filter out mouse events. Focus events are an interesting story because it is impossible in Safari/Chrome to focus on a disabled input, however the event fires; it's possible this is a flaw in my testing.

As for keyboard events. Safari/Chrome allow them, however again, I do not know in the wild if it is even possible to trigger them if an input can't receive focus. The specific example I made allows keyboard events if you manually trigger them, however it isn't possible to actually press a key within the input.

Now for touch events. We should leave these alone. They clearly fire when a disabled input is touched in both Android and Safari (http://codepen.io/nhunzaker/pen/veCsF).

Verdict

Nothing new... 😿. Filter out click, double click, mousedown, mouseup, and mousemove.

But we should definitely be doing this for textarea and select. Do we know if they have coverage right now?

@nhunzaker
Copy link
Contributor Author

Any additional thoughts here?

Takes some code from ReactDOMButton in order to solve the same problem
within ReactDOMInput.
@nhunzaker
Copy link
Contributor Author

@syranide I just updated this with the latest from master. Is there anything outstanding to bury this?

@syranide
Copy link
Contributor

@nhunzaker ... @zpao or some other dev should weigh in on this.

@zpao
Copy link
Member

zpao commented Sep 24, 2014

cc @yungsters

@zpao
Copy link
Member

zpao commented Sep 24, 2014

(Also, sorry! We're getting out of a large backlog of issues/PRs and unfortunately some have slipped through the cracks completely 😞)

@@ -0,0 +1,52 @@
/**
* Copyright 2013-2014 Facebook, Inc.
Copy link
Contributor

Choose a reason for hiding this comment

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

2014 should become 2015 before this is merged.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's the old license even :)

@nhunzaker
Copy link
Contributor Author

@zpao I'd be happy to update it, but is this PR still relevant?

@nhunzaker
Copy link
Contributor Author

Whelp, for whatever reason I deleted my fork. Nice... I'll resubmit this.

@nhunzaker
Copy link
Contributor Author

Closing this, please refer to #3349.

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.

Disabled input still clickable in IE11
4 participants