{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":155438125,"defaultBranch":"main","name":"react","ownerLogin":"gnoff","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2018-10-30T18:40:15.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2716369?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1714660753.0","currentOid":""},"activityList":{"items":[{"before":"da0b480525a561fcec62cdf7950bd5c3303f6e9f","after":"946168d3ae9c9962b5db2fe191c6ae1018459dcc","ref":"refs/heads/suspend-boundary-on-sync-stylesheet","pushedAt":"2024-05-10T23:58:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Fiber] render boundary in fallback if it contains a new stylesheet during sync update\n\nWhen we implemented Suspensey CSS we had a heuristic that if the update was sync we would ignore the loading states of any new stylesheets and just do the commit. But for a stylesheet capability to be useful it needs to reliably prevent FOUC and since the stylesheet api is opt-in through precedence we don't have to maintain backaward compat (old stylesheets do not block commit but then nobody really renders them because of FOUC anyway)\n\nThis update modifies the logic to put a boundary back into fallback if a sync update would lead to a stylesheet commiting before it loaded.","shortMessageHtmlLink":"[Fiber] render boundary in fallback if it contains a new stylesheet d…"}},{"before":"c4cb74792a131f7e45fd0f98d0e1762f3c3266e1","after":null,"ref":"refs/heads/update-critical-projects","pushedAt":"2024-05-02T14:39:13.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":null,"after":"c4cb74792a131f7e45fd0f98d0e1762f3c3266e1","ref":"refs/heads/update-critical-projects","pushedAt":"2024-05-02T03:52:57.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Tooling] Update critical artifact list\n\nWhen a React PR is opened CI will report large size changes. But for critical packages like react-dom it reports always. In React 19 we moved the build for react-dom the client reconciler from react-dom to react-dom/client\n\nThis change adds react-dom-client artifacts for stable and oss channels since that is originally what was being tracked. But since react-dom/client always imports react-dom I left the original react-dom packages as critical as well. They are small but it woudl be good to keep an eye on them","shortMessageHtmlLink":"[Tooling] Update critical artifact list"}},{"before":null,"after":"da0b480525a561fcec62cdf7950bd5c3303f6e9f","ref":"refs/heads/suspend-boundary-on-sync-stylesheet","pushedAt":"2024-05-01T23:34:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Fiber] render boundary in fallback if it contains a new stylesheet during sync update\n\nWhen we implemented Suspensey CSS we had a heuristic that if the update was sync we would ignore the loading states of any new stylesheets and just do the commit. But for a stylesheet capability to be useful it needs to reliably prevent FOUC and since the stylesheet api is opt-in through precedence we don't have to maintain backaward compat (old stylesheets do not block commit but then nobody really renders them because of FOUC anyway)\n\nThis update modifies the logic to put a boundary back into fallback if a sync update would lead to a stylesheet commiting before it loaded.","shortMessageHtmlLink":"[Fiber] render boundary in fallback if it contains a new stylesheet d…"}},{"before":"76716212bbdf6cf29dc0ad6f83424ee84c313d08","after":null,"ref":"refs/heads/asynccurrentowner","pushedAt":"2024-04-25T17:40:46.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":null,"after":"76716212bbdf6cf29dc0ad6f83424ee84c313d08","ref":"refs/heads/asynccurrentowner","pushedAt":"2024-04-25T17:29:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Resolve cycle","shortMessageHtmlLink":"Resolve cycle"}},{"before":"6beead9ad38014bfce9cddb004fa52e67c16f99f","after":"6c0f74a94e84f4e12a7f9739adfe4a21c6b073af","ref":"refs/heads/render-microtask-pings-sync","pushedAt":"2024-04-25T01:01:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Flight][Fizz] tasks that ping in a microtask should render synchronously\n\nThis change modifies the ping mechanism for FlightServer and FizzServer to perform work synchronously if infer the ping is happening in a microtask. The heuristic is to consider whether we're already in a \"work\" phase which is only cleared in a second macrotask scheduled alongside the work task. If we are and the task is the only task in the queue we assume we're in a microtask and immediately retry the task.\n\nThere is an edge case however that I suspect can crop up where a ping is interleaved between a work task and the flush task. If this happens it will also appear like a microtask and be retried synchronously. While this isn't the intent of the PR this also isn't breaking any semantics so this should be fine.","shortMessageHtmlLink":"[Flight][Fizz] tasks that ping in a microtask should render synchrono…"}},{"before":null,"after":"6beead9ad38014bfce9cddb004fa52e67c16f99f","ref":"refs/heads/render-microtask-pings-sync","pushedAt":"2024-04-25T00:57:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Flight][Fizz] tasks that ping in a microtask should render synchronously\n\nIf a task pings in a microtask we have an opportunity to render the task again before flushing. This is likely more performant that enqueing a new task for cache locality reasons but it also has some practical benefits to flushing as well since we can potentially avoid flushing fallback UIs.\n\nThis change updates the pingTask implementation to consider if we're pinging in the same epoch in which the task was spawned. If we are we perform work synchronously rather than enqueuing a new work task.","shortMessageHtmlLink":"[Flight][Fizz] tasks that ping in a microtask should render synchrono…"}},{"before":"b25f3d406fa2b532b9a773b154a20143d75960ee","after":"1c0a3f28032def134f22752dab84eb0b03282e27","ref":"refs/heads/refactor-performwork","pushedAt":"2024-04-24T18:24:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Reimlements with a flushing state flag to avoid an increasing epoch counter","shortMessageHtmlLink":"Reimlements with a flushing state flag to avoid an increasing epoch c…"}},{"before":"31c27429a8a9c5478218dc265b07fdcbd636fc2f","after":"b25f3d406fa2b532b9a773b154a20143d75960ee","ref":"refs/heads/refactor-performwork","pushedAt":"2024-04-24T18:24:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Reimlements with a flushing state flag to avoid an increasing epoch counter","shortMessageHtmlLink":"Reimlements with a flushing state flag to avoid an increasing epoch c…"}},{"before":"9f01b18a501012618c2e0b24c4bf65e07cb3e729","after":"31c27429a8a9c5478218dc265b07fdcbd636fc2f","ref":"refs/heads/refactor-performwork","pushedAt":"2024-04-24T18:15:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Reimlements with a flushing state flag to avoid an increasing epoch counter","shortMessageHtmlLink":"Reimlements with a flushing state flag to avoid an increasing epoch c…"}},{"before":"223ea80f563c4f23cee1b8ada8eae01b5ae1686b","after":null,"ref":"refs/heads/clean-top-level","pushedAt":"2024-04-24T15:50:37.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":"d71af9480d1e8f65621ce99a6e18cfa814b0866f","after":"9f01b18a501012618c2e0b24c4bf65e07cb3e729","ref":"refs/heads/refactor-performwork","pushedAt":"2024-04-24T04:05:45.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Flight][Fizz] schedule flushing independently from performing work\n\nToday work that pings in a microtask in Flight and Fizz will end up being rendered in a new macrotask. This is potentially sub-optimal for cache-locality reasons but it also has an impact on flushing because flushes always happen synchronously after rendering. It would be ideal if tasks that can ping in a microtask get a chance to render before we flush because we can end up with a more compact wire format for flight and we can potentially avoid showing fallbacks for fizz.\n\nThis commit doesn't actually implement rendering in microtasks. This will come in a follow up change. What this change does do is refactor the flushing controls to be able to schedule flushing in a macrotask separately from the render phase. The appraoch uses a notion of epochs to allow scheduled work to infer if it is still valid. For instance if Float causes a flush to be enqueued but then the next task is a ping leading to a render we don't necessarily want to flush before additional renders are allowed to complete. Additionally if there is already a flush scheduled we don't want an enqueued flush from Float to lead to an additional flush.\n\nthe request's flushScheduled property is now more narrowly tailored to represent out-of-band flushes enqueued through float and not the general purpose flushing that is done after every work loop.\n\nthe request now has an epoch property which can be used to determine if we haven't started a new work loop or flush since the task was previously scheduled.\n\nIn some environments schedulWork is synchronous. All the logic still makes sense for synchronous work even if it can have unecessary overhead (such as checking if we're in the same epoch since this will necessarily be true in sync mode). However sync mode is mostly useful for legacy renderers like renderToString and we should probably move away from in for the browser build anyway so I don't think we ought to concern ourselves with further optimization of the sync case.","shortMessageHtmlLink":"[Flight][Fizz] schedule flushing independently from performing work"}},{"before":null,"after":"d71af9480d1e8f65621ce99a6e18cfa814b0866f","ref":"refs/heads/refactor-performwork","pushedAt":"2024-04-24T03:58:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Flight][Fizz] schedule flushing independently from performing work\n\nToday work that pings in a microtask in Flight and Fizz will end up being rendered in a new macrotask. This is potentially sub-optimal for cache-locality reasons but it also has an impact on flushing because flushes always happen synchronously after rendering. It would be ideal if tasks that can ping in a microtask get a chance to render before we flush because we can end up with a more compact wire format for flight and we can potentially avoid showing fallbacks for fizz.\n\nThis commit doesn't actually implement rendering in microtasks. This will come in a follow up change. What this change does do is refactor the flushing controls to be able to schedule flushing in a macrotask separately from the render phase. The appraoch uses a notion of epochs to allow scheduled work to infer if it is still valid. For instance if Float causes a flush to be enqueued but then the next task is a ping leading to a render we don't necessarily want to flush before additional renders are allowed to complete. Additionally if there is already a flush scheduled we don't want an enqueued flush from Float to lead to an additional flush.\n\nthe request's flushScheduled property is now more narrowly tailored to represent out-of-band flushes enqueued through float and not the general purpose flushing that is done after every work loop.\n\nthe request now has an epoch property which can be used to determine if we haven't started a new work loop or flush since the task was previously scheduled.\n\nIn some environments schedulWork is synchronous. All the logic still makes sense for synchronous work even if it can have unecessary overhead (such as checking if we're in the same epoch since this will necessarily be true in sync mode). However sync mode is mostly useful for legacy renderers like renderToString and we should probably move away from in for the browser build anyway so I don't think we ought to concern ourselves with further optimization of the sync case.","shortMessageHtmlLink":"[Flight][Fizz] schedule flushing independently from performing work"}},{"before":"b5a72791b5c770e66c82f62d7aac84350e5cd298","after":"223ea80f563c4f23cee1b8ada8eae01b5ae1686b","ref":"refs/heads/clean-top-level","pushedAt":"2024-04-24T03:40:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Now that react-dom/client is a separate build there are additional internal module boundaries that get picked up by devtoools timeline testing. This udpates snapshots to reflect this expected change.","shortMessageHtmlLink":"Now that react-dom/client is a separate build there are additional in…"}},{"before":"7a9604e8c4419cc721a56af12f04f4a4eeee7e99","after":"b5a72791b5c770e66c82f62d7aac84350e5cd298","ref":"refs/heads/clean-top-level","pushedAt":"2024-04-24T03:31:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Now that react-dom/client is a separate build there are additional internal module boundaries that get picked up by devtoools timeline testing. This udpates snapshots to reflect this expected change.","shortMessageHtmlLink":"Now that react-dom/client is a separate build there are additional in…"}},{"before":null,"after":"e77baa2415f3274f0cc583caeb08bf10559898dd","ref":"refs/heads/single-task-work","pushedAt":"2024-04-23T05:22:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Flight][Fizz] ping work within current task\n\nFizz and Flight both currently have a work schedule that enqueues tasks for retrying in a new macrotask. however it means that any given render will be split across multiple tasks even if any thenables that suspend are available within a microtask. This PR updates the ping mechanism for both renderers to schedule retry work on the microtask queue.\n\nAs we've run into many times in React this is another instance where being able to schedule a microtask to run at the end of the queue would be ideal since we can optimize flushing better.","shortMessageHtmlLink":"[Flight][Fizz] ping work within current task"}},{"before":"baacaf0226d35163879036975e52946a9787038a","after":null,"ref":"refs/heads/18-3-deprecate-rendertostaticnodestream","pushedAt":"2024-04-19T15:18:19.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":"229e7d3886764404f183add844e70c12bcb40e59","after":null,"ref":"refs/heads/remove-rendertostaticnodestream","pushedAt":"2024-04-19T04:06:08.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":"0d4e24bad1b7d24b91db5fade3528e0d9f0d7a16","after":"baacaf0226d35163879036975e52946a9787038a","ref":"refs/heads/18-3-deprecate-rendertostaticnodestream","pushedAt":"2024-04-19T02:12:26.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Deprecate `renderToStaticNodeStream` (#28872)\n\nThis commit adds warnings indicating that `renderToStaticNodeStream`\nwill be removed in an upcoming React release. This API has been legacy,\nis not widely used (renderToStaticMarkup is more common) and has\nsemantically eqiuvalent implementations with renderToReadableStream and\nrenderToPipeableStream.","shortMessageHtmlLink":"Deprecate <code>renderToStaticNodeStream</code> (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2251866030\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/28872\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/28872/hovercard\" href=\"https://github.com/facebook/react/pull/28872\">facebook#28872</a>)"}},{"before":null,"after":"0d4e24bad1b7d24b91db5fade3528e0d9f0d7a16","ref":"refs/heads/18-3-deprecate-rendertostaticnodestream","pushedAt":"2024-04-19T01:59:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Deprecate `renderToStaticNodeStream` (#28872)\n\nThis commit adds warnings indicating that `renderToStaticNodeStream`\nwill be removed in an upcoming React release. This API has been legacy,\nis not widely used (renderToStaticMarkup is more common) and has\nsemantically eqiuvalent implementations with renderToReadableStream and\nrenderToPipeableStream.","shortMessageHtmlLink":"Deprecate <code>renderToStaticNodeStream</code> (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2251866030\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/28872\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/28872/hovercard\" href=\"https://github.com/facebook/react/pull/28872\">facebook#28872</a>)"}},{"before":"a22f1899d32bb1138112f6a1c4bba721db0d2a33","after":"229e7d3886764404f183add844e70c12bcb40e59","ref":"refs/heads/remove-rendertostaticnodestream","pushedAt":"2024-04-19T01:45:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Remove `renderToStaticNodeStream`\n\nrenderToStaticNodeStream was not origianlly deprecated when renderToNodeStream was deprecated because it did not yet have a clear analog in the modern streaming implementation for SSR. In React 19 we have already removed renderToNodeStream. This change remvoes renderToStaticNodeStream as well because you can replicate it's semantics using renderToPipeableStream with onAllReady or renderToReadableStream with await stream.allready.","shortMessageHtmlLink":"Remove <code>renderToStaticNodeStream</code>"}},{"before":"bc4dea669546c5b8d2719502026e233235e15140","after":null,"ref":"refs/heads/warn-rendertostaticnodestream","pushedAt":"2024-04-19T01:33:56.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":null,"after":"a22f1899d32bb1138112f6a1c4bba721db0d2a33","ref":"refs/heads/remove-rendertostaticnodestream","pushedAt":"2024-04-19T01:06:25.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Remove `renderToStaticNodeStream`\n\nrenderToStaticNodeStream was not origianlly deprecated when renderToNodeStream was deprecated because it did not yet have a clear analog in the modern streaming implementation for SSR. In React 19 we have already removed renderToNodeStream. This change remvoes renderToStaticNodeStream as well because you can replicate it's semantics using renderToPipeableStream with onAllReady or renderToReadableStream with await stream.allready.","shortMessageHtmlLink":"Remove <code>renderToStaticNodeStream</code>"}},{"before":null,"after":"bc4dea669546c5b8d2719502026e233235e15140","ref":"refs/heads/warn-rendertostaticnodestream","pushedAt":"2024-04-19T01:01:17.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"Deprecate `renderToStaticNodeStream`\n\nThis commit adds warnings indicating that `renderToStaticNodeStream` will be removed in an upcoming React release. This API has been legacy, is not widely used (renderToStaticMarkup is more common) and has semantically eqiuvalent implementations with renderToReadableStream and renderToPipeableStream.","shortMessageHtmlLink":"Deprecate <code>renderToStaticNodeStream</code>"}},{"before":"c4e3887a57171c657fdc5d453ea810020ac391f1","after":null,"ref":"refs/heads/escape-script","pushedAt":"2024-04-19T00:38:46.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":"0bbbd7ef067ab1bc743e833ebd4db703e88d6ffa","after":"c4e3887a57171c657fdc5d453ea810020ac391f1","ref":"refs/heads/escape-script","pushedAt":"2024-04-19T00:27:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Fizz] escape <script> textContent similar to bootstrapScript\n\ninline script children have been encoded as HTML for a while now but this can easily break script parsing so practically if you were rendering inline scripts you were using dangerouslySetInnerHTML. This is not great because now there is no escaping at all so you have to be even more careful. While care should always be taken when rendering untrusted script content driving users to use dangerous APIs is not the right approach and in this PR the escaping functionality used for bootstrapScripts and importMaps is being extended to any inline script.\n\nthe approach is to escape 's' or 'S\" with the appropriate unicode code point if it is inside a <script or </script sequence. This has the nice benefit of minimally escaping the text for readability while still preserving full js parsing capabilities. As articulated when we introduced this escaping for prior use cases this is only safe because we are escaping the entire script content. It would be unsafe if we were not escaping the entirety of the script because we would no longer be able to ensure there are no earlier or later <script sequences that put the parser in unexpected states.","shortMessageHtmlLink":"[Fizz] escape &lt;script&gt; textContent similar to bootstrapScript"}},{"before":"a61a35d35cc9138f83f1006e354827ede6ccf181","after":null,"ref":"refs/heads/escape-style","pushedAt":"2024-04-19T00:24:30.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"}},{"before":null,"after":"0bbbd7ef067ab1bc743e833ebd4db703e88d6ffa","ref":"refs/heads/escape-script","pushedAt":"2024-04-18T23:47:35.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Fizz] escape <script> textContent similar to bootstrapScript\n\ninline script children have been encoded as HTML for a while now but this can easily break script parsing so practically if you were rendering inline scripts you were using dangerouslySetInnerHTML. This is not great because now there is no escaping at all so you have to be even more careful. While care should always be taken when rendering untrusted script content driving users to use dangerous APIs is not the right approach and in this PR the escaping functionality used for bootstrapScripts and importMaps is being extended to any inline script.\n\nthe approach is to escape 's' or 'S\" with the appropriate unicode code point if it is inside a <script or </script sequence. This has the nice benefit of minimally escaping the text for readability while still preserving full js parsing capabilities. As articulated when we introduced this escaping for prior use cases this is only safe because we are escaping the entire script content. It would be unsafe if we were not escaping the entirety of the script because we would no longer be able to ensure there are no earlier or later <script sequences that put the parser in unexpected states.","shortMessageHtmlLink":"[Fizz] escape &lt;script&gt; textContent similar to bootstrapScript"}},{"before":null,"after":"a61a35d35cc9138f83f1006e354827ede6ccf181","ref":"refs/heads/escape-style","pushedAt":"2024-04-18T23:20:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Fizz] escape <style> textContent as css\n\nstyle text content has historically been escaped as HTML which is non-sensical and often leads users to using dangerouslySetInnerHTML as a matter of course. While rendering untrusted style rules is a security risk React doesn't really provide any special protection here and forcing users to use a completely unescaped API is if anything worse. So this PR updates the style escaping rules for Fizz to only escape the text content to ensure the tag scope cannot be closed early. This is accomplished by encoding \"s\" and \"S\" as hexadecimal unicode representation \"\\73 \" and \"\\53 \" respectively when found within a sequence like </style>. We have to be careful to support casing here just like with the script closing tag regex for bootstrap scripts.","shortMessageHtmlLink":"[Fizz] escape &lt;style&gt; textContent as css"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAERwDEywA","startCursor":null,"endCursor":null}},"title":"Activity · gnoff/react"}