jiebi/CodeConvo huggingface dataset:
Code change:
(I am using 15rc2 because I need all the svg tags) I am rendering a foreignObject svg tag. According to I put body tag inside that tag and then whatever html I want in there. renderToString on the server leaves the body tag in place, and gives it a react-dataid. However when rendered on the client that body tag is removed. So when I look at the live elements, the body inside foreignObjects is gone, along with it's data-reactid. The server source ( ie view page source ) shows that the body tag was rendered with the missing react-dataid. The result is that you get a “Invariant Violation: Unable to find element with ID XX”, when the page updates, and somethings don't work. Removing the body from inside the foreignObject tag seems to solve the problem, but I don't know if that is an "OK" solution to this or if that body tag is necessary in some scenarios. But in either case this seems to be a scenario where server rendering results in different DOM/HTML then client rendering. Is this a problem, or is the body tag not supposed to there anyway? Todd
We never render the on the client side - only on the server side. Can you provide a jsfiddle that demonstrates the invariant violation?
Thanks for tracking down more specifically. Could be that browsers don't actually support that body usage? Or when actually parsed from markup, the body node doesn't exist (which seems likely and matches up with what we see in other situations where the browser changes markup). I won't have a chance to look into this more for a few days - it might be best to just use your alternate approach for now.
I can remove the body tag. It seems to work ok with out it. Whats clear at this point is that if the server sends the body tag, it is not parsed into a DOM node, at least on mac with Chrome and Safari. That results in the error, since the data-reactid for the body is missing. IE doesn't support foreignObject so its not relevant there. MS Edge does, but I haven't tested it.
It seems so. Even without React, I can’t get Chrome (or Firefox for that matter) to make an actual node: <img width="261" alt="screen shot 2016-03-17 at 15 19 30" src=""
FWIW, does manage to put one in:
Sounds like we should add this to : we should warn and tell you you can't put a body tag inside foreignObject. We don't do anything much for SVG there right now; probably the ideal solution would be to pass the namespace info down too, then we can distinguish SVG and HTML tags with the same name (like title), then make sure the contents of a SVG tag are appropriate HTML tags. Not sure which HTML tags are and aren't allowed but it might be detailed in the HTML5 spec at
Can I take this one?
please do :-)

Related discussion:
text: expect(isTagStackValid(['table', 'tr'])).toBe(false); expect(isTagStackValid(['div', 'ul', 'li', 'div', 'li'])).toBe(false); expect(isTagStackValid(['div', 'html'])).toBe(false); <ins> expect(isTagStackValid(['body', 'body'])).toBe(false); expect(isTagStackValid(['svg', 'foreignObject', 'body', 'p'])).toBe(false); </ins> }); });
Code change:
(I am using 15rc2 because I need all the svg tags) I am rendering a foreignObject svg tag. According to I put body tag inside that tag and then whatever html I want in there. renderToString on the server leaves the body tag in place, and gives it a react-dataid. However when rendered on the client that body tag is removed. So when I look at the live elements, the body inside foreignObjects is gone, along with it's data-reactid. The server source ( ie view page source ) shows that the body tag was rendered with the missing react-dataid. The result is that you get a “Invariant Violation: Unable to find element with ID XX”, when the page updates, and somethings don't work. Removing the body from inside the foreignObject tag seems to solve the problem, but I don't know if that is an "OK" solution to this or if that body tag is necessary in some scenarios. But in either case this seems to be a scenario where server rendering results in different DOM/HTML then client rendering. Is this a problem, or is the body tag not supposed to there anyway? Todd
We never render the on the client side - only on the server side. Can you provide a jsfiddle that demonstrates the invariant violation?
Thanks for tracking down more specifically. Could be that browsers don't actually support that body usage? Or when actually parsed from markup, the body node doesn't exist (which seems likely and matches up with what we see in other situations where the browser changes markup). I won't have a chance to look into this more for a few days - it might be best to just use your alternate approach for now.
I can remove the body tag. It seems to work ok with out it. Whats clear at this point is that if the server sends the body tag, it is not parsed into a DOM node, at least on mac with Chrome and Safari. That results in the error, since the data-reactid for the body is missing. IE doesn't support foreignObject so its not relevant there. MS Edge does, but I haven't tested it.
It seems so. Even without React, I can’t get Chrome (or Firefox for that matter) to make an actual node: <img width="261" alt="screen shot 2016-03-17 at 15 19 30" src=""
FWIW, does manage to put one in:
Sounds like we should add this to : we should warn and tell you you can't put a body tag inside foreignObject. We don't do anything much for SVG there right now; probably the ideal solution would be to pass the namespace info down too, then we can distinguish SVG and HTML tags with the same name (like title), then make sure the contents of a SVG tag are appropriate HTML tags. Not sure which HTML tags are and aren't allowed but it might be detailed in the HTML5 spec at
Can I take this one?
please do :-)

Related discussion:
text: case 'rt': return impliedEndTags.indexOf(parentTag) === -1; <ins> case 'body': </ins> case 'caption': case 'col': case 'colgroup':
Code change:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.

