Global window.event is overwritten in React 16.5+ in development mode.

[sergei-startsev]

Do you want to request a feature or report a bug?

Report a bug.

What is the current behavior?

Global window.event is overwritten in React 16.5+ in development mode. Here're minimal repro steps:

• React 16.5.2 in dev mode: https://jsfiddle.net/sergei_startsev/ecz103vL/2/

If you click the button, you see DOMContentLoaded event type.

What is the expected behavior?

The current behavior contradicts with specified behavior window property event returns the Event which is currently being handled by the site's code. Outside the context of an event handler, the value is always undefined. Moreover it works properly in production mode:

• React 16.5.2 in prod mode: https://jsfiddle.net/sergei_startsev/st5L8e02/2/

It returns expected click event type.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

It works properly in React 16.4.2 and prod mode:

• React 16.4.2 in dev mode: https://jsfiddle.net/sergei_startsev/o26L08qw/

The issue is reproduced in Chrome 69. It works properly in FF 62 (window.event isn't support in 62, however it should be reproduced in FF 63 - it was recently added, see details).

It seems that the issue was introduced by @ConradIrwin in #11696.

[gaearon]

Seems like a bug. Can you figure out what's wrong with #11696? Or we could revert it altogether although you'd still get a different event in some cases (which is what #11696 tried to fix).

[asapach]

Can you figure out what's wrong with #11696?

According to the docs:

Outside the context of an event handler, the value is always undefined.

#11696 sets the value, but never resets it back to undefined:

react/packages/shared/invokeGuardedCallbackImpl.js

Line 120 in e1a067d

window.event = windowEvent;

So it always stores some previous event.

[gaearon]

Want to send a PR to reset it? As long as we handle nesting correctly.

[asapach]

@gaearon, I've tried a couple of things, and I don't think it's possible to restore the property correctly.

Initially Object.getOwnPropertyDescriptor(window, 'event') looks like this:

{
  configurable: true,
  enumerable: false,
  get: ...,
  set: ...
}

After it has been assigned (e.g. window.event = undefined or window.event = windowEvent) it looks like this:

{
  configurable: true,
  enumerable: true,
  value: undefined,
  writable: true
}

After delete window.event:

undefined

I would suggest using something other than window.event to fix #11687 (e.g. window.lastEvent) or roll this back entirely.

[ConradIrwin]

I'm sorry about this. In testing I observed that changes to window.event made within event handlers are restored at the end of the event handler. That said I can't reproduce this any more, so I must have been mistaken.

I am happy with either exposing this somewhere other than window.event, or by using the property descriptor to restore itself:

let property = Object.getOwnPropertyDescriptor(window, 'event')

if (property) {
  let windowEvent = window.event
}

function call() {
  window.event = windowEvent
}

dispatchEvent()

if (property) {
  Object.defineProperty(window, 'event', property)
}

[sergei-startsev]

@ConradIrwin I've applied the suggested fix for a project where the issue was initially detected -- it works fine for me.

I've also verified a restored descriptor:

Let me know if you would like to make PR yourself or delegate it.

[ConradIrwin]

I should be able to get to it tomorrow , if you want to jump ahead of me, please feel free :D. Conrad Sent via Superhuman ( https://sprh.mn/?vip=conrad.irwin@gmail.com )

…

On Wed, Sep 19, 2018 at 2:11 PM, Sergei Startsev < ***@***.*** > wrote: @ ConradIrwin ( https://github.com/ConradIrwin ) I've applied the suggested fix for a project where the issue was initially detected -- it works fine for me. I've also verified a restored descriptor: image ( https://user-images.githubusercontent.com/748074/45781393-7fb52a00-bc68-11e8-975e-84d1ea0eaac3.png ) Let me know if you would like to make PR yourself or delegate it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( #13688 (comment) ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/AAFwQINLCCGDKD468unPO_9vBU3qYlmyks5ucrL9gaJpZM4WwNfH ).

[sergei-startsev]

@ConradIrwin np, the changes look pretty straightforward 😉