Nor sure what that means other than that the tests are flakey :'(
https://travis-
https://travis-


Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.


Firs, it's unitless. I've seen a hack where the value is being specified as to make it pass the check and skip our adding of 'px'. Further, is actually a shorthand property, so we should support the expansion into the right properties.
I don't think we need to do anything special for shorthand properties except for the list needed only for IE8.
related: there are also some obscure css properties that can be unitless: Edit: + widow, - counter-*
While we're at it, is also unitless. The properties mentioned in the above link don't actually take a single number.
I'm not saying it's a great idea, just putting it out there... but what if we switched over to , , , , , etc. Not the prettiest, but perhaps prettier than and you can now access unmodified traditional CSS behavior and if you want to use the short-hand style, it's obvious and unambiguous, and not limited to just . It doesn't modify expected behavior, it doesn't conflict... philosophically that's up to you. :) ...speaking with people in the chat, I agree that it's a bad idea... however, seeing other peoples gripes with how React doesn't vendor-prefix, etc, etc. Perhaps the real solution is for React to export a settable where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix , use the addon. And this is a bad idea as well as it would prevent reliably sharing components. is currently ambiguous as it supports unitless and and thus we cannot auto-suffix it...
line-height 'px' is used 15x-50x more times than unitless, em or percentage on fb codebase. I feel like this should be the default and we should provide a more verbose way to use it in an unitless way.
I agree, my only issue with that is that we would explicitly break with the CSS standard then.
My view on this is that the CSS standard is only using strings. So if you say '1.5', React is just going to output '1.5'. Now if you say 23 (the number), then React is going to be able to add any convenience it wants, such as adding 'px' as it's the most common use case.
It doesn't conflict today (probably never will but still). Also, do we now want to add , , (and so on for each numeric unit)? I think I'm more likely to go for forcing a unit if you want one. (eg, doesn't get converted to , you have to put the in yourself).
My idea with having the units as a suffix of the name is that it could be a universal test for all properties (for simplicity). If , or whatever is at the end the property name, we remove it and add it to the value instead. That way the only thing we would need to hard-code is which units are allowed, so the implementation would be minimal and barring any new units, future proof. While it theoretically could conflict, I don't see how it ever could, the units have very non-wordy names (case would obviously be taken into account as it already is). However, a practical issue is what to do if there are multiple units specified for the same property. So I definitely see that this may not be the favored way to go, just putting it out there :) I like idea, but I feel like it would be hair thin separation of the two and possibly "dangerous"... but it is neat, and likely what the user intended.
Fixed by -- we can discuss units more on a separate issue if needed.


When I run jsx --watch src/ build/ it compiles the jsx files and create a file in the build directory. On the next jsx file modification, the jsx process crashes. Once the is present, jsx won't compile jsx files even when ran manually. I use OSX Maverick and jsx 0.8.13.
AFAIK this is a "bug" with or whatever JSX relies on to expose that feature. Just make sure to close the watch instance instead of just closing the terminal/powering down and it should be fine.
Does it work again if you remove the file?
Yes it does. Oh or wait, the crashing.
It seems like there are two ways of fixing this. We can either out why is not cleaning up the file when the process exits, or the functionality and just hope people don't accidentally have multiple processes targeting the same output directory. I'm pretty comfortable with option 2, honestly. Thoughts,
Yeah, no lock seems fine for me, it could warn if it was found perhaps? Another thing to mention that has been happening to me, I'm using React through a Linux VM and accessing the filesystem through samba. When saving a file it immediately triggers a recompile before the file has finished saving, causing it to error. Shortly after it recompiles it again, so no harm, but it's worth noting.
I'm fine with no locking. I didn't even know that existed. Do what works!


After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!


At the end, there is a confusing explanation about "Duplicated data from props" in the section "What Shouldn’t Go in State?": Perhaps what is trying to be said is something like:
Ah, perhaps what they're really referring to is basically "edit pages", where you might want to diff the before and after, so that you can send only the changed variables. But it really reads quite weirdly, especially for beginners.
This change is needed. I'm new to React and just did a Google search on that part of the documentation for clarification and it came up with this page. I'm guessing that what you've interpreted it to mean is correct, as it makes sense that way.


Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.


Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1


! Edits were made last week to this page, maybe it was broken accidentally?
I guess you use https, but the page loads a script over http and that gets blocked. I made a pull request to fix this . I couldn't test it, so fingers crossed that it is right.
I though we were going to remove this page and let this live entirely in the react-magic repo?
The scripts live in the react-magic repo, but I think we'll keep the page on the React site as it's still really useful there.


Idea (that I'm pretty sure I saw elsewhere, react-native maybe?)… We should transform our calls to a conditional wrapping the call. We have to check the condition anyway and this would reduce the no-op function calls. In otherwords becomes Hell, we could replace the with and get rid of the function call entirely, though it really doesn't matter much since we're going to throw (plus we'd duplicate the default string). This might end up be a meaningless optimization…
I believe this is done intentionally (by hand) in some hotspots, so it would seem not. I guess one could argue if it might not make more sense to simply always use the inline style and drop the argument rather than adding another transform?
That's a tough sentence to parse. Are you saying we should always write the "optimized" form? If so I would say "no", the first is way easier to read as a human being.
do you consider something like since jsx has to be transformed anyways? invariant feels more like a contract to me and codes could be more readable if we separate the warning and real implementation, any thoughts?
We have complex invariants that aren't strictly about arguments so while that might be an option for some cases, it doesn't cover us.


The attribute allows for restrictions to be placed on iframes, regardless of domain. It's useful if you're dealing with IE versions less than 10 that don't have the attribute. More info: (v=vs.85).aspx


Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. 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: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond


Do you want to request a feature or report a bug? Bug. What is the current behavior? Right now, React provides a cross-browser workaround for the event. , so React hacks around this by evaluating the selection after both and , which is smart! However, if you haven't an handler to your component, the part of the selection listening hack for Firefox won't ever fire. Which means if you happen to be doing something in that changes the selection, it won't be caught by as expected, such that the next time fires, the handler will be triggered (via the part of the hack), since React thinks the selection has changed. Example: You place your cursor at the end of a sentence. fires thanks to . updates the selection. You the last character: you handle deleting the character, and preventing default. doesn't fire, because on change hasn't taken place yet, as expected. updates the selection. You another character: you handle deleting another character. fires thanks to , but its internal state is comparing it to the selection before it was updated by , so it is out of date. Not expected. If you add a noop handler for , this problem goes away, since will always fire after rendering thanks to , and then it will never fire incorrectly due to . An example is in , actually doesn't do anything. Except without, the handling wouldn't stay in sync in Firefox. What is the expected behavior? Ideally I'd think that the event hack would still fire even without having to have the developer add a noop to their component? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 15 in Firefox.
Thanks for the detailed report Sorry I didn't get to this until now. This should be an easy fix – just adding onKeyUp below onKeyDown here:


There appears to be a typo on line 116 of "codebase-". Specifically, I see one "" symbol. This results in all text after line 116 appearing as one large block of code. See the screenshot below, with the markdown code on the left and the stylized code rendered on the right: <img width="1389" alt="screen shot 2017-01-09 at 2 38 51 pm" src=""Based on the content of the subsequent text after line 116, I would expect it to appear as the following: <img width="1436" alt="screen shot 2017-01-09 at 2 42 08 pm" src=""If this is indeed something that should be fixed, I'd like to fix it, and can submit a PR immediately.
I think you're right, please do submit a PR.
(For future reference, feel free to send PRs for small fixes like this without creating an issue.)


Do you want to request a feature or report a bug? bug What is the current behavior? Selecting of the same value for the twice in a row results in triggering of change event twice for the same value. 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: ). Open and click twice on any option. As the result you'll see in console that change event is triggered each time (even if the changed value is equal to the previous one). For comparison you may check the native html implementation: What is the expected behavior? The change event should not trigger again for the same value. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? macOS Sierra 10.12.5, Safari 10.1.1
cc
Thanks for the report It looks like this . We'll look into this and see if we can include a fix in the 15.6 release.
If you extend the given example with 4 radio elements (), fires only once per radio. In other words, the event is not fired if a value for a name changes. Might as well rename to () so it is clear when the callback is fired. But it seems to be a different problem than what is describing. Tested on Google Chrome Version 59.0.3071.86 (Official Build) (64-bit).
Same as mentioned above, uncontrolled radio inputs in my project just stopped working as was expected, they stopped calling the onChange function if a radio button was checked before.
This particular issue was filed before 15.6 release so I don't think what you're describing is related to it. Can you confirm your bug is the same as
yes i think this particular issue is not related indeed. I am almost certain the is the same bug I have the example here: sorry about the confusion
Thanks to and comments in I managed to understand that my reported issue is only affecting uncontrolled radio inputs. Here is a working example of controlled radios working as expected:
While solutions works, I would love to see this fixed in React 15.6 release. Any news on this, it's been a few months. Thanks!
I'm unable to reproduce the issue reported with the latest React 15 release: The issue where it only fires a single change event per input seems to still be a problem, which we will investigate separately. Thanks!