Related discussion:
text: } } <ins> function stripComplexValues(key, value) { if (typeof value !== 'object' || Array.isArray(value) || value == null) { return value; } var prototype = Object.getPrototypeOf(value); if (!prototype || prototype === Object.prototype) { return value; } return '<not serializable>'; } </ins> // This implementation of ReactPerf is going away some time mid 15.x. // While we plan to keep most of the API, the actual format of measurements // will change dramatically. To signal this, we wrap them into an opaque-ish
Code change:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.

Related discussion:
text: var result = {}; result[DOMProperty.ID_ATTRIBUTE_NAME] = item.id; result.type = item.type; <del> result.args = JSON.stringify(item.args); </del> <ins> result.args = JSON.stringify(item.args, stripComplexValues); </ins> return result; })); console.log(
Code change:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.

Related discussion:
text: expect(summary).toEqual([]); }); <ins> it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => { ReactDOM.render(<Div>hey</Div>, container); }); spyOn(console, 'table'); ReactDefaultPerf.printOperations(measurements); expect(console.table.calls.length).toBe(1); expect(console.table.argsForCall[0][0]).toEqual([{ 'data-reactid': '', type: 'set innerHTML', args: '{"node":"<not serializable>","children":[],"html":null,"text":null}', }]); }); </ins> it('warns once when using getMeasurementsSummaryMap', function() { var measurements = measure(() => {}); spyOn(console, 'error');
Code change:
To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.

Related discussion:
text: ); }); <del> it('should properly log warnings when events simulated with rendered components', function() { </del> <ins> // TODO: reenable this test. We are currently silencing these warnings when // using TestUtils.Simulate to avoid spurious warnings that result from the // way we simulate events. xit('should properly log warnings when events simulated with rendered components', function() { </ins> spyOn(console, 'error'); var event; var element = document.createElement('div');
Code change:
To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.

Related discussion:
text: fakeNativeEvent, node ); <ins> // Since we aren't using pooling, always persist the event. This will make // sure it's marked and won't warn when setting additional properties. event.persist(); </ins> Object.assign(event, eventData); if (dispatchConfig.phasedRegistrationNames) {
Code change:
To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.

Related discussion:
text: expect(handler).not.toHaveBeenCalled(); }); <ins> it('should not warn when simulating events with extra properties', function() { spyOn(console, 'error'); var CLIENT_X = 100; var Component = React.createClass({ handleClick: function(e) { expect(e.clientX).toBe(CLIENT_X); }, render: function() { return <div onClick={this.handleClick} />; }, }); var element = document.createElement('div'); var instance = ReactDOM.render(<Component />, element); ReactTestUtils.Simulate.click( ReactDOM.findDOMNode(instance), {clientX: CLIENT_X} ); expect(console.error.calls.length).toBe(0); }); </ins> it('can scry with stateless components involved', function() { var Stateless = () => <div><hr /></div>; var SomeComponent = React.createClass({
Code change:
has two calls to the Component class construction which are missing use of the 'new' operator. The calls are like this: Component(publicProps, publicContext, updateQueue) and are here: and here:
This is intentional. We check if we need to construct , and then use it to either call or not. This lets us support functional components and factory components:

Related discussion:
text: var args = [ "bin/jsx", <ins> "--cache-dir", ".module-cache", </ins> config.sourceDir, config.outputDir ];
Code change:
Do you want to request a feature or report a bug? This is more of a documentation discussion What is the current behavior? Currently, the contributing guide lists the lint step before running prettier. For example, says: If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). What is the expected behavior? I think it would make more sense to run prettier first, since it can automatically get rid of certain lint errors (like single-quotes or comma-dangle). A first-time contributor following the steps in order might waste time fixing things manually at the lint step before proceeding to the formatting step. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? N/A
Happy to take PR fixing it.
Thanks to reminding, I make a PR for it.
Seems like this was fixed.

Related discussion:
text: 2. If you've added code that should be tested, add tests! 3. If you've changed APIs, update the documentation. 4. Ensure the test suite passes (`npm test`). <del> 5. Make sure your code lints (`npm run lint`). 6. Format your code with [prettier](https://github.com/prettier/prettier) (`npm run prettier`). </del> <ins> 5. Format your code with [prettier](https://github.com/prettier/prettier) (`npm run prettier`). 6. Make sure your code lints (`npm run lint`). </ins> 7. Run the [Flow](https://flowtype.org/) typechecks (`npm run flow`). 8. If you added or removed any tests, run `./scripts/fiber/record-tests` before submitting the pull request, and commit the resulting changes. 9. If you haven't already, complete the CLA.
Code change:
We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.

Related discussion:
text: var invariant = require('fbjs/lib/invariant'); var ExecutionEnvironment = require('fbjs/lib/ExecutionEnvironment'); <del> // TODO: There's no way to cancel these, because Fiber doesn't atm. let rAF: (callback: (time: number) => void) => number; </del> <ins> // TODO: There's no way to cancel, because Fiber doesn't atm. </ins> let rIC: (callback: (deadline: Deadline) => void) => number; if (!ExecutionEnvironment.canUseDOM) { <del> rAF = function(frameCallback: (time: number) => void): number { setTimeout(frameCallback, 16); return 0; }; </del> rIC = function(frameCallback: (deadline: Deadline) => void): number { setTimeout(() => { frameCallback({
Code change:
We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.

Related discussion:
text: 'polyfill in older browsers.', ); } else if (typeof requestIdleCallback !== 'function') { <del> // Wrap requestAnimationFrame and polyfill requestIdleCallback. </del> <ins> // Polyfill requestIdleCallback. </ins> var scheduledRAFCallback = null; var scheduledRICCallback = null;
Code change:
We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.

Related discussion:
text: isIdleScheduled = false; var callback = scheduledRICCallback; scheduledRICCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(frameDeadlineObject); } };
Code change:
We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.

Related discussion:
text: } var callback = scheduledRAFCallback; scheduledRAFCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(rafTime); } }; <del> rAF = function(callback: (time: number) => void): number { // This assumes that we only schedule one callback at a time because that's // how Fiber uses it. scheduledRAFCallback = callback; if (!isAnimationFrameScheduled) { // If rIC didn't already schedule one, we need to schedule a frame. isAnimationFrameScheduled = true; requestAnimationFrame(animationTick); } return 0; }; </del> rIC = function(callback: (deadline: Deadline) => void): number { // This assumes that we only schedule one callback at a time because that's // how Fiber uses it.
Code change:
We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.

Related discussion:
text: return 0; }; } else { <del> rAF = requestAnimationFrame; </del> rIC = requestIdleCallback; } <del> exports.rAF = rAF; </del> exports.rIC = rIC;
Code change:
Do you want to request a feature or report a bug? bug What is the current behavior? In the render Fragments example, the JSX tag is closed prematurely. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). — What is the expected behavior? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.0.0 documentation website on Chrome Android. Previously array Fragments weren't supported.

