Restore global window.event after event dispatching (#13688) #13697
Conversation
Details of bundled changes.Comparing: e1a067d...d68bbcb react-dom
react-art
react-test-renderer
react-reconciler
react-native-renderer
scheduler
Generated by |
|
Can we remove the |
|
replace the code
Em qui, 20 de set de 2018 às 09:30, Dan Abramov <notifications@github.com>
escreveu:
… Can we remove the window.event assignment now? Or replace that code with
this one?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#13697 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Am6hA11ebtK2kP9wA76BUyb_Z5qPu8s8ks5uc4pagaJpZM4WxKFF>
.
|
|
I mean, if we're restoring the descriptor, wouldn't that be sufficient to cover that use case too? I thought that would capture its current value too. |
|
@gaearon, the descriptor doesn't have a value, see #13688 (comment). The getter will instead return the current event emitted by |
|
I just don't see how it makes sense that we both attempt to Can we change the place where we write to replace the descriptor getter, and later restore it? |
|
@gaearon - window.event = windowEvent;
+ Object.defineProperty(window, 'event', windowEventDescriptor);After all required manipulations with fake events we have to restore the default behavior for Object.defineProperty(window, 'event', windowEventDescriptor);Was this helpful? |
|
Can we do Object.defineProperty(window, 'event', {
...windowEventDescriptor,
get() { return windowEvent }
});? and then just Object.defineProperty(window, 'event', windowEventDescriptor) |
|
Will it be actually beneficial? We still have to keep both |
|
It's strange that we're changing the characteristics of a descriptor. E.g. I didn't realize it was a getter, or non-enumerable. If it's consistently a getter across browsers that support it, we should just keep it as a getter and not mess with it. |
|
I'm not quite sure regarding browser consistency, e.g. the issue isn't reproduced in FF 62 (the latest release version) -- |
|
E.g. |
|
What a mess. |
|
OK. I can merge this if you can help test in all environments: IE9+ (would require some polyfills), including IE11, then different versions of FF and Chrome. And some mobile (e.g. iOS and Chrome on Android). |
|
OK, I'll try to cover all of them except iOS/Safari -- it can be a bit problematic. |
|
@gaearon I've used the following code to check that the fix works properly: console.log('Global `window.event` descriptor before/after dispatching a fake event:');
console.log(Object.getOwnPropertyDescriptor(window, 'event'));
ReactDOM.render(
<h1>React Component</h1>,
document.getElementById('container')
);
console.log(Object.getOwnPropertyDescriptor(window, 'event'));There're different results of Here's the proof. With the applied fix descriptors are the same: Note: Since FF 62 and IE9-11 returns react/packages/shared/invokeGuardedCallbackImpl.js Lines 116 to 121 in e1a067d And the issue isn't reproduced here. I've checked the fix for the following environments:
I would appreciate if somebody could check it in iOS/Safari. Anyway I don't see why it shouldn't work here. |
|
@sergei-startsev Looking good on iOS 12, 11, and 10 here. Unfortunately JSFiddle doesn't work on older iOS versions - but running the following script in the console works on iOS 8 and 9 as well: var descriptor = Object.getOwnPropertyDescriptor(window, 'event');
Object.defineProperty(window, 'event', descriptor); |
|
@philipp-spiess thanks for checking! |
|
@gaearon Is there anything else we would like to check here? |
|
LGTM, thanks for testing |
|
Hi, I am getting IE11 hanging and the repeated error "Assignment to read-only properties is not allowed in strict mode", on the line
in the cjs\react-dom.development.js This is in version 16.7.0 Commenting out the line allows the site to continue working, or commenting out the Has the build process added the 'use strict' by accident? |
Used @ConradIrwin suggestion to fix #13688.