<!-- 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? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with: React 16.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens. ~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.


I’ve seen the “rendered fewer hooks than expected” invariant a couple times now pointing at a component rendered as a part of an error boundary that just caught an error when that component does not use hooks at all. I’ve been able to fix this issue by un-commenting: I haven’t been able to produce a minimal test-case yet . I’m reporting anyway with the temporary fix that worked for me in case you have any insight on what a minimal test-case could be. I’ll update this issue if I keep running into the problem and I can create a minimal test-case.
I ran into the issue again and was able to produce a small repro: Pressing the “throw” button results in the invariant: With a component stack of: Which is weird since has no hooks!
Wanna look into fixing? Should be easy — there must be a missing call somewhere. Or maybe doesn't reset everything we need.
I looked into it, wrote a test, and discovered it’s fixed on master The test is broken on 16.8.6, I didn’t bother bisecting to find the commit that fixed it. PR for the test: .
I thought I was seeing this in 16.9, but it turns out we were on and , and both need to be updated for this to work.


: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks


<!-- 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? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
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!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is


React version: 16.13.1 This code works fine when using plain , but fails: when is enabled: The warning is caused by an exception happened in this block: This is happening because module brings its own implementation of the object with slightly different behavior which requires context to be properly preserved. This one-line change should do the fix: This issue has also been reported to React-testing-library, which has similar code: Why should this be a fix in React and not in ESM? React relied on undocumented behavior of Node modules loader. It was never guaranteed that it will work without proper context. In fact, it will not work as expected if you try it with any non built-in module The current code in React may break in future if module will be replaced with anything else, or if changes their internal implementation.
Do you want to submit a PR It sounds like a reasonable thing for us to fix.
I could, however I am not sure about testing part. What kind of tests would you expect for this?


