There were 2 issues:
I was reusing event outside the original event handler (activeNativeEvent).
This is a bad idea. I've changed deferred dispatch to have an empty object
as the nativeEvent.
I didn't handle inputs without .selectionStart (e.g. file inputs). I extracted
a input type check from ChangeEventPlugin and reuse it here.
Polyfill 'onSelect' behavior for React.
Use non-standard 'selectionchange' event rather than 'select' event.
This allows us to fire the event when user moves the cursor via arrow
keys, and not just when they select multiple chars.
Add methods to ReactDOMSelection to make getting current selection
easier, so we can do a fast check for change without having to
calculate char offsets for selection start and end.
Move compositionstart/compositionend to a new event plugin.
Add a polyfill that listens to key and mouse events and uses selection to
determine which text has changed.
Add clipboard events to React.
For forms, these shouldn't really be necessary -- the onChange event should handle deletions and insertions. For contenteditables, however, we need to be able to access clipboard data.
Closes#271.
All three of these files are DOM-specific so it should be fine to use window. (ReactEventTopLevelCallback isn't obviously DOM-specific but it calls getEventTarget which is so I think we're fine here.)
Test Plan:
grunt test, tried events in a real browser and they seemed to work still.
Sencha says that separating big components into their own iframes was important for performance:
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story.
Today the only thing stopping us is that events don't bubble to our events system from an iframe. This diff
looks at the owning document of the container and adds top-level listeners to it. It should not change
existing behavior and should improve our support for this.
Summary:
- Weren't pooling the Transaction in the batching strategy
- Creating a new closure for every event tick due to batchedUpdates()
- EnterLeaveEventPlugin creates a new array on each event.
I wonder if there is more optimization opportunity in accumulate(). Squinting at the fps graph this seems to be faster and waste less memory but it's hard to conclusively tell. I did verify that these were all hotspots though.
There is a circular dependency between `ReactID`, `ReactMount` and
`ReactInstanceHandles`. Ben and I talked about this today. It seems like the
simplest solution is to consolidate a lot of the code that Ben recently wrote
into `ReactMount`. We can later find ways to trim code out of this module
without causing circular deps.
This works around a bug with listening to clicks using event delegation on Mobile Safari using an event plugin.
NOTE: We don't enable touch events by default, so I don't know if would want to inject this plugin by default. In fact, I'm not sure what our strategy is at all for when to invoke `React.useTouchEvents(true)`.
This fixes two bugs related to string-casting in React:
# Setting `<input value={0} />` would use an empty `value` because `0` is falsey.
# Using `onChange` and `setState` with non-strings could lead to an infinite loop.
The latter is possible with controlled inputs when:
- User changes input value.
- `onpropertychange` fires.
- `ChangeEventPlugin` dispatches `onChange`.
- A handler responds via `this.setState` with a non-string value (e.g. a number).
- The input re-renders and re-sets `value`.
- The new `value` is not a string, but the current `value` (read from the element) is cast to a string automatically by the browser.
- This triggers another `onpropertychange`.
- `ChangeEventPlugin` dispatches another `onChange`.
- ...
This fixes a bug with `ChangeEventPlugin` in IE8 and IE9. The extend of this bug includes:
- On IE8, not firing `onChange` immediately after `value` of an input is changed.
- On IE9, not firing `onChange` when backspacing.
Just a bit of byte savings for server rendering. Props to @benjamn for the base36 idea (and for making this diff easy).
With a little work we could probably get rid of the .r as well.
Upgrade `TextChangeEventPlugin` to be the `onChange` event that React
fires. In React, `onChange` will now fire when `input` fires for form elements in
modern browsers.
Handle this for:
input[type=text]
input[type=password]
input[type=checkbox]
input[type=radio]
textarea
select
Support:
- OSX Chrome
- OSX Safari
- OSX Firefox
- Win 7 / IE8
- Win 7 / IE9
- Win 7 / IE10
Everything works but caret selection / placement differs from browser to
browser.
For <select> elements, the event is fired with `change`. This is a
conscious decision, even though in some browsers (OSX firefox, IE), it
can be argued that the event should fire more due to how the UI looks.
Builds on https://github.com/facebook/react/pull/75, which handled only
text inputs.
Also removed some unnecessary calls to `document.getElementById`, which
will eventually cease to work for React-specific IDs.
This clears the way for the deprecation of `ReactDOMNodeCache` and
`getDOMNodeID`.
Dumping the mock cache isn't dirying the modules, so we have to unit test a different way. If we can fix our unit test framework, we should revert this.
Also, I added strict mode to `EventPluginRegistry.js`.
The `EventPluginHub` module was getting huge and scary. This pulls out all of the logic required to inject plugins and publish their event registration names into a new `EventPluginRegistry` module.
Functionally, nothing should have changed. I added many error checks to cover edge cases that we were not yet running into, but they are all in `EventPluginRegistry` and unit tested.
IE8 doesn't support oninput and IE9 supports it badly but we can do
almost a perfect shim by listening to a handful of different events
(focus, blur, propertychange, selectionchange, keyup, keydown).
This always triggers event handlers during the browser's event loop (not
later in a setTimeout) and after the value property has been updated.
The only case I know of where this doesn't fire the event immediately is
if (in IE8) you modify the input value using JS and then the user does a
key repeat, in which case we fire the event on the second keydown.
Test Plan:
Modify ballmer-peak example to add es5-shim and to use onTextChange
instead of onInput. In IE8, IE9, and latest Chrome, make sure that the
event is fired upon:
* typing normally,
* backspacing,
* forward-deleting,
* cutting,
* pasting,
* context-menu deleting,
* dragging text to reorder characters.
After modifying the example to change .value, make sure that the event
is not fired as a result of the changes from JS (even when the input box
is focused).
This improved browser support for the `wheel` event.
- Try to use `wheel` event (DOM Level 3 Specification).
- Fallback to `mousewheel` event.
- Fallback to `DOMMouseWheel` (older Firefox).
Also, since `wheel` is the standard event name, let's use that in React.
NOTE: The tricky part was detecting if `wheel` is supported for IE9+ because `onwheel` does not exist.
Test Plan:
Execute the following in the console on a page with React:
var React = require('React');
React.renderComponent(React.DOM.div({
style: {
width: 10000,
height: 10000
},
onWheel: function() {
console.log('wheel');
}
}, null), document.body);
Verified that mousewheel events are logged to the console.
Verified in IE8-10, Firefox, Chrome, and Safari.
Summary:
This makes a few changes to React Core, most notably `ReactEventEmitter` and `ReactEventTopLevelCallback`.
- Changed `ReactEventEmitter` to use `EventListener` (instead of `NormalizedEventListener`).
- Deleted `NormalizedEventListener` (which was previously broken).
- Created `getEventTarget` which is used to get a normalized `target` from a native event.
- Changed `ReactEventTopLevelCallback` to use `getEventTarget`.
- Renamed `abstractEventType` to `reactEventType` in `AbstractEvent`.
- Reanmed `abstractTargetID` to `reactTargetID` in `AbstractEvent`.
- Removed `originatingTopLevelEventType` from `AbstractEvent` (unused and violates encapsulation).
- Removed `nativeEvent.target === window` check when refreshing authoritative scroll values (unnecessary).
This actually fixes React because `NormalizedEventListener` does not currently do what it promises to do (which is normalizing `target` on the native event). The `target` event is read-only on native events.
This also revises documentation and adds `@typechecks` to a few modules.
NOTE: Most importantly, this sets the stage for replacing `AbstractEvent` with `ReactEvent` and subclasses, piecemeal.
ReactEvent should be reserved for the actual object created when an
event fires. The current ReactEvent is more like EventEmitter than
anything (e.g. it sets up delegation, provides methods to attach and
remove listeners).
Test Plan:
With the ballmer-peak example (modified to use input), tested that the
percentage updates when adding or deleting text in the field on Chrome
and IE9. After adding es5-shim and es5-sham to the ballmer-peak page,
IE8 works properly too.
'input' is supported in IE9+ and all other browsers according to
https://developer.mozilla.org/en-US/docs/Web/API/window.oninput
Test Plan:
Modified ballmer-peak example to use onInput instead of onKeyUp and
tested that it works properly on latest Chrome.
Mouad Debbar
SanderSpies
Josh Duck
Ben Alpert
Owen Coutts
Marshall Roch
Isaac Salier-Hellendag
Timothy Yung
Pete Hunt
Paul O'Shannessy
Jordan Walke
Tim Yung
Pete Hunt
CommitSyncScript
Ben Newman
Paul O’Shannessy