Related discussion:
text: ```javascript render() { return [ <del> <li key="A"/>First item</li>, <li key="B"/>Second item</li>, <li key="C"/>Third item</li>, </del> <ins> <li key="A">First item</li>, <li key="B">Second item</li>, <li key="C">Third item</li>, </ins> ]; } ```
Code change:
The current default behavior is that keyboard users will get to the code sections of the live editor and get stuck. Can someone configure ignoreTabKey which makes the editor ignore tab key presses so that keyboard users can tab past the editor without getting stuck? Chrome on Windows atm and cannot edit it to submit a fix. Sorry about that :(
Thanks for bringing this to our attention

Related discussion:
text: }, }} className="gatsby-highlight"> <del> <LiveEditor onChange={this._onChange} /> </del> <ins> <LiveEditor onChange={this._onChange} ignoreTabKey={true} /> </ins> </div> </div> {error &&
Code change:
Do you want to request a feature or report a bug? Improvement What is the current behavior?  does not currently support the property. () is nice to have when you want to write key-specific handling—rather than input-specific (dependent on layout and modifier keys) handling. What is the expected behavior? already exposes a property. It should have a property as well. Currently, if you want to use the 's , you must access it through 's . Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Affects React 16 and earlier (I assume).
I created the PR for this.
the above PR is stale and closed; should I pick this up? planning to replicate the same and follow the PR suggestions; any tips or idea?
Can you give me an idea of how widely supported it is?
According to it is supported in all major desktop browsers. Are there any plans to implement this? I am not sure whether I should mark it with until this issue is resolved or don't use it at all.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

Related discussion:
text: function getUnboundedScrollPosition(scrollable) { if (scrollable === window) { return { <del> x: document.documentElement.scrollLeft || document.body.scrollLeft, y: document.documentElement.scrollTop  || document.body.scrollTop </del> <ins> x: window.pageXOffset || document.documentElement.scrollLeft, y: window.pageYOffset || document.documentElement.scrollTop </ins> }; } return {
Code change:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

Related discussion:
text: import requestAnimationFrameForReact from 'shared/requestAnimationFrameForReact'; import ExecutionEnvironment from 'fbjs/lib/ExecutionEnvironment'; <ins> import invariant from 'fbjs/lib/invariant'; import warning from 'fbjs/lib/warning'; </ins> // We capture a local reference to any global, in case it gets polyfilled after // this module is initially evaluated.
Code change:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

Related discussion:
text: localClearTimeout(timeoutId); }; } else { <ins> if (__DEV__) { if (typeof requestAnimationFrameForReact !== 'function') { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } let localRequestAnimationFrame = typeof requestAnimationFrameForReact === 'function' ? requestAnimationFrameForReact : function(callback: Function) { invariant( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); }; </ins> let headOfPendingCallbacksLinkedList: CallbackConfigType | null = null; let tailOfPendingCallbacksLinkedList: CallbackConfigType | null = null;