Describe what you were doing when the bug occurred: on commits greater than 3s through the commits doing a next next Please do not remove the text below this line DevTools version: 4.10.1- Call stack: at updateTree (chrome-) at getCommitTree (chrome-) at ProfilingCacheProfilingCache.getCommitTree (chrome-) at CommitFlamegraphAutoSizer (chrome-) at Hh (chrome-) at qi (chrome-) at mk (chrome-) at lk (chrome-) at kk (chrome-) at ck (chrome-) Component stack: at CommitFlamegraphAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevToolsDevTools (chrome-)
Can you reliably reproduce this? If so, can you please share a repro case with us? (The bug is unlikely to be fixed without out.)
Should I be providing the profiler json? Because using a recording profiler json or the use case, I mentioned above, it reproduces always. Or are you looking for a repository where this can be reproduced?
Ah, sorry my original request was unclear. No, profiler JSON would likely just show that an element is indeed missing. A repro case (where I can run the code, see where/how/why DevTools misses the element) is what I need to fix.
Argh. So this is going to sound weird. I have a project where I can reproduce this, and I can do that always (see the date @ screenshot) but I can't ship it out due to a lot of internal tooling. So, I tried a similar use-case in my and I cannot it reproduce in that . I'll try some more and see if I can reproduce it in my personal project. The image below is from the project which I can't ship !
I would be willing to sign an NDA or similar agreement if that would help. Otherwise, it would be super helpful if you were able to reduce it to something that you could ship. (Maybe you could start with your full app and remove things until you get to the smallest case that repros the bug? Then you could share just that?)
Friendly ping. Any update or chance of one?
Hey try the below: Use this repo . The movie attached should help w/ repro steps. I also left some silly comments in - if you wanna try those out as well (somehow I feel they contribute to this trace - I could be wrong there). I haven't experimented much w/ the different yarn, node and npm versions, but below the ones which kinda did it. https://user-
Thank you for the repro! Holiday time so I might not take a look right away, but I'll try to look soonish.
I knew there will be so many edge cases for these unfound fiber errors Anyway, based on repro, the problem (for this case) is that there's a error thrown I think by the recursive function due to the big number of elements that it needs to mount. I reproduced it in . Here's the steps to reproduce it: profiling Show button Hide button profiling
That's good insight. Can confirm this on my side as well, (though only if I disable the host component filter). My intuition when writing DevTools was that it would be very uncommon for apps to have React trees deep or wide enough that the recursive function (or similar functions, e.g. ) would run out of stack. I think that's true, but given how large the user base is I guess it makes sense that it happens sometimes. I took a stab at rewriting the recursive methods in the backend/renderer in but didn't get them all (, , , ) because it would have been a big change and would make the code harder to read. Maybe worth picking back up and finishing that effort. Anyone interested? The good news is, DevTools has decent unit test coverage.
Hi I may not be able to start till next week, but I'd like to give it a shot if you're cool with it
Sounds great Keep me posted.
Friendly ping on this. Had the same issue multiple times and fallback to console log debugging
Circling back around to this. Using the excellent repro steps () shared by I can repro this faster if I change the default items (in ) from to . Then just loading the app, I notice the following error (in the console): If I ignore this error and profile anyway: the number of list items from 5,000 -0 several errors (in the DevTools extension console, likely caused by the stack overflow above): profiling an error now in DevTools UI (related to the previous errors): So the underlying cause here, as pointed out by is the original stack overflow error.
Converting all of the recursive methods in DevTools to be iterative would be a bit lift but I think I can fix this particular case by iterating over siblings rather than recursing. I'll post a PR shortly.


