KeyboardEvent now normalizes "charCode", "keyCode", "which" across all browsers
KeyboardEvent has partial "key"-support for KeyDown/KeyUp and full "key"-support for KeyPress.
KeyboardEvent, MouseEvent and TouchEvent now has "getModifierState", polyfill when not implemented.
In IE10/11, it is apparently possible to have a Selection or Range object that has the following properties:
- `anchorNode` === `focusNode` (Selection) or `startContainer` === `endContainer` (Range)
- `anchorOffset` === `focusOffset` (Selection) or `startOffset` === `endOffset` (Range)
- `isCollapsed` === `false` (Selection) or `collapsed` === `false` (Range)
As defined in http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html, this doesn't really make sense. Since the nodes and offsets are the same, the "collapsed" value should be `true`.
Moreover, when calling `selection.toString()` in this case, it appears that the entire text contents of `body` -- including `<script>` tag contents -- are considered within the selection. I thought maybe the selected nodes were missing from the DOM or something, but no, they're there.
Sidestep all of this in `ReactDOMSelection` by calculating the `collapsed` property manually and setting the selection length directly to zero if it is actually collapsed.
Side note: I think that for selection restoration on contenteditables, we shouldn't try to do this offset calculation. We should just use the structure provided natively (nodes and offsets) since we can restore using that structure as well.
Previous behavior: `transferPropsTo(<div style={{color: 'red'}} />)` would get `color` overriden if we transfer in a `style={{color: 'blue'}}`. This is inconsistent with how other props are transfered.
This simply reverses the order of arguments.
closes#1435
This makes it a little easier to add SVG properties. It also makes use of that injection that we claim is easy to use and will likely start playing a bigger part soon.
Closes#1009
We're now trying to access document directly at require time. Wrapping in a function prevented that before. But we can simply check what environment we're in first.
React components have _mountIndex, that looks like it is their order in DOM.
If you swap 2 elements in DOM, their order in children array isn't changed, but their _mountIndex is
There is no point in doing the feature detection on every call, unless there is an IE bug where it is not sure about which support for selection it has (totally plausible).
Adds a PropType that checks for proper use of the ReactLink API and optionally validates the type of value passed in via the link. Basically, it's a wrapper around PropTypes.shape that hides the implementation of ReactLink.
The `updatedChildren[j].parentNode.removeChild(updatedChildren[j]);` line below can fail if (1) we're moving/moving the same node twice or (2) the node we're looking for is gone completely. This makes it easier to distinguish between the two cases.
Perf shouldn't be a concern here because this is DOM code and invariants are fast in comparison.
Test Plan: grunt test
In the future we could consider wrapping the entire public API (renderComponent, setProps, setState, etc) in this check but this should do for now.
Test Plan: grunt test
8855d6153e gave more accurate error messages for date and regexp by returning 'date' and 'regexp' respectively from `getPropType`.
However, for the object primitive check, which compares the instance passed with `getPropType's` return string, `object` !== 'date'.
This adds special hanlding for those.
Andreas Svensson
Ben Alpert
Paul O’Shannessy
Cheng Lou
Isaac Salier-Hellendag
Paul O'Shannessy
Jan Kassens
Jonas Gebhardt
Juraj Dudak
Christoph Pojer
Cheng Lou
Matthew Dapena-Tretter
Laurence Rowe