The last two assertions in this new test don't pass because of the duck-typing check in . Not quite sure what you had in mind here. Not every object whose is a component class is a valid descriptor… right?
This is an intermediate step. Currently the duck typing is flawed regardless. Descriptors will probably get an inheritance chain so that instanceof ReactDescriptor works as a safer check. Only descriptors should pass. We could probably check for props too. It is expected that component classes themselves fail the test. Therefore it should also be renamed. On Feb 24, 2014, at 7:42 AM, Ben Alpert wrote:
Right -- with the current code, returns true when passed a component class, which is wrong.
That's right. We should add that unit test. Out of curiosity, how did you find this? On Feb 24, 2014, at 1:51 PM, Ben Alpert wrote:
I was adding a warning for passing a component class to renderComponent because of this Stack Overflow question:
I think this is fixed. Not sure if we have a solid unit test to cover this.


React adds a scroll listener that tracks and caches the scroll position (I assume for some undocumented internal purpose). Additionally, the scroll listener forces a synchronous layout (see screenshot). This seems wasteful, especially considering that the values tracked are never exposed in the API. What is the scroll listener used for? Can it be removed? !
ViewportMetrics is used to normalize pageX and pageY on mouse events: . Perhaps ironically, it was created to prevent synchronous layouts during mouse event handlers.
I wish these values (as well as the event) were somehow exposed.
:+1:
BTW you can obviously have this if you use a Webpack-like bundler:
Well, is only used for IE8 and possibly other very old browsers (), so we should be able to just disable it for all other browsers and everyone is happy right? (Could still be optimized slightly for IE8... if anyone cares) Also, That makes no sense at all to me, does not take an argument, yet we get the scroll position and provide it as an argument. Instead, gets the scroll position internally and uses that? So we call twice, but only use the result once (also, this should be broken for events inside iframes, for IE8). Also2, I'm pretty sure any browsers that supports touch, also supports . cc
I agree that we shouldn't be tracking it in other browsers if we don't need it. I don't know if there's a way to predict whether we'll have .pageX and .pageY before mouse events actually come in.
:)
Another idea being just let resize/scroll set a flag, when a mouse event is created, if the flag is set, update viewport metrics. That way we only update it when needed, but could potentially cause a reflow if there are other events before it (very unlikely though I imagine).
This issue causes React based longer lists unusable on mobile.
Is there any progress on this issue? I’m not sure if this is the root-cause for pages rendered with react scrolling extremely slow with firefox mobile on android (e.g. this react website ).
Is that your site? If so, you can try commenting out the logic in refreshScrollValues to see if it makes a difference. If it does, I'm happy to prioritize and try to get it in.
No, that is not my site, it is an example react & fluxible page (see: ), but we have exactly the same issues with scrolling on firefox mobile. I’ve applied the changes in manually and it doesn’t solves the problem, so this issue might be unrelated to my problem. I will investigate further. Thanks for considering to prioritize this. Much appreciated.


I am working on a project that has strict accessibility requirements. The table I am putting some data in has to implement headers and ids attributes to meet accessibility. See W3 techniques here Unfortunately the "headers" attribute is being stripped out because it's not supported by React (it's not on the supported attributes list). Can you please add support for the missing standard attribute called "headers"?
+1
As a workaround I believe on a you can grab the DOMNode with a ref and add what you need.


If we claim to support IE8, and users are testing their code locally in IE8, they might get thrown into compatibility mode by default. This will cause their webapp to blow up, and they will be confused because IE8 is a supported browser. For background, check out this thread: Users can get out of compatibility mode by adding this tag: Since the current failure is cryptic, and it's easy to detect when IE8 is in compatibility mode (), we should probably add a warning to give a hint to the user that even though they're using IE8, they're actually in compatibility mode (effectively IE7) and should add the meta tag or use one of the other various workarounds.


Since copy+pasting our code makes it too easy for people to XSS themselves, lets just add a comment in there about it.
PR at - let me know if that's what you had in mind!
My intuition is that it makes more sense to fix the example (call a sanitization library) or to change the example completely (demonstrate something else that is safer). It looks really bad to have a security warning on the homepage of the react site. Makes it seem like our framework encourages unsafe operations, rather than a safe-by-default way of doing things.
Should switch the demo to use a different library like markdown-js that escapes everything and doesn't support HTML:
markdown-js looks good. First attempt: ,output Code licensed if someone wants to turn this into a coherent example; I've signed the CLA.
That's a good suggestion too :) - what are your thoughts? I'm happy to change the example to use like people have suggested above. nice usage example :+1:
Uh yea, that sounds fine to me. This behavior is definitely non-standard markdown but it's an example so not a big deal. We should probably do the same for the tutorial while we're here. And it's on cdnjs so that's all pretty easy:
Just going to use marked instead, which I'm already familiar with and has an option to sanitize input.