<!-- Please answer both questions below before submitting this issue. --Please provide a link to the URL of the website (if it is public), a CodeSandbox () example that reproduces the bug, or a project on GitHub that we can checkout and run locally. If possible, please describe how to reproduce this bug on the website or app mentioned above: <!-- FILL THIS IN --<!-- FILL THIS IN --<!-- FILL THIS IN --<!---------------------------------------------------<!-- Please do not remove the text below this line --<!---------------------------------------------------DevTools version: 4.13.1- Call stack: at chrome- at (chrome-) at chrome- at listener (chrome-) Component stack: (none) GitHub URL search query:
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example:
I am also having this bug
See the comment above please :) Repro is needed.
This happened to me, the node wasn't appearing in the Components tree and I was getting this error. The problem was that my attribute was way too long
! suddenly having this issue right now. I thought it was because of my commits, but changing to another old branch just give the same errors. it was working just fine yesterday, don't know why. maybe due to the devtools update or something? btw I'm on react 16.8.6, react devtools 4.13.3 (5/19/2021)
Try updating to the latest release (4.13.4) just to rule anything out. But if you're still seeing the issue, then we still need a repro case.
at first the bug still persists. with same error log. then I retried close the devtools and opened it again (I think I actually have done this as well before) then somehow it works now. the error log still shows up but at least now all components are showing on the devtools, and that's all I need. in addition, I found this ! and I was trying to hide that component (which has no recent changes on it) to see whether it has any impact. or any component that last showing on the devtools. but for now, that'll be all. thank you for responding
I appreciate the extra information, but this isn't a description that I can use to reproduce (and fix) the bug. I need an actual website (or code) that I can run along with instructions (like "do this, then this") so I can see the bug.
There are some simple code could help reproduce. You could try following code sandbox link. The reproduce steps are: "Do not" open develop panel. to develop panel and go to react dev tab. Errors was shown. I guess it's kind of race condition. When I change the component order such as It will work perfect. Ps: brief explain what component do. The PageLoadProgressHandler will dispatch float element to PopupPool.
Excellent! Thank you, Super interesting that this bug only occurs if you wait to open DevTools until after the page has loaded.
I think it is because only have two components, I have two sites, one it will always happen, another will random happen. or maybe code-sandbox do some strange things.
This is interesting. The reason DevTools throws is that the Fiber's owner (the attribute) points to a Fiber that hasn't been mounted yet. That seems unexpected. This repro is just a wrapper around two NPM packages. Where's the source code for these packages? :D Edit I found it, although there's a lot of indirection here_. Tracing one package which imports another which imports another. Would be helpful if it were flattened but I guess I can always step through the bundled source.
PopupPool: PageLoadProgressHandler: Good luck... XD.
Interestingly, if I copy the , , and source files into the sandbox (and only change the import statement in ) the bug goes away. That's surprising.
I wonder if I'm running slightly different code? The debug log shows a slightly different tree structure. Is the version of the source you linked me to the same as the one the Sandbox points to in NPM, Edit Looks like the repro is using 0.18.8 (released a couple of months ago) but the latest NPM release is 0.11.1. That being said, it doesn't look like the files that are being imported have changed (at least not in source) so I'm still not sure what's up.
I change two main components to hook style then get better performance, it reduce the error happen, but I still could get error. Some error is happen after component render done and open the panel same behavior with pervious. I'll log my changes in following issue ticket.
Would be nice to get a smaller reproduction of this issue (all of the code in one project, rather than spread across many NPM packages). That's what I was trying to do with moving the source but then the bug goes away b'c the code seems to be different. I noticed one potential difference being the indirection but I'm not sure how likely that is to be related.
Looking at the error while debugging, it looks like the , then either renders it or dispatches a popup event to show it. I'm not sure why (too sleepy to think it through maybe) but sometimes seems to be mounting before_ has, which goes against an assumption in DevTools. Will dig back in tomorrow.
I really appreciate the repro case, but there are so many layers of indirection between the various NPM packages being used to dynamically create the components. It's difficult to trace through. I'm going to hand this issue to you and ask for a smaller repro case. (Without 10+ NPM projects that each require each other.) Is this something you can help with? Edit I fixed this () but the test case I is not great since it relies on unsupported side effects to trigger the problem case. I'd still love to get a smaller repro so I can (1) be sure I fully fixed the problem and (2) add a regression case so it doesn't get re-introduced.
Bugfix released as
thank you fixed on version 4.13.5
Thanks your effort. Your fixed also be success from my side.


