-
Notifications
You must be signed in to change notification settings - Fork 47.8k
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
Remove old IE polyfill code #10238
Remove old IE polyfill code #10238
Conversation
topLevelType === 'topKeyDown' | ||
topLevelType === 'topInput' || | ||
topLevelType === 'topChange' || | ||
topLevelType === 'topSelectionChange' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be worth keeping the top level keyUp and keyDown since it's easy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would we lose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the original comment:
99% of the time, keydown and keyup aren't necessary. IE8 fails to fire
propertychange on the first input event after settingvalue
from a
script and fires only keydown, keypress, keyup. Catching keyup usually
gets it and catching keydown lets us fire an event for the first
keystroke if user does a key repeat (it'll be a little delayed: right
before the second keystroke). Other input methods (e.g., paste) seem to
fire selectionchange normally.
It says IE8 only but one never knows right? We could add them back for sense of security, downside is just a few more lines of code, and maybe cargo-culting in code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having them here plus a todo for further investigation sounds good to me.
|
||
// For IE8 and IE9. | ||
// In IE9 the input event does not fire for deleting text. Luckily | ||
// selectionchange does, so we also listen for that in those cases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true? I tested this build out in IE9 on Windows 7 and it wasn't dispatching change events for deletion. But I also tested out master and I saw the same problem. Are you seeing something different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops it is true, but we aren't hitting this path, because the targetInst
is null...I wonder if that is related to selectionchange not having the right target? why would the instance be null in this case?
and this bug is definitely in master as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok yeah this bug is probably in all versions of react. The Event responder can't find the associated instance for this event because the target
is the document
. This would be true for any weird events like this...
I think it'd be great if we could land this. I published the DOM fixtures with this build here: |
26352fe
to
c921618
Compare
Updated with fixed logic |
Very cool. @jquense I didn't want to let this grow cold. I should be able to get a solid chunk of time to dig into this later today. |
|
||
// On the selectionchange event, the target is the document which isn't | ||
// helpful becasue we need the input, so we use the activeElement instead. | ||
if (!isTextInputEventSupported && topLevelType === 'topSelectionChange') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this was the problem (and is the problem on master/stable) there is no targetInst
for this event so there is no way this event will get published to react-land
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does getActiveElement
not return the correct node for getting the instance from getInstanceFromNode
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it does generally, The null check is out of caution, since this depends on on the input being focused, there may be edge cases where focus drops or some programatic driving of the browser doesn't set focus, etc. I don't think there is much we can do about such edge cases and wanted to limit the possible effect to only cases where the polyfill was being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a frustrating constraint, but it sounds we can't do anything about it. 👍.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were already tracking the active element for this code so the constraint isn't new, i'm just deferring to activeElement
instead of caching it locally in a variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, cool.
@@ -54,7 +54,7 @@ describe('ChangeEventPlugin', () => { | |||
); | |||
|
|||
setUntrackedValue(input, true); | |||
ReactTestUtils.SimulateNative.click(input); | |||
ReactTestUtils.SimulateNative.change(input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if this was asked before: why the switch from click
to change
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Radios and Checkboxes were listening for onClick, i removed that in favor of just listening for onChange/onInput like text inputs.
I'm not entirely sure why the original code used click, the comment suggested it was for IE8, it appears to work fine in IE9 though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. I like this better too, but I wasn't sure on the legacy. 👍
It should be noted that this narrows the scope of the |
fixtures/dom/public/index.html
Outdated
clearTimeout(id); | ||
}; | ||
}()); | ||
</script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does requestAnimationFrame come in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
React apparently requires it, I got a warning
for it being missing. Not sure what the official place to snag it is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fiber currently requires it, I think this way is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine.
fixtures/dom/public/index.html
Outdated
}; | ||
}()); | ||
</script> | ||
<script src="https://unpkg.com/babel-polyfill@6.23.0/dist/polyfill.min.js"></script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think using babel-polyfill
will be problematic at all? It might make it easy to miss changes that won't work in all our supported browsers by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a good question...we should probably use a very focused set of polyfills according to what React says it requires. Should also help keep React honest about that as well :P
I just didn't know what React requires now, for instance in DEV you need Set
which didn't seem obvious
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I like that with requestAnimationFrame
we have an invariant so it fails early. I feel like we should do the same with other stuff like Set
or Map
if we have a hard requirement on those without fallbacks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please let’s keep this focused on Map
and Set
.
topLevelType === 'topSelectionChange' || | ||
topLevelType === 'topKeyUp' || | ||
topLevelType === 'topKeyDown' | ||
topLevelType === 'topInput' || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If getTargetInstForInputEventPolyfill
is only used in a browser (IE9) that doesn't support the input
event, does it make sense to check for topInput
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its like a half-polyfill, we actually do rely on IE9's native onInput
but patch around it so it's not unusably buggy. Specifically it works fine except when deleting text (lol), the selectionchange
covers that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK cool, got it. For some reason, I was thinking IE9 didn't fire input events 😄
@jquense I did a local build and booted this up. I can not change the fixture select or react version dropdown. (neither can I on http://remove-ie9-change-polyfills.surge.sh/): This is in Chrome 59. Any idea what's going on? |
I'm seeing that same problem as well. On another note, it looks like the Angular team ran into the backspace issue and used the Reference: angular/angular.js#936 |
O wow selects in Chrome do some very weird things when you listen for both Input and Change, the |
To recap:
multiple events are deduped |
Cool. I'll pick up heavy duty browser QA and report back. |
} | ||
|
||
if (getTargetInstFunc) { | ||
var inst = getTargetInstFunc(topLevelType, targetInst); | ||
var inst = getTargetInstFunc(topLevelType, targetInst, targetNode); | ||
if (inst) { | ||
var event = createAndAccumulateChangeEvent( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jquense can we use targetNode
as nativeEventTarget
for selection events in IE9? When you start backspacing it registers a change event but it gets undefined
for event.target.value
since event.target
is still the document.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use this same check to branch when calling createAndAccumulateChangeEvent
it should fix input backspacing in IE9 (tested locally).
var event = createAndAccumulateChangeEvent(
inst,
nativeEvent,
(!isTextInputEventSupported && topLevelType === 'topSelectionChange')
? targetNode
: nativeEventTarget,
);
We can dedupe that check with a constant, but yeah. I think that should be work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so! I forgot about actual event target, good call
Found an issue in IE9. EDIT: Sorry, looks like @aweary beat me to it.
This is because the value is getting lost, like This is not an issue in IE10, IE11, or Edge. |
the eventTarget issue should be fixed btw |
Tested successfully in: Chrome 59, 51 *Safari does not accept key input on range inputs, unless I've missed something |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this is good to go, except for the fixtures polyfill part? I trust you folks to test this well :-)
d0b05a0
to
dd936f3
Compare
ok updated the polyfill situation. I ended up getting a CRA upgrade in there and moving the loader stuff into webpack-land so I didn't have to get a browser build of the core-js polyfills i wanted |
It would be nice to separate fixture changes in another PR (we can take it sooner). So that if we end up reverting this, we don't risk merge conflicts in fixtures. |
The up[grade was sort of triggered by how I needed to tweak the entry to allow the more focused polyfilling. I could split it out and then rebase just the onChange on top of it if that's easier. Or structure the commits a bit better so you can revert the one cleanly if needed |
Upgrade to react-scripts v1 and include required polyfills for older browsers
I'm just proposing to split any changes in |
dd936f3
to
7659334
Compare
I cleaned up the commits. I can split them into two PR's but it seems like we are pretty ready to go with this, so it may not save much. That is unless @nhunzaker or @aweary won't have a chance to test again for a while. |
@jquense I can do some thorough QA later today, if it can wait 3 hours. |
of course, no rush :) |
I'm a little busy this week, but I can possibly get some QA in tomorrow if there's still a need for it ❤️ |
I did it! This works in the following browsers:
|
Thanks! |
pour one out for the super clever ie8 onInput polyfill 🍾 |
Not too fast, maybe we’ll have to revert 😛 These things are tricky |
indeed, i've learned that the hard way. |
**what is the change?:** This reverts facebook@0b220d0 Which was part of facebook#10238 **why make this change?:** When trying to sync the latest React with FB's codebase, we had failing integration tests. It looks like they are running with an old version of Chrome and there is something related to file upload that fails when these polyfills are missing. For now we'd like to revert this to unblock syncing, but it's worth revisiting this change to try and add some polyfill for FB and remove it from React, or to fix whatever the specific issue was with our file upload error. **test plan:** `yarn test` and also built and played with the `dom` and `packaging` fixtures
**what is the change?:** This reverts 0b220d0 Which was part of #10238 **why make this change?:** When trying to sync the latest React with FB's codebase, we had failing integration tests. It looks like they are running with an old version of Chrome and there is something related to file upload that fails when these polyfills are missing. For now we'd like to revert this to unblock syncing, but it's worth revisiting this change to try and add some polyfill for FB and remove it from React, or to fix whatever the specific issue was with our file upload error. **test plan:** `yarn test` and also built and played with the `dom` and `packaging` fixtures
This is a bit of an experiment in what can be pulled out here. I’m not yet convinced it’s a good idea. I need to fixup my branch at least.
Removes onClick logic for radio and checkboxes, believe that was ie8 only
removes a substantial chunk of of the input polypill. ie9 partially supports onInput already, and we only need to add in the selection change event to handle the cases it doesn’t work on, e.g. deleting text
For everything else we don’t distinguish between when to use change vs input (such as for select inputs) since we listen to both and dedupe.
I tested against the fixtures on IE9 with positive results!