Calling on in a component being Shallow Rendered will result in the error being thrown. I set up a test case:
Who would be best to answer this one?
Seems like a valid bug report — thanks and the test case is rad. I may not be able to look at this for a while, unfortunately.
no worries let me know if you need any more info from me. This was on React 14 beta btw (not sure if that matters)
I have the same issue. A simpler example that throws the error:
Any way of getting around this issue? I am currently running into it.
Sorry about the slow response from us (FB) here. I'm the principal author of the shallow render feature, but React core isn't my main gig and I've been swamped with product work. I don't have an offhand answer for you, but I've just put time on my calendar to look into this next week. Jim, Ben, Paul — if by chance one of you happened to take care of this before then, I wouldn't be mad :)
An update on my end. I think that my problem actually went away when I deduped my npm dependencies to remove an extra react version that was causing issues. If this error pops up again I'll let you know. Thanks for the response! On Fri, Aug 28, 2015, 9:38 PM Scott Feeney wrote:
Hmm I am still able to reproduce this issue in my test case after running npm dedupe
Just to clarify, my previous comment wasn't supposed to mean that the issue has gone away. I think I was seeing a separate issue caused by multiple react versions that I misidentified as this issue (I hope that makes sense).
I am getting this error, too. I'm using react v0.14.0-rc1. Looking at the code : Apparently .
Note that shallow rendered components override to return a instead of whatever it normally returns. That still shouldn't be undefined and should have a attribute, though.
I'm experiencing this issue too - your suggestion gets me past the initial error & on to in
Pretty sure this breaks many other things outside of , but I noticed moving to be directly above in fixed this for me.
We are also affected by this issue. I think shallow rendering is a really cool feature for testing, but unfortunately I can't use it for some of our components due to this bug.
I created pull request with a fix that works for me. Can someone else verify?
Any workaround for this issue?
:+1: Having same issue
Just ran into this too :/
Any update on this? I see that 0.14.3 was released, but these kind of tests are still failing.
I think I have to add a test to my pull request before it can be merged, but I did not get around to do it yet.
Closing in favor of which should merge soon.


I'm trying to use the attribute as described here: Unfortunately, sometimes returns , when is called multiple times. MWE:
This is intended – when the component is unmounted or the ref changes, the old ref gets called with null before it's called with the new value (or the same component instance again). If you store the instance on your component, this effect should be unobservable as long as your component is mounted, but it prevents memory leaks. If you want to do something with in the ref handler, you should check if it's null.
Thanks for the information! I think this might be worth mentioning in the docs.


Issue with the reproducible example . Full build contains non-standard iterator. Theoretical, it can be to ES in the future, it can be (or already ) to another libraries. should take into account possibility iterable numbers.
Well, the good news is that if this is already on enough pages, then introducing iterable numbers may not be web compatible anyway. I think that this is only in DEV only code. Unfortunately a lot of pages incorrectly uses the DEV build of React.
"good news"


I'm still quite new to React, but I guess this is a bug in the React framework introduced in 0.14. Seems like all listeners attached with JSX are broken in native Android browser for Android LTE 4.3, when compiling code with NODEENV development. Everything works fine with NODEENV production compilation. I've tracked it down to being related to ReactErrorUtils, that in development mode do guards on events. The source code: If I simply remove that part of code after compiling the React app, the listeners starts working again. I guess this is not intentional, but instead a bug? To reproduce problem in Android LTE 4.3 (code that works in e.g. Chrome Browser): Using the pre-compiled Getting Started lib
Hm. That's unfortunate. I guess we'll try to find a feature test for this and patch it.


Oddly enough, the two examples below are not equal as I thought they would be. The error is as follows: I'm assuming that is because the function as assuming an optional callback. But I would expect your code to do a typeof check, and not just a defined check. Can we change it to do a check? I can submit a PR.
Well, the typecheck happens with that exact typecheck, just not directly in forceupdate. Here's forceUpdate: and where the invariant happens: FWIW, is not the same as due to an important distinction. The former makes a new function that is bound but it will pass along any arguments. The latter also is a new function but it explicitly doesn't pass any arguments. So the former gets the event passed along while the latter just drops it. The event isn't callable, thus the invariant. We need to do the typecheck so I guess we could discuss whether we keep it as an invariant or a warning. But it is a misuse of the API.
To follow up on that, the more "equal" thing would be: Which should throw the same error that you see with your first bind example.
Correct. Yes, I understand all of that. It wasn't toooo hard for me to understand what is happening. And it is a misuse of the API. So I guess, I would consider adding the argument type to the invariant to help make it clearer? Something more like: It's kind of moot. But It confused me for a second. Might confuse others also.


Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.


The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.


(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 :-)


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.


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.


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:


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.


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.


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.


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


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!


<!-- 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