DevTools named hook parsing logic currently matches AST nodes using the original line number: But this may not be sufficient, as mentioned in comment
While we're on the subject: Column numbers in particular are where a lot of inconsistencies between tools/engines' representations occur and off-by-one errors creep in. V8, SpiderMonkey, JSC all use 1-based lines and 1-based columns in . Hermes follows the other engines for the most part but has its own thing going on for bytecode addresses (printed similarly to columns but 0-based). See the in React Native. VS Code uses 1-based lines and 1-based columns. The library (at least AFAIK from older versions) uses 1-based lines and 0-based columns in its API. ESTree/Babel ASTs use 1-based lines and 0-based columns. The Chrome DevTools protocol uses 0-based lines and 0-based columns. So I suspect we have an incorrect conversion already - we should fix it and signpost assumptions/conversions more clearly.
Reopening to address this follow up comment from


Currently the CHANGELOG shows 4.3.0 as the latest version of , but at least on , there is not a 4.4.0. React version: n/a Changelog to version on Link to code example: n/a No 4.4.0 explanation in 0 explanation in
I think 4.4.0 was essentially a no-op release to correspond with React 18 release (though cc to confirm). Looking at what's changed in the package between the 4.3.0 release and Monday's 4.4.0 "release" I see: I believe this is the same thing as happened with the ESLint 4.2.0 release and React 17. I believe the "fix" here would be to just add a 4.4.0 release to the CHANGELOG that notes this.
Thanks so much That definitely seems like the right fix!


<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: main branch "" in " and its " <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --The page is 404. The page should exist.
Fixed by


Can't send ArrayBuffer to Server Action despite saying that you can. I'm not sure if this is an error or my part or the documentation. I retrieved the arrayBuffer from file of formData, then pass it through the parameter of the Server Action. It seems like it doesn't get sent to the server because it can't be parsed due to ArrayBuffer being serializable but not iterable. However this is somewhat confusing because you can attach File in FormData in the form of Blob and send it to the Server Action. I understand that FormData is but I'm not sure I understand why it can't be done the same with ArrayBuffer. I understand that I can just pass the FormData to send files but In my case I needed to transform the Files first before uploading and it ends up with a Blob. <!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: form, input, submit button, and also onSubmit function using Client Action the arrayData from the formData then pass it to server action <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: -- Throws client-side error ArrayBuffer gets sent to the server The documentation: <img width="583" alt="image" src=""Please let me know if I fail to understand the documentation or if it's something wrong in the documentation
I'm having the same issue.
Wokraround: I've tested multiple react/nextjs version combinations and now found working one. For me it's nextjs 13.5.6 and react 18.2.0. Reply pls when you try it out)
I will test. I'm using and
The workaround i have for now is to wrap the data with FormData first and append the file before sending it to the server action
It seems that shipping as parameters of the server action is enabled, but returning from the server action is still not enabled.
as per the documentation, that is the intended behavior
They're supported as return values in Server Actions in React's Experimental release channel. Sending to Server Actions is currently not supported but we want to achieve parity eventually. I'll file a PR updating the docs accordingly.
Will be supported by
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
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!