Do you want to request a feature or report a bug? Bug (for electron users) What is the current behavior? When running jest, if any components containing a webview element are rendered, a warning is rendered to the console. When many tests are run, the output is littered with warnings. 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? No warning is logged to the console. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React: 16.4.1 Electron: 2.0.6 Unknown if it worked in prior versions of react.
What other special tags does Electron have?
Looking through their docs it seems to be only the tag for now:
In that case I don’t mind adding it to the whitelist. Send a PR?
You beat me to the punch. Thanks so much and


With this: If I render again after it resolves, it won't get the default prop value. This is a bug.


<!-- 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? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost. I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.


Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.


Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via


<!-- 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: Current main branch the repository from the main branch node and yarn (node version: 16.14.0, yarn version: 1.22.17, JDK version: tried both 11 and 17) yarn yarn build <!-- 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. --Error message : <!-- 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: --No error messages from rollup. Success in yarn build.
If rollup is crashing during the build process, that's a rollup problem.
Yes, that was what my colleagues and I are thinking too. Then shouldn't something change related to Rollup, like going back to the previous version of code, or another way to resolve the error in the react project?
Exactlly it's the problem of Rollup and already fix it two years ago. See
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!


When trying to build the [(]) locally: react yarn build-for-devtools from the root repo node version: v16.16.0.
This is the result of :
Yarn is the package manager of choice in this repository. Did you run from the root first?
I did not do that as I dont usually work with yarn. I will try now. Please reject my bug and thanks for your time. I feel a bit stupid.
Im trying it now, and it looks like its working. It would be great if someone adds this to the readme of the extension repo.
Sorry to hear. We definitely want to avoid that. You're absolutely right. I'm on it.
Please note also that they ask to do: . The command has , which doesnt work for windows and should be replaced by . This is the command:


<!-- 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: 18.3.0-canary-- SSR app that has images in its tree using renderToString or renderToPipeableStream <!-- 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: --! To not insert preloads randomly. Note that there is difference between renderToString and renderToPipeableStream, renderToString the preloads appear inside root and renderToPipeableStream they appear in head. Sorry this is a bit of a question rather than bug report maybe, I have searched around and cannot see any mention of auto-preloading images but I assume there must be something going on that I have missed. I was able to fix by using .
This. Tested with . It would be "kinda" tolerable for the LCP image above fold (featured image or similar), but we have lots of lazy loaded images below fold which contain <noscriptalternatives like: For every tag used in noscript, the image is preloaded in which completely defies the purpose of lazy loading.
I think this is actually now expected behaviour, after digging the source a bit I found Though I could not find any docs/release notes that mention this which is a little odd as now you need to explicitly think about the loading strategy of every img tag you use. For me I was able to "fix" this by making sure all our img tags have either loading=lazy or fetchPriority=low when they are not to be preloaded, this gave me more or less only the LCP images preloaded. For your case you could either add loading=lazy or fetchPriority=low to the fallback images, though depending on your target browsers you could get rid of the noscript parts these days as loading=lazy has pretty wide browser support now. Would be good to have this documented somewhere and also maybe add this to the react linter.
Thanks for the info regarding loading=lazy, that could solve it. If this is really a "feature", I have to say, I don't think it should be React's business to put stuff into my automagically…
Which framework are you using?
For me, its Remix.
You're probably using their image component that uses . Or they're doing calls some other way. Can you open an issue on their issue tracker first to clarify?
I'm not using their image component but , but I will take a look at Remix & React Router code, whether they call this somewhere and open an issue. Interestingly, this behavior is only applied by Remix (or happens for some reason), when upgrading to React canary.
React is adding support for Suspensey "resource". For instance if you render a stylesheet and opt into React's handling of this using "precedence" then commits which contain this stylesheet will wait to commit until the sheet has loaded. Another area that we're making Suspensey is images. Lazy images indicate that they do not require suspense coordination but by default images will (in the future) block a boundary reveal until the image has loaded and been decoded. While these features are for client updates there are analogs for SSR. for stylesheets browsers already block paint until stylesheets load in the head. They don't however do this for images. React canaries now preload the first few images rendered if they are not lazy because we want to mimic the coordinated reveal of Suspensey images along with the first paint. It's not a perfect heuristic because it's not actually enforced to be coordinated but it does better align the behavior across suspensy vs lazy images. Another way you can signal to React that an image is not expected to be part of the first paint is to set the fetchPriority to "low"
For every <imgtag used in noscript, the image is preloaded in <headwhich completely defies the purpose of lazy loading. This is a genuine bug. will land a fix
Good to know, thanks for the explanation.
fwiw no framework used just renderToPipeableStream, in my case I was able to add low priority to a few icon images to get the preload to load reasonable candidates. Would be good to be able to opt-out of this somehow for a boundary, thinking of the case where you are waiting on component/data to load and don't really care about the image but lazy loading would be inappropriate for an above the fold larger image. Maybe even a way to modify the heuristic via some sort of callback would be useful.