All sites
Data API
Github Data API
Structured JSON data, on demand, with anti-bot bypass built in.
8endpointsRate Limit handled for you
Example (captured live) Open playground
github.com
ExampleJSON responseclick the page to trace a field
{
"full_name": "facebook/react",
"state": "open",
"issues": [
{
"number": 37544,
"title": "Bug:",
"state": "open",
"user": "k3fenix",
"labels": [
"Status: Unconfirmed"
],
"comments": 0,
"created_at": "2026-09-08T15:47:59Z",
"updated_at": "2026-09-08T15:47:59Z",
"url": "https://github.com/react/react/issues/37544",
"is_pull_request": false,
"body": "<!--
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:
## Steps To Reproduce
1.
2.
<!--
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 (https://codesandbox.io/s/new), 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: https://stackoverflow.com/help/mcve.
-->
## The current behavior
## The expected behavior
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37543,
"title": "[DOM] Respect the submitter's formMethod in useFormStatus",
"state": "open",
"user": "zxuhan",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-08T13:14:10Z",
"updated_at": "2026-09-08T13:52:57Z",
"url": "https://github.com/react/react/pull/37543",
"is_pull_request": true,
"body": "## Summary
Per the [HTML spec](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-formmethod), `formmethod` on a submit button overrides the form's `method` for that submission. `useFormStatus()` ignores it and always reports `form.method`:
```jsx
<form action={myAction}>
{/* useFormStatus().method is "get", should be "post" */}
<button type="submit" formMethod="post" />
</form>
```
`FormActionEventPlugin` already resolves the submitter's `formAction` override, so this resolves `formMethod` right next to it: from React props when the submitter belongs to this instance, and from the DOM attribute otherwise. Reading props keeps the `formmethod` React emits for a Server Action button from counting as a user override.
The value is normalized the way the DOM normalizes it. Matching is case insensitive, an unknown value falls back to `get` (the attribute's invalid value default), and a value that renders no attribute leaves the form's method alone (it has no missing value default).
Fixes https://github.com/react/react/issues/33361
## How did you test this change?
Two tests in `ReactDOMForm-test.js`, one per pending status path, covering a submitter without `formMethod`, an override on `<button>` and on `<input type="submit">`, case normalization, an unknown value, and a submitter React doesn't own. Both fail on `main`.
- [x] `yarn test packages/react-dom/src/__tests__` and `yarn test --prod packages/react-dom/src/__tests__`
- [x] `yarn test-stable` / `yarn test-www` / `yarn test-classic` on `ReactDOMForm-test.js` and `ReactDOMFizzForm-test.js`
- [x] `yarn test packages/react-server-dom-webpack/src/__tests__/ReactFlightDOMForm-test.js`
- [x] `yarn linc`
- [x] `yarn prettier-check`
- [x] `yarn flow dom-node` and `yarn flow dom-browser`
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37541,
"title": "[rust-compiler] Cache post-dominator frontiers in InferReactivePlaces",
"state": "open",
"user": "ax1s-x1zz",
"labels": [
"CLA Signed"
],
"comments": 2,
"created_at": "2026-09-08T02:15:20Z",
"updated_at": "2026-09-08T02:19:26Z",
"url": "https://github.com/react/react/pull/37541",
"is_pull_request": true,
"body": "## Summary
Cache each block's post-dominator frontier in `InferReactivePlaces` so it is
computed at most once per block instead of on every fixpoint iteration.
The post-dominator frontier of a block depends only on the CFG structure, which
is fixed for the duration of this pass. The fixpoint loop in `infer_reactive_places`
recomputes it for the same block on every iteration, and also for phi predecessors
inside the phi loop. Caching it mirrors the TS reference, which already does this in
`src/Inference/ControlDominators.ts` (`postDominatorFrontierCache`).
## Why
- Behavior is unchanged: the frontier is a pure function of the CFG, so caching
cannot change the result.
- Reduces repeated work on functions with many blocks and many fixpoint
iterations, where the same frontier is recomputed across iterations.
- Aligns the Rust port with the TS implementation it mirrors.
## Test plan
- `cargo test --workspace` passes (no regressions).
- `bash compiler/scripts/test-e2e.sh --variant babel` shows no change:
- Code: 1809/1810 (same as baseline)
- Events: 1807/1810 (same as baseline; the 3 pre-existing event-shape
failures are unrelated to this change and are documented in the TODO list)",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37540,
"title": "[Compiler Bug]: unused `const x = a?.b` becomes a bare `a?.b;` outside the memo block that declares `a` — ReferenceError at runtime",
"state": "open",
"user": "alejo-hernandez-krevyos",
"labels": [
],
"comments": 0,
"created_at": "2026-09-07T18:12:02Z",
"updated_at": "2026-09-07T18:12:02Z",
"url": "https://github.com/react/react/issues/37540",
"is_pull_request": false,
"body": "### What kind of issue is this?
React Compiler (babel-plugin-react-compiler)
### Link to repro
https://gist.github.com/alejo-hernandez-krevyos/86b0da81923321863e810e6e918da5e1 — `repro-input.tsx` is the 12-line component; the three `repro-output-*` files are the compiler's output from babel-plugin-react-compiler 1.0.0, 0.0.0-experimental-a1856f3-20260507, and the Rust port via oxc-transform-react 0.149.0 (identical result in all three).
### Repro steps
Compile this component (any of the three versions above, default options, target 19):
```tsx
import { useLocation } from "./router"
import { TABLE, detect, routesFor, nameOf } from "./registry"
export function Sidebar({ navigation }: { navigation?: string[] }) {
const pathname = useLocation()
const key = detect(pathname)
const active = key ? TABLE[key] : null
const contextNavigation = active ? routesFor(active.slug) : []
const effective = navigation ?? contextNavigation
const title = key ? nameOf(key) : "home"
// unused, kept for a later design change
const Icon = active?.icon
return <aside title={title}>{effective.length}</aside>
}
```
The compiler moves `const active = …` into a memo block (`if ($[0] !== navigation || $[1] !== pathname) { … }`), prunes the unused `Icon` binding, but keeps its initializer as a bare expression statement **outside** that block, presumably because a property read may have a getter side effect:
```js
const title = t1;
active?.icon; // <- `active` is not declared in this scope
let t2;
```
At runtime this is `ReferenceError: active is not defined` (Safari: `Can't find variable: active`) on the first render of the component. Minifiers keep the name because it is a free identifier, so the production bundle carries it verbatim.
**Expected:** the unused declaration is dropped entirely (its initializer is a pure property read on a local), or the statement stays inside the scope that declares `active`, or the compiler bails out on the function.
**Actual:** a reference to a variable that no scope declares. The source passes `tsc`, ESLint (eslint-plugin-react-hooks 7.1), and unit tests on uncompiled output, so nothing that reads the source can see it — we found it in production, where every page rendering this component crashed.
Removing the unused line, or reading `active?.icon` inside JSX, makes the output correct. Nearby open reports (moved references, different shapes): #34901, #35342, #35386, #36128.
### How often does this bug happen?
Every time
### What version of React are you using?
19.2.8
### What version of React Compiler are you using?
1.0.0 (also reproduced on 0.0.0-experimental-a1856f3-20260507 and on the Rust port via oxc-transform-react 0.149.0)
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37539,
"title": "[rust-compiler] Fix non-ASCII panic in ValidateNoSetStateInEffects",
"state": "open",
"user": "hori-design",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-07T16:16:29Z",
"updated_at": "2026-09-07T16:16:34Z",
"url": "https://github.com/react/react/pull/37539",
"is_pull_request": true,
"body": "## Summary
`get_identifier_name_with_loc` reads an identifier's name out of the source when SSA has dropped it. `SourceLocation.index` is a Babel position and counts UTF-16 code units, but the fallback used it to slice a Rust `&str`, which indexes UTF-8 bytes:
```rust
let slice = &code[start_idx..end_idx];
```
These agree only while the source is ASCII. After any non-ASCII character, later offsets are short by the extra bytes, so the slice reads the wrong span, or panics when it lands inside a character:
```
panicked at crates/react_compiler_validation/src/validate_no_set_state_in_effects.rs:168:30:
start byte index 637 is not a char boundary; it is inside 'う' (bytes 636..639 of string)
```
The panic aborts validation for the whole file, so every diagnostic in it is lost.
`validate_no_derived_computations_in_effects.rs` already converts correctly in its own copy of this function. Both were added in #36173 and only one got the UTF-16 handling, so this ports that logic over.
Found through Biome, which embeds these crates for its `useReactCompiler` rule.
## How did you test this change?
Added `repro-setState-in-effect-non-ascii-source.ts`, which panics before this change and compiles cleanly after:
```
bash scripts/test-rust-port.sh ValidateNoSetStateInEffects \
packages/babel-plugin-react-compiler/src/__tests__/fixtures/compiler/repro-setState-in-effect-non-ascii-source.ts
```
The non-ASCII comments in it are test input, not documentation; removing them realigns the offsets and the crash disappears.
Everything `compiler_rust.yml` runs is green on macOS arm64, including `scripts/test-rust-port.sh` (1811 passed) and `yarn snap --rust` (1812 passed).
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37538,
"title": "Kitchen sink changes",
"state": "open",
"user": "aguashui",
"labels": [
"CLA Signed"
],
"comments": 2,
"created_at": "2026-09-07T15:01:06Z",
"updated_at": "2026-09-07T15:40:43Z",
"url": "https://github.com/react/react/pull/37538",
"is_pull_request": true,
"body": "Fix typos, grammatical errors, and misspelled identifiers across React core, DevTools, bindings, test suites, scripts, and compiler packages.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37537,
"title": "[compiler] Preserve JSX pragmas before generated imports",
"state": "open",
"user": "wapgear",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-07T12:54:47Z",
"updated_at": "2026-09-07T12:54:54Z",
"url": "https://github.com/react/react/pull/37537",
"is_pull_request": true,
"body": "## Summary
Fixes #36460.
React Compiler inserts generated imports before leading JSX pragma comments. Downstream TypeScript JSX transforms then ignore those comments, selecting the default runtime or factories instead of the ones requested by the source file.
Move leading JSX pragma comments onto the first generated import so they remain before code. Keep unrelated statement annotations on their original statement.
## How did you test this change?
Added three regression tests: two pass React Compiler output through TypeScript's JSX transform and check the requested runtime and factories; the third checks that unrelated statement annotations stay attached. The two behavioral tests fail against the original implementation and pass with the fix.
Validation in `compiler/packages/babel-plugin-react-compiler`:
- `node node_modules/jest/bin/jest.js --selectProjects main --runInBand`
- `yarn ts-node node_modules/.bin/jest --runInBand --selectProjects 'e2e no forget' 'e2e with forget'` (16 tests passed)
- `node ../snap/dist/main.js --sync` (1,811 fixtures passed)
- `yarn build` and `yarn lint`
After simplifying the implementation and tests, reran `Imports-test` (all three passed), ESLint on `src/Entrypoint/Imports.ts`, Prettier on both changed files, and `git diff --check`.
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37536,
"title": "[DevTools] (Fixes #37534)Fix Inspect button not working with top-laye…",
"state": "open",
"user": "seshan18",
"labels": [
"CLA Signed"
],
"comments": 3,
"created_at": "2026-09-07T10:44:27Z",
"updated_at": "2026-09-07T11:05:31Z",
"url": "https://github.com/react/react/pull/37536",
"is_pull_request": true,
"body": "## Summary
This PR fixes a bug where the DevTools Inspector (Highlighter) fails to select or visually highlight elements rendered in the native browser Top Layer (such as `<dialog>` elements opened via `showModal()`).
**The Problem:**
Because Top-Layer elements physically render above all other DOM nodes, regardless of `z-index`, the DevTools overlay was previously being hidden underneath them. This made the Inspect feature appear broken when trying to inspect content inside a `<dialog>`.
**The Solution:**
This commit updates the `Overlay` container in the DevTools backend to use the native Popover API (`popover="manual"`). By calling `showPopover()` when the overlay mounts, the DevTools highlighter is elevated into the Top Layer alongside the dialogs, making it visible again.
This approach perfectly matches the recent fix introduced for TraceUpdates highlighting (PR #32614). It includes CSS resets to prevent default browser centering from disrupting the DevTools layout and uses safe feature detection (`typeof showPopover === 'function'`) to ensure backwards compatibility with older browsers.
Fixes #37534
## How did you test this change?
- **Manual Testing in Chrome (which supports the Popover API):**
- Built the DevTools extension locally using `yarn build:extension:chrome`.
- Loaded the unpacked extension into a browser.
- Rendered a React application containing a `<dialog>` opened with `.showModal()`.
- Verified that using the DevTools "Inspect" button successfully highlights the components inside the dialog, displaying the blue highlighter box visually *above* the dialog interface.
- **Backward Compatibility:**
- Ensured that feature detection prevents the extension from crashing on older browser versions or environments that do not yet fully support the `showPopover()` API (the overlay safely falls back to standard DOM attachment).",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37535,
"title": "[rust-compiler] Preserve the invariant error shape through lowering",
"state": "open",
"user": "lazerg",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-07T09:36:38Z",
"updated_at": "2026-09-07T09:42:53Z",
"url": "https://github.com/react/react/pull/37535",
"is_pull_request": true,
"body": "## Summary
The Rust compiler logs `CompileError` events for lowering invariants in a different shape than the TS reference. For `error.bug-invariant-couldnt-find-binding-for-decl.js` the TS plugin puts the location directly on `detail.loc`, while Rust nests it under `detail.details[0].loc`.
`record_error` hands back the invariant as a `CompilerError` holding a flat `CompilerErrorDetail`, but `lower_statement`, `lower_block_statement_inner`, `lower_function` and `lower_function_to_value` all returned `Result<_, CompilerDiagnostic>`. The `?` operator therefore routed the error through `CompilerDiagnostic::from_detail`, which moves the location into a sub-detail, and it went back into a `CompilerError` in that shape. Returning `CompilerError` from those four functions drops the round trip and leaves the detail alone.
Fixes #37533
## How did you test this change?
Run from the repository root:
- `bash compiler/scripts/test-e2e.sh --variant babel`: events go from 1807/1810 to 1808/1810. The two that still fail (`fbt/error.todo-locally-require-fbt.js` and `todo-hoist-type-alias-before-declaration.js`) were already failing before this change.
- `cargo test --manifest-path compiler/Cargo.toml --workspace`, including a new lowering test that fails without the change.
- `bash compiler/scripts/test-babel-ast.sh`, `bash compiler/scripts/test-rust-port.sh` and `yarn --cwd compiler snap --rust`.
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37534,
"title": "[DevTools Bug]: Inspect button does not work with top-layer elements like <dialog>",
"state": "open",
"user": "alexandergottlieb",
"labels": [
"Type: Bug",
"Status: Unconfirmed",
"Component: Developer Tools"
],
"comments": 1,
"created_at": "2026-09-07T09:22:06Z",
"updated_at": "2026-09-07T09:56:01Z",
"url": "https://github.com/react/react/issues/37534",
"is_pull_request": false,
"body": "### Website or app
https://codesandbox.io/p/sandbox/ws7dp6
### Repro steps
The [_Inspect_ button](https://github.com/react/react/blob/f1f7ed2ac267a21dd2e3e67c4a606b9cf56e360b/packages/react-devtools-shared/src/devtools/views/Components/InspectHostNodesToggle.js) lets you lookup a component in the tree by clicking on it.
This is not working with top-layer elements, like [`<dialog>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/dialog) opened via [`showModal`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal).
1. Navigate to https://ws7dp6.csb.app/
2. Open React Dev Tools > Components
3. Click the _Inspect_ button (there are two icons of a cursor inside a rectangle at the top left, the browser's built-in one works, the one in React Dev Tools does not)
4. Click inside the dialog
5. Notice that nothing is selected.
https://github.com/user-attachments/assets/3ea438f3-3362-4e37-9c81-8f9ffd0540b7
### How often does this bug happen?
Every time
### DevTools package (automated)
_No response_
### DevTools version (automated)
_No response_
### Error message (automated)
_No response_
### Error call stack (automated)
```text
```
### Error component stack (automated)
```text
```
### GitHub query string (automated)
```text
```",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37533,
"title": "[rust-compiler] Invariant errors logged with a different event shape than the TS reference",
"state": "open",
"user": "ax1s-x1zz",
"labels": [
],
"comments": 0,
"created_at": "2026-09-07T04:17:25Z",
"updated_at": "2026-09-07T04:17:25Z",
"url": "https://github.com/react/react/issues/37533",
"is_pull_request": false,
"body": "# Issue Proposal: Rust compiler logs invariant errors with a different event shape than the TS reference
## Summary
The Rust port of the React Compiler emits `CompileError` logger events whose `detail`
shape differs from the TypeScript reference for errors thrown as `CompilerError.invariant()`
during lowering. Concretely, the Rust event carries the error inside a nested
`detail.details[0]` array, while the TS reference places the location directly on
`detail.loc`. This fails the e2e event comparison for the fixture
`error.bug-invariant-couldnt-find-binding-for-decl.js`.
This is the only remaining Rust-vs-TS event-shape failure in the Babel e2e suite
(`1807 / 1810` total; the other two failures are the already-documented, accepted
fixture differences in TODO.md Group A).
## Profiling evidence
Full Babel e2e run at HEAD `f1f7ed2ac`:
```
Code: 1809/1810 passed Events: 1807/1810 passed Total: 1807/1810 passed
FAIL compiler/.../fixtures/compiler/error.bug-invariant-couldnt-find-binding-for-decl.js
```
Fixture input:
```js
import {useEffect} from 'react';
export function Foo() {
useEffect(() => {
try {
// do something
} catch ({status}) {
// do something
}
}, []);
}
```
Raw `detail` payloads logged by each implementation for the same input:
| field | TS reference | Rust |
|---|---|---|
| `detail.category` | `"Invariant"` | `"Invariant"` |
| `detail.reason` | `"(BuildHIR::lowerAssignment) Could not find binding for declaration."` | same |
| `detail.severity` | `"Error"` | `"Error"` |
| `detail.loc` | `{start, end, identifierName: "status"}` | *(absent)* |
| `detail.details` | *(absent)* | `[{kind: "error", loc: {start, end}, message: "..."}]` |
The emitted code and `fnLoc` are identical; only the event `detail` shape diverges.
## Root cause
Both implementations already serialize each diagnostic faithfully — the Rust
`log_error`/`compiler_error_to_info` paths in
`compiler/crates/react_compiler/src/entrypoint/program.rs` mirror the TS
`formatDetailForLogging` (`src/Entrypoint/Program.ts:177`), which maps
`CompilerDiagnostic` → `detail.details[]` and `CompilerErrorDetail` → flat `detail.loc`.
The divergence originates earlier, in the error-type conversion:
`compiler/crates/react_compiler_lowering/src/build_hir.rs:3942`
records the catch-binding failure as an `CompilerErrorDetail` (category `Invariant`).
`builder.record_error(...)` returns `Err(CompilerError)` for invariant errors
(`compiler/crates/react_compiler_hir/src/environment.rs:331`). The enclosing function
returns `Result<T, CompilerDiagnostic>`, so the `?` operator triggers
`impl From<CompilerError> for CompilerDiagnostic`
(`compiler/crates/react_compiler_diagnostics/src/lib.rs:385`),
which wraps the `ErrorDetail` via `CompilerDiagnostic::from_detail(...)`. A
`CompilerDiagnostic` always serializes as the `detail.details[]` form, so the flat
location that TS preserves on the `CompilerErrorDetail` is moved into a sub-detail.
In TS, the equivalent `CompilerError.invariant()` produces a `CompilerErrorDetail`
(`src/HIR/BuildHIR.ts:948`), which survives to the logger as the flat `detail.loc`
form.
## Proposed minimal fix (for discussion)
Keep the invariant error's `ErrorDetail` representation through the `?` conversion so
the logged event stays flat, matching TS. The forward conversion currently always calls
`from_detail`; the reverse conversion already special-cases flat output for the `Todo`
category (see the comment at `compiler/crates/react_compiler_diagnostics/src/lib.rs:405`).
Extending the same principle to the invariant path in the forward conversion would align
the emitted event shape without touching serialization call sites or fixture outputs.
Scope is intentionally limited to:
- `compiler/crates/react_compiler_diagnostics/src/lib.rs` (the `From` conversion)
- a regression test (below)
No change to `log_error`, `compiler_error_to_info`, the Babel/NAPI bridge, or any
`.expect.md` fixture is expected. Codegen output and `fnLoc` are unaffected (only the
event `detail` shape changes), so no other fixture should change.
## Regression test plan
1. **Unit test** (fast, no JS toolchain): a test in
`compiler/crates/react_compiler_diagnostics` (or `react_compiler_lowering`) asserting
that converting a single-invariant `CompilerError` to `CompilerDiagnostic` and then
serializing through `log_error`'s `detail` path yields `detail.loc` populated and
`detail.details` absent. The test fails on current `main` and passes after the fix.
2. **E2E gate**: `bash compiler/scripts/test-e2e.sh --variant babel` must move
`error.bug-invariant-couldnt-find-binding-for-decl.js` from `FAIL` to `PASS` while
keeping the other `1809` fixtures passing.
3. **Workspace unit tests**: `cargo test --workspace` (currently `84 passed, 0 failed`)
must stay green.
## Compatibility
- **Backward compatible**: this only changes the serialized shape of a diagnostic that
currently diverges from the reference; the emitted program is unchanged.
- **No public API change**: the conversion is internal to the compiler crates.
## Verification environment
- HEAD: `f1f7ed2ac` (`[rust-compiler] Preserve ref access location across phi joins`)
- Rust toolchain `1.97.1`, edition 2024, `rust-version = 1.85`
- Babel e2e variant only; SWC/OXC frontends are not present on `main`.
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37532,
"title": "[Fizz][19.2.x] Fix duplicate Suspense completion instruction when an outlined boundary's fallback resolves late",
"state": "open",
"user": "sleitor",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-07T01:04:34Z",
"updated_at": "2026-09-07T01:04:39Z",
"url": "https://github.com/react/react/pull/37532",
"is_pull_request": true,
"body": "## Summary
Fixes #36985.
In react-dom 19.2.0-19.2.7, `renderToPipeableStream`/`renderToReadableStream` can emit the Suspense boundary completion instruction (`$RC(...)`) **twice** for the same boundary when:
1. the boundary's content is large enough to be eligible for outlining (`byteSize > 500`), and
2. the boundary's own `fallback` itself suspends (e.g. an async component as the fallback), and
3. the content finishes rendering **before** the fallback does.
By design, when a boundary is eligible for outlining, its still-pending fallback task is **not** aborted when the content completes (`finishedTask` skips `fallbackAbortableTasks.forEach(abortTaskSoft, ...)` in that case), because the fallback may still be needed if the boundary later gets outlined. The fallback keeps rendering into the boundary's placeholder `Segment` in the parent tree (the same `Segment` whose `.boundary` field points back at the `SuspenseBoundary`).
`flushSegment` reads `segment.boundary` to decide whether a `Segment` still represents a boundary that needs to be revealed, but it never cleared that reference after visiting it once. So when the fallback later finishes, `finishedSegment` re-queues that same placeholder `Segment`, and when it's flushed again via `flushPartiallyCompletedSegment` → `flushSegmentContentwise` → `flushSegment`, the code re-enters the boundary-reveal branch for a boundary that has already been queued/reported as complete — producing either a literal duplicate `$RC("B:n","S:n")`, or (if the boundary gets a new outlined id on the second pass) a fresh `<!--$?--><template id="B:m">` + a second `$RC("B:m","S:m")`, alongside a now-dangling `$RS` for the placeholder the first reveal already consumed. On the client this throws while patching DOM the first reveal already replaced, and the boundary recovers via client rendering with recoverable error #419.
## Fix
Restore the null-out of `segment.boundary` in `flushSegment` once a boundary segment has been visited, so a boundary's placeholder segment is only ever treated as "the boundary" on its first flush. A later reflush of the same `Segment` object (e.g. triggered by a late-resolving fallback) falls through to `flushSubtree` and is treated as ordinary content instead of re-triggering a boundary reveal — this is exactly today's behavior on `main`, which does not exhibit this bug. Also reverts the `Segment.boundary` field to being non-read-only (Flow `+boundary` → `boundary`) so the reset compiles under Flow, again matching `main`.
This is a minimal, targeted backport scoped to the `19.2.x` maintenance branch; it does not touch the `isEligibleForOutlining` semantics or any other Fizz behavior.
## Test plan
Added a regression test to `packages/react-dom/src/__tests__/ReactDOMFizzServer-test.js` that:
- renders nested `<Suspense>` boundaries where the inner boundary's fallback itself suspends on an async component,
- resolves the (outlining-eligible, >500 byte) content first,
- resolves the fallback afterwards,
- and asserts that exactly one `$RC(...)` completion instruction is emitted for the boundary (previously 3 were emitted — a legitimate duplicate for the outer boundary was expected, but the inner boundary was completed/reflushed under a stale id).
Verified:
- The new test fails on `releases/19.2.x` before this change (3 `$RC` calls) and passes after (2 `$RC` calls, one per boundary).
- `yarn test ReactDOMFizzServer-test.js` (169 tests), `ReactDOMFizzServerNode-test.js`, `ReactDOMFizzServerBrowser-test.js`, and `ReactDOMFizzServerEdge-test.js` all pass (208 tests total) with this change.
- Also reproduced the original standalone repro script from the issue against an actual built `react-dom/server` bundle from this branch: the duplicate `$RC` calls disappear after this change.
Reported by @polemitis in #36985, with initial investigation by @thisisankit01.
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37531,
"title": "fix: detect setState in useEffect for anonymous component callbacks passed to HOFs",
"state": "open",
"user": "sleitor",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-07T00:13:25Z",
"updated_at": "2026-09-07T00:17:49Z",
"url": "https://github.com/react/react/pull/37531",
"is_pull_request": true,
"body": "## Summary
The `react-hooks/set-state-in-effect` ESLint rule was not detecting `setState` calls inside `useEffect` when the component was an anonymous callback passed to a higher-order function (e.g. `const MyComponent = wrap(() => { ... })`).
## Root Cause
`getFunctionName()` in the compiler's `Program.ts` did not handle the HOF pattern where the parent is a `CallExpression` whose parent is a `VariableDeclarator`. This meant the anonymous function was never identified as a component and never compiled/validated by the lint rules.
## Changes
- **`compiler/.../Entrypoint/Program.ts`**: Add HOF pattern handling to `getFunctionName()` so `const MyComponent = wrap(() => {})` resolves the function name to `MyComponent`
- **`packages/eslint-plugin-react-hooks/src/shared/RunReactCompiler.ts`**: Add `CallExpression` to the `mayContainReactCode` heuristic so files with HOF-wrapped components are not skipped
- **`packages/eslint-plugin-react-hooks/__tests__/ReactCompilerRuleTypescript-test.ts`**: Add test cases for both `set-state-in-effect` and prop mutation detection in HOF-wrapped components
## Test Plan
Ran `packages/eslint-plugin-react-hooks/__tests__/ReactCompilerRuleTypescript-test.ts` — all 15 tests pass (11 existing + 4 new):
- HOF-wrapped component prop mutation detection (immutability rule)
- Direct component setState in effect detection (set-state-in-effect rule)
- HOF-wrapped component setState in effect detection (set-state-in-effect rule)
- Direct component without setState in effect (valid case)
Also ran `yarn workspace babel-plugin-react-compiler lint` — passes clean.
Fixes https://github.com/facebook/react/issues/35910
Note: This reopens the approach from #35943, which was auto-closed for staleness after being left unreviewed (never rejected on merits). Re-submitting the same fix with the same tests.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37528,
"title": "[compiler] Allow strict comparisons of ref-accessing callbacks",
"state": "open",
"user": "kolvian",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-06T08:05:52Z",
"updated_at": "2026-09-06T08:29:36Z",
"url": "https://github.com/react/react/pull/37528",
"is_pull_request": true,
"body": "<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.
Before submitting a pull request, please make sure the following is done:
1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect".
7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
<!--
Explain the **motivation** for making this change. What existing problem does the pull request solve?
-->
Fixes https://github.com/react/react/issues/37521. Previously, strict equality comparisons (ie. `===` or `!==`) with ref-accessing callback functions as operands would be flagged by ESLint as accessing ref values at render time. Since strict equality comparisons don't call the operand functions, it is safe to perform these comparisons at render time, so I add narrow support to `===` and `!==`, while still rejecting operands read from `ref.current`. In the future, this could be expanded to include `typeof` and other checks as well. I also added 8 tests for thoroughness:
4 compiler fixtures, each with a generated `.expect.md` snapshot:
- Safe strict comparisons of callbacks, including aliases and conditional selection.
- Comparisons involving actual ref values still warn.
- Calling ref-accessing callbacks inside comparisons still warns.
- Loose comparisons retain existing warnings.
4 ESLint 8 integration cases:
- The issue’s TypeScript reproduction produces no warning.
- Comparing a ref value warns.
- Comparing a function read from a ref warns.
- Calling a ref-accessing callback in a comparison warns.
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface.
How exactly did you verify that your PR solves the issue you wanted to solve?
If you leave this empty, your PR will very likely be closed.
-->
All tests pass, `yarn` passes, `yarn flow dom-node` passes. I also added a specific regression test for this change, which runs something similar to this:
```ts
import {useRef} from 'react';
function Component({previous}) {
const ref = useRef(0);
const callback = () => ++ref.current;
return callback !== previous;
}
```
Previously, this would be flagged by ESLint. You can run this yourself by running:
```bash
cd compiler
yarn snap -p '*ref*comparison*'
# ESLint integration tests
cd ../packages/eslint-plugin-react-hooks
yarn test ReactCompilerRuleTypescript --runInBand
```
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37527,
"title": "[DOM] fix: apply `autofocus` attribute",
"state": "open",
"user": "WofWca",
"labels": [
"CLA Signed"
],
"comments": 3,
"created_at": "2026-09-05T12:46:49Z",
"updated_at": "2026-09-05T18:02:20Z",
"url": "https://github.com/react/react/pull/37527",
"is_pull_request": true,
"body": "<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.
Before submitting a pull request, please make sure the following is done:
1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect".
7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
<!--
Explain the **motivation** for making this change. What existing problem does the pull request solve?
-->
Fixes https://github.com/react/react/issues/23301.
Supersedes https://github.com/react/react/pull/37328 - that one only fixes the issue for dialogs but not for popovers. And overall such an inconsistency in DOM generation is not nice IMO.
Previously, setting `autoFocus={true}` on the client
would only trigger the React's `element.focus()` polyfill,
but it would not apply the actual `autofocus` attribute.
Let's change that.
With `autofocus` getting more widely adopted by browsers
and getting more complex
(e.g. its interactions with the `<dialog>` element),
it's about time to start migrating away from the polyfill.
This was discussed a bit in
https://github.com/react/react/pull/11192 (2017).
As the comment in `ReactFiberConfigDOM.js`,
this commit does not remove the polyfill.
I decided to keep that for a follow-up
in order to not get stuck in discussions.
But yes, ultimately I think it's about time to get rid of the polyfill.
## How did you test this change?
I added a test which fails without the fix and passes with it.
I did not test the code live otherwise.
Note that I haven't managed to run the whole test suite (`yarn test`). They keep timing out for me.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37526,
"title": "Attach ref before commitHostMount so autoFocus sees it",
"state": "open",
"user": "NAVEENKUMARKR777",
"labels": [
"CLA Signed"
],
"comments": 3,
"created_at": "2026-09-05T04:08:25Z",
"updated_at": "2026-09-08T15:55:11Z",
"url": "https://github.com/react/react/pull/37526",
"is_pull_request": true,
"body": "## Summary
Fixes #7769, open since 2016 and labeled `Difficulty: challenging`.
For a `HostComponent`, `commitLayoutEffectOnFiber` called `commitHostMount` — which triggers `autoFocus` via a synchronous DOM `.focus()` call — *before* attaching the fiber's own ref:
```js
if (current === null) {
if (flags & Update) {
commitHostMount(finishedWork); // may call domElement.focus()
} else if (flags & Hydrate) {
commitHostHydratedInstance(finishedWork);
}
}
if (flags & Ref) {
safelyAttachRef(finishedWork, finishedWork.return); // too late
}
```
Because `focus` fires synchronously, an `onFocus` handler on the *same* element sees `ref.current === null`:
```jsx
<input
autoFocus
ref={inputRef}
onFocus={() => {
// inputRef.current is null here today
}}
/>
```
For years the only documented workaround has been to use `event.target`/`event.currentTarget` instead of the ref. Earlier attempts at a fix (see the issue thread) stalled because reordering the whole effect list looked risky and likely to affect `componentDidMount`/`useLayoutEffect` ordering relative to refs.
This PR takes a narrower path: it only swaps the two statements above (ref attach now runs before `commitHostMount`/`commitHostHydratedInstance`) for the fiber's *own* ref. It doesn't touch `ClassComponent`/`FunctionComponent` handling, so `componentDidMount`/`useLayoutEffect` still run relative to refs exactly as before — this only affects the DOM host mount effects (`autoFocus`, and the `<img>` src-reassignment trick, which is async and unaffected either way).
The identical pattern also existed in `reappearLayoutEffects` (the Offscreen/Activity "reappear" path for `HostComponent` and `HostHoistable`), so it's fixed there too for consistency, per the existing comment tying the two functions together.
## Test plan
- Added `packages/react-dom/src/__tests__/ReactDOMAutoFocusRefOrdering-test.js` with two regression tests (function ref via `useRef`, and callback ref) that fail without this change and pass with it.
- `yarn test` (source/experimental), `yarn test-www`, `yarn test-www --variant=false`, and `yarn test-stable` all pass for the new test file.
- Full `packages/react-reconciler` and `packages/react-dom` suites pass (a few unrelated tests intermittently time out under sandboxed parallel execution — confirmed pre-existing by reproducing on `main` and passing in isolation on this branch).
- `yarn flow dom-node`: no errors.
- `yarn prettier` / `yarn linc`: clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37525,
"title": "[Compiler] Detect nested state mutation through object spread",
"state": "open",
"user": "wapgear",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-04T20:26:56Z",
"updated_at": "2026-09-07T13:36:47Z",
"url": "https://github.com/react/react/pull/37525",
"is_pull_request": true,
"body": "## Summary
Object spread creates a new object but preserves references to nested values. Track that relationship for a single spread of a captured context value so `const copy = {...state}; copy[key].value = next` reports a state mutation.
Keep valid immutable updates compiling, including property overrides and replacing a copied property before mutating it. Reuse the existing mutation state to account for replacements through assignments and calls such as `Object.assign`. TypeScript and Rust use the same rules.
The analysis stays conservative after possible replacements or when the object literal has additional properties. Tracking copies returned by helpers is outside this change.
Fixes #37316.
## How did you test this change?
- Six shallow-copy fixtures cover the original repro, mutation before replacement, property overrides, and replacements through assignment, `Object.assign`, and a local call.
- `yarn snap --sync`: 1816/1816 passed.
- `yarn snap --rust --sync`: 1816/1816 passed.
- Compiler TypeScript checking, ESLint and Prettier for the changed TypeScript file, `cargo fmt --all -- --check`, and the Rust native build passed.
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37523,
"title": "[Compiler] Fix JSX ref object property aliasing",
"state": "open",
"user": "itamark",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-04T18:43:39Z",
"updated_at": "2026-09-08T16:25:19Z",
"url": "https://github.com/react/react/pull/37523",
"is_pull_request": true,
"body": "## Summary
Fixes #37507.
Passing `obj.prop` to a JSX `ref` attribute caused unrelated reads from the same object to report `Cannot access refs during render`.
`collectTemporariesSidemap` aliases a property-load temporary back to its base object. JSX ref inference correctly marks the loaded property as a ref, but `Env.set` followed that alias and marked the base object as a ref too. Later `obj.*` reads were therefore treated as ref-value accesses.
This change skips that alias when the property-load result is already inferred as a ref. The ref type stays on the loaded value, while the base object remains ordinary. Local aliases still resolve to the ref temporary, and genuine `.current` access validation is unchanged.
The regression fixture covers direct and locally aliased property refs.
## How did you test this change?
- `env -u NO_COLOR yarn snap --sync` — 1811 tests passed, 0 failed
- `yarn eslint packages/babel-plugin-react-compiler/src/Validation/ValidateNoRefAccessInRender.ts` — passed
- `git diff --check` — passed
- The fixture eval renders the unrelated `ctx.files` value and passes a callback through `ctx.foo`; `logs: ['DIV']` verifies React still attaches the rendered DOM node to the original ref.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37522,
"title": "Fix crash on null-prototype style objects in ReactDOM",
"state": "open",
"user": "harshil585581",
"labels": [
"CLA Signed"
],
"comments": 3,
"created_at": "2026-09-04T14:27:10Z",
"updated_at": "2026-09-04T15:03:57Z",
"url": "https://github.com/react/react/pull/37522",
"is_pull_request": true,
"body": "Use shared/hasOwnProperty helper when checking own properties on style objects and options to support objects created via Object.create(null).
Fixes #37423
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.
Before submitting a pull request, please make sure the following is done:
1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect".
7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
<!--
Explain the **motivation** for making this change. What existing problem does the pull request solve?
-->
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface.
How exactly did you verify that your PR solves the issue you wanted to solve?
If you leave this empty, your PR will very likely be closed.
-->
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37521,
"title": "Bug: ESLint flags just refering (not calling) functions that use refs as accessing refs (react-hooks/refs)",
"state": "open",
"user": "mikecat",
"labels": [
"Status: Unconfirmed"
],
"comments": 0,
"created_at": "2026-09-04T13:19:16Z",
"updated_at": "2026-09-04T13:19:16Z",
"url": "https://github.com/react/react/issues/37521",
"is_pull_request": false,
"body": "<!--
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: 19.2.8
ESLint version: 9.39.5
Node.js version; 24.20.0
## Steps To Reproduce
1. Run `npm run lint` command at the root of the repository.
<!--
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: [mikecat/next-read-function-using-ref-in-render: Next.js example where just refering (not calling) function that uses refs is marked as accessing refs during render](https://github.com/mikecat/next-read-function-using-ref-in-render)
`page.tsx`:
```typescript
import { useCallback, useState, useRef } from 'react';
export default function Home() {
const [sampleValue, setSampleValue] = useState(0);
const sampleRef = useRef(0);
const sampleFunc = useCallback(() => {
setSampleValue(++sampleRef.current);
}, []);
const [prevSampleFunc, setPrevSampleFunc] = useState<(() => void) | null>(null);
if (sampleFunc !== prevSampleFunc) {
setPrevSampleFunc(() => sampleFunc);
}
return null;
}
```
<!--
Please provide a CodeSandbox (https://codesandbox.io/s/new), 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: https://stackoverflow.com/help/mcve.
-->
## The current behavior
You will see this error message:
```text
12:7 error Error: Cannot access refs during render
React refs are values that are not needed for rendering. Refs should only be accessed outside of render, such as in event handlers or effects. Accessing a ref value (the `current` property) during render can cause your component not to update as expected (https://react.dev/reference/react/useRef).
C:\MyApps\temp\next-read-function-using-ref-in-render\app\page.tsx:12:7
10 |
11 | const [prevSampleFunc, setPrevSampleFunc] = useState<(() => void) | null>(null);
> 12 | if (sampleFunc !== prevSampleFunc) {
| ^^^^^^^^^^ Cannot access ref value during render
13 | setPrevSampleFunc(() => sampleFunc);
14 | }
15 | react-hooks/refs
```
## The expected behavior
In this code, the function `sampleFunc` is just referred and not called during render.
Therefore, I don't think that this code is accessing refs during render as the error message suggests.
I expect this message, which looks like a false positive, isn't emitted for this code.
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37520,
"title": "Warn when textarea switches from uncontrolled to controlled",
"state": "open",
"user": "wapgear",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-04T12:21:51Z",
"updated_at": "2026-09-04T12:22:16Z",
"url": "https://github.com/react/react/pull/37520",
"is_pull_request": true,
"body": "## Summary
Adds a development warning when a textarea changes from uncontrolled to controlled, matching the existing input behavior. This catches cases where `value` starts as `undefined` and becomes defined later.
Fixes #16342.
## How did you test this change?
Using Node v20.19.0 from `.nvmrc`:
`yarn test ReactDOMTextarea ReactDOMInput ReactDOMComponent --runInBand` passed 4 suites and 347 tests.
`yarn test --prod --runInBand` passed 325 suites, 6,919 tests, and 195 snapshots.
`yarn prettier`, `yarn lint`, and `yarn flow dom-browser` passed.
`yarn test --runInBand` passed 324 of 325 suites and 6,946 tests. `ReactMultiChildText-test.js` hit its existing 30-second timeout under full-suite load. Rerunning `yarn test ReactMultiChildText --runInBand` passed all 4 tests in 4.1 seconds.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37519,
"title": "[DevTools] Fix inspect highlight overlay misalignment with CSS zoom",
"state": "open",
"user": "sleitor",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-04T10:37:00Z",
"updated_at": "2026-09-04T10:42:47Z",
"url": "https://github.com/react/react/pull/37519",
"is_pull_request": true,
"body": "## Summary
Fixes #36904.
When a page uses the non-standard CSS `zoom` property (e.g. `html { zoom: 0.9 }`), the DevTools "inspect element" highlight overlay and the "highlight updates when components render" trace-updates canvas are visibly offset from the actual element, with the offset growing the further the element is from the viewport origin.
## Root cause
Both `Highlighter/Overlay.js` and `TraceUpdates/canvas.js` inject `position: fixed` nodes into the inspected page's DOM and position them using coordinates from `getBoundingClientRect()`/`getComputedStyle()`.
Those coordinates are already relative to the zoomed viewport, but in Chromium, CSS `zoom` on an ancestor (unlike `transform: scale`) also rescales `position: fixed` descendants. So when `body { zoom: 0.9 }`:
- `getBoundingClientRect()` returns e.g. `top: 450px` (already zoom-adjusted, viewport-relative)
- Our overlay element sets `position: fixed; top: 450px` *inside* the zoomed page
- Chromium renders it at `450 * 0.9 = 405px`, i.e. 45px off
The browser's native element inspector isn't affected because it renders outside the page's CSS coordinate system entirely.
## Fix
- Added `getCumulativeZoom(node)` to `views/utils.js`, which walks the element's ancestor chain and multiplies together each ancestor's computed `zoom` value (defaulting to `1` when zoom is not used).
- `Highlighter/Overlay.js`: compute the cumulative zoom once per `inspect()` call (from the first inspected element's ancestor chain) and divide all coordinates/sizes assigned to the `position: fixed` overlay elements (rect, borders, tooltip position) by it, compensating for Chromium's double-scaling.
- `TraceUpdates/canvas.js`: adjust the trace-updates canvas's CSS width/height (but not its backing-store resolution, which stays keyed off `devicePixelRatio`) by the same cumulative zoom factor, since the canvas element is also `position: fixed` and gets rescaled the same way; the rects drawn onto it are left untouched since they already come from zoom-adjusted `getBoundingClientRect()` values that match the (pre-rescale) canvas coordinate space.
This is a targeted fix for zoom scoped to these two files, per the discussion in #36904. It does not attempt the broader highlighting-system unification tracked in #36787; if that unification lands, this zoom handling should move there.
## How I tested
- `yarn prettier` / `yarn lint` — clean.
- `yarn flow dom-browser` — no new errors (pre-existing unrelated `react-devtools-facade` module-resolution errors are present on `main` as well, verified via `git stash`).
- Manually reasoned through the coordinate math for both nested `iframe` and non-`iframe` cases; `getCumulativeZoom` defaults to `1` (no-op) when `zoom` isn't set anywhere in the ancestor chain, so pages without CSS `zoom` are unaffected.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37518,
"title": "[Compiler] Fix refs false positive for obj.prop passed to JSX ref attribute",
"state": "open",
"user": "rh0kzy",
"labels": [
"CLA Signed"
],
"comments": 2,
"created_at": "2026-09-04T01:07:49Z",
"updated_at": "2026-09-04T01:13:37Z",
"url": "https://github.com/react/react/pull/37518",
"is_pull_request": true,
"body": "Fixes #37507.
## Summary
Passing `obj.prop` to a JSX `ref` attribute made every other `obj.*` read report `Cannot access refs during render`, in both `babel-plugin-react-compiler` (`validateRefAccessDuringRender`) and the `react-hooks/refs` lint rule.
Root cause: in `ValidateNoRefAccessInRender.ts`, `collectTemporariesSidemap` aliases every `PropertyLoad` temporary (`t = obj.prop`) to its base object, and `Env.set` writes through that alias. Type inference unifies the place passed to a JSX `ref` attribute with the `useRef` object type (`InferTypes.ts`, `JsxExpression` case), so the inferred `Ref` type for `ctx.foo` landed on `ctx` itself instead of the temporary. From then on every `ctx.*` load derived `RefValue`.
Fix: in the `PropertyLoad` case of `collectTemporariesSidemap`, don't alias the temporary when the loaded value is itself known to be a ref object (`isUseRefType(lvalue.identifier)`), mirroring the existing skip for `useRef.current` loads.
## How did you test this change?
- Issue repro (`ref={ctx.foo}` + `ctx.files.length` reads): 3 errors before, 0 after, with correct memoized output. A/B verified by stashing the fix (errors return) and restoring it (errors gone).
- Local-alias (`const r = ctx.inputRef; ref={r}`) and chained (`ref={ctx.a.inputRef}`) variants from the issue: also fixed.
- Genuine violations still error: `ref.current` in render, `props.ref.current`.
- Added regression fixture `allow-jsx-ref-attribute-from-object-prop` (+ snapshot).
- Full compiler fixture suite: 1811/1811 pass. `eslint` and `tsc --noEmit` clean on the changed file.
Known limitation (out of scope): `const ctx = {inputRef, files}` + reading `ctx.files` still errors. That flows through the `ObjectExpression` → `Structure` join, a documented over-approximation ("we don't track types of fields", see fixture `error.invalid-use-ref-added-to-dep-without-type-info` which mandates it). Fixing it would require per-key tracking.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37516,
"title": "[DevTools] Skip tree base duration updates for missing commit-tree fibers",
"state": "open",
"user": "javascript-unsafe",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-03T15:10:07Z",
"updated_at": "2026-09-03T15:10:41Z",
"url": "https://github.com/react/react/pull/37516",
"is_pull_request": true,
"body": "Fixes #35640
## Summary
`CommitTreeBuilder.updateTree` threw `Could not clone the node` when a commit carried `TREE_OPERATION_UPDATE_TREE_BASE_DURATION` for a fiber that was already gone from the snapshot. Rebuilding later commits (including imported profiles) aborted at that point.
`#35718` stopped *recording* durations for disconnected subtrees. Profiles exported before that still contain the stale ops. This change skips a missing-id duration update (leave `treeBaseDuration` as-is) and keeps walking the payload. ADD / REMOVE / REORDER are unchanged.
Replayed the `#35640` attachment (136 commits): first abort was commit 50, fiber 731, duration site; after this skip all 136 commits apply.
## Test plan
- [x] `profilingCommitTreeBuilder-test.js`: append duration for missing fiber `731`; `getCommitTree` does not throw and the id is not inserted
- [x] `yarn test` DevTools `profilingCommitTreeBuilder` (not run in this sparse checkout)",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37514,
"title": "[compiler] Recognize optional chains inside try/catch blocks",
"state": "open",
"user": "sleitor",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-03T11:24:06Z",
"updated_at": "2026-09-03T11:24:12Z",
"url": "https://github.com/react/react/pull/37514",
"is_pull_request": true,
"body": "## Summary
Fixes #36902.
React Compiler's dependency inference could infer a *less specific* dependency than the one manually specified whenever an optional-chain read (e.g. `user?.access_token`) occurred inside a `try` block, causing "Existing memoization could not be preserved" compilation errors even though nothing was actually wrong with the source.
## Root cause
Every instruction inside a `try {}` block is lowered to HIR with its own `maybe-throw` terminal — an edge to the enclosing `catch` handler that doesn't change the value produced, but does mean instructions that would otherwise share one basic block each get their own block instead.
`CollectOptionalChainDependencies.ts` recognizes the lowered form of an optional chain (`a?.b`) via structural pattern-matching over specific block shapes (e.g. "the consequent block contains exactly a `PropertyLoad` followed by a `StoreLocal`, terminated by a `goto`"). That matching logic assumed instructions stay grouped into larger blocks and didn't account for the `maybe-throw` splitting that happens inside `try` blocks. So when an optional chain like `user?.access_token` appeared inside a `try` block, the pattern match silently failed, and the read was no longer tracked as an optional-chain dependency at all.
Without that tracking, standard dependency-inference fallback logic in `DeriveMinimalDependenciesHIR.ts` widened the dependency to the whole base object (`user`) instead of the specific property (`user?.access_token`), since it couldn't otherwise prove it was safe to read `.access_token` unconditionally. That's coarser than the manually-specified `[user?.access_token]` dependency, so `ValidatePreservedManualMemoization` correctly (but unnecessarily) flagged it as "Inferred less specific property than source" and skipped optimizing the component.
Confirmed with the reduced repro from the issue:
```jsx
const myCallback = useCallback(() => {
try {
console.log(user?.access_token);
} catch (error) {
console.error(error);
}
}, [user?.access_token]);
```
Removing the `try`/`catch` (as noted in the issue) avoids the `maybe-throw` splitting entirely, which is why that "fixed" it — the bug isn't about `try`/`catch` per se, it's that the optional-chain pattern matcher couldn't see through it.
## Fix
Add a small `flattenMaybeThrows` helper in `CollectOptionalChainDependencies.ts` that walks through a chain of `maybe-throw` terminals (as would happen for every instruction inside a `try` block) and returns the concatenated instructions plus the first non-`maybe-throw` terminal reached. Use it wherever the optional-chain matcher inspects a block's instructions/terminal (the test block, and the consequent/alternate blocks), so the existing pattern-matching logic works unchanged whether or not the code is wrapped in a `try` block.
## Testing
- Added `preserve-memo-deps-optional-chain-in-try-catch.js`, a regression test based on the issue's reduced repro. Before this fix it failed to compile with `Existing memoization could not be preserved`; after the fix it compiles with `$[0] !== user?.access_token`, matching the source dependency exactly.
- `yarn workspace babel-plugin-react-compiler lint` — passes.
- `yarn workspace babel-plugin-react-compiler jest` — all 43 tests pass.
- `yarn workspace snap run snap` (full compiler fixture suite) — all 1811 tests pass, no regressions.
## Scope note
This fixes the specific, confirmed mechanism described in the issue and reduced by @MonstraG (an optional-chain read losing precision because it's inside a `try` block). The original issue's fuller repro also re-reads the same property a second time, non-optionally, in a separate statement inside the guarded `if`/`try` body (`user.access_token`, after already checking `user?.access_token`) — that pattern hits a related but distinct and pre-existing imprecision in how dependencies are merged when a property can't be proven safe to read unconditionally, independent of `try`/`catch`. That's a separate, larger change and is not addressed by this PR.",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37513,
"title": "[compiler] Support update expressions on captured variables",
"state": "open",
"user": "javache",
"labels": [
"CLA Signed"
],
"comments": 0,
"created_at": "2026-09-03T10:38:44Z",
"updated_at": "2026-09-04T08:22:41Z",
"url": "https://github.com/react/react/pull/37513",
"is_pull_request": true,
"body": "## Summary
- support prefix and postfix update expressions on captured variables in both TypeScript and Rust compiler backends
- represent updates with explicit `PrefixUpdateLocal`, `PrefixUpdateContext`, `PostfixUpdateLocal`, and `PostfixUpdateContext` HIR variants
- model captured updates as mutations so SSA, effect inference, dead-code elimination, and post-render validation preserve their semantics
- convert the existing TODO fixtures to passing coverage and add the Airwave-shaped map regression from T286959188
- correct Rust workspace manifest paths in the rust-port documentation
## How did you test this change?
- `yarn prettier`
- `yarn linc`
- `yarn flow dom-node`
- `yarn test --silent --no-watchman React-hooks-arity`
- `yarn test-www --silent --no-watchman useMemoCache`
- `yarn test-www --variant=false --silent --no-watchman useMemoCache`
- `node_modules/.bin/tsc --noEmit -p compiler/packages/babel-plugin-react-compiler/tsconfig.json`
- `cargo +1.93.1 fmt --manifest-path compiler/Cargo.toml --all -- --check`
- `cargo +1.93.1 check --manifest-path compiler/Cargo.toml -p react_compiler -j 1`
- targeted Cargo tests for lowering, SSA, inference, optimization, and validation
- TypeScript and Rust snapshot runs for `*update-expression*` (11 tests each)",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37512,
"title": "Bug:",
"state": "open",
"user": "hamidousaas",
"labels": [
"Status: Unconfirmed"
],
"comments": 0,
"created_at": "2026-09-02T23:41:43Z",
"updated_at": "2026-09-02T23:41:43Z",
"url": "https://github.com/react/react/issues/37512",
"is_pull_request": false,
"body": "<!--
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:
## Steps To Reproduce
1.
2.
<!--
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 (https://codesandbox.io/s/new), 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: https://stackoverflow.com/help/mcve.
-->
## The current behavior
## The expected behavior
",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37511,
"title": "oxc port: [correctness] initialize named function expression bindings",
"state": "open",
"user": "wbinnssmith",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-02T23:20:34Z",
"updated_at": "2026-09-03T19:15:56Z",
"url": "https://github.com/react/react/pull/37511",
"is_pull_request": true,
"body": "Initialize referenced named function-expression bindings as private function-entry bindings. This prevents recursive references from reaching mutation inference uninitialized and keeps renaming consistent through HIR, SSA, alias analysis, reactive lowering, and codegen.
Unreferenced private names remain unchanged, preserving observable `Function.name` values.
Ported from:
- oxc-project/oxc@e3c6c4e7392d004a93f0a913dd5a9dd9adfb9174 by @Boshen
- oxc-project/oxc@33d4ed9dec2cdda9da640e1978fc12138ed25677 by @Boshen
## Benchmark
Compared exact `main` base `0bbf02475c7b61a618551f1cf10c9bebf336f285` against PR commit `03d2abbaea` using the Criterion harness from `wbinnssmith/rust-compiler-criterion-benchmark` (`ed9ff959b7`, `3a63fa30b9`). Both binaries compiled the same fixed PR-head corpus: 1,811 fixtures, 755,856 source bytes.
The harness fixes this benchmark at 50 samples, 3 s warm-up, and 30 s measurement; peak RSS used 20 fresh processes.
- `main`: 616.69-665.16 ms, peak RSS mean 193.8 MiB, 95% sample range 192.1-195.4 MiB
- PR: 585.97-597.83 ms, peak RSS mean 190.3 MiB, 95% sample range 185.7-193.3 MiB
- Relative change: -11.152% to -4.0123% (95% CI)
- p-value: <0.01, significance threshold 0.05
Criterion reports a statistically significant improvement. This likely reflects host noise rather than an expected speedup from the small conditional path; the confidence interval and raw ranges are included for transparency.
## Test plan
- `yarn snap -p named-function-expression-private-binding`
- `yarn snap --rust -p named-function-expression-private-binding`
- `yarn snap -p duplicate-named-function-expression-names`
- `yarn snap --rust -p duplicate-named-function-expression-names`
- `yarn snap -p error.bug-infer-mutation-aliasing-effects`
- `yarn snap --rust -p error.bug-infer-mutation-aliasing-effects`
- `yarn snap --rust` (1,812 passed)
- `cargo check --manifest-path compiler/crates/react_compiler/Cargo.toml`
- `cargo fmt --check --manifest-path compiler/crates/react_compiler/Cargo.toml`
- `yarn prettier`
- `yarn linc`
- `git diff --check`",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37510,
"title": "Bump fast-uri from 3.1.2 to 3.1.7 in /packages/react-devtools-cdt-mcp/fixtures/app",
"state": "open",
"user": "dependabot[bot]",
"labels": [
"CLA Signed",
"dependencies",
"javascript"
],
"comments": 1,
"created_at": "2026-09-02T23:10:49Z",
"updated_at": "2026-09-02T23:15:25Z",
"url": "https://github.com/react/react/pull/37510",
"is_pull_request": true,
"body": "Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.2 to 3.1.7.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/fastify/fast-uri/releases">fast-uri's releases</a>.</em></p>
<blockquote>
<h2>v3.1.7</h2>
<h2>⚠️ Security Warning</h2>
<p>This is a security release that fixes the following high-severity security advisories:</p>
<ul>
<li><a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-qw65-cvwx-89v3">GHSA-qw65-cvwx-89v3</a> — authority injection via an unvalidated port in <code>serialize()</code></li>
<li><a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-58mr-gqgx-xq4g">GHSA-58mr-gqgx-xq4g</a> — host confusion via unbalanced or misplaced IP-literal brackets</li>
</ul>
<p>Users of the v3.x release line should upgrade to v3.1.7.</p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.6...v3.1.7">https://github.com/fastify/fast-uri/compare/v3.1.6...v3.1.7</a></p>
<h2>v3.1.6</h2>
<h2>⚠️ Security Warning</h2>
<p>This release addresses the following high-severity security advisories:</p>
<ul>
<li><a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-5jgf-p345-68v8">GHSA-5jgf-p345-68v8</a> — host confusion via skipped IDN canonicalization on scheme-relative references</li>
<li><a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-fph4-wmhf-6fwf">GHSA-fph4-wmhf-6fwf</a> — server-side request forgery via repeated hostname percent-decoding</li>
<li><a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-f65p-4m7j-42xc">GHSA-f65p-4m7j-42xc</a> — server-side request forgery via malformed IPv6 normalization</li>
<li><a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-jqff-g426-hqxp">GHSA-jqff-g426-hqxp</a> — host confusion via percent-encoded scheme normalization</li>
</ul>
<p>Users of the v3.x release line should upgrade to v3.1.6.</p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.5...v3.1.6">https://github.com/fastify/fast-uri/compare/v3.1.5...v3.1.6</a></p>
<h2>v3.1.5</h2>
<h2>⚠️ Security Warning</h2>
<p>Fix for <a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-7p8r-x3mc-p8w7">https://github.com/fastify/fast-uri/security/advisories/GHSA-7p8r-x3mc-p8w7</a></p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.4...v3.1.5">https://github.com/fastify/fast-uri/compare/v3.1.4...v3.1.5</a></p>
<h2>v3.1.4</h2>
<h2>⚠️ Security Release</h2>
<p>Fix for <a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-v2hh-gcrm-f6hx">https://github.com/fastify/fast-uri/security/advisories/GHSA-v2hh-gcrm-f6hx</a></p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.3...v3.1.4">https://github.com/fastify/fast-uri/compare/v3.1.3...v3.1.4</a></p>
<h2>v3.1.3</h2>
<h2>⚠️ Security Release</h2>
<ul>
<li>Fixes: <a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-4c8g-83qw-93j6">https://github.com/fastify/fast-uri/security/advisories/GHSA-4c8g-83qw-93j6</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.2...v3.1.3">https://github.com/fastify/fast-uri/compare/v3.1.2...v3.1.3</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/fastify/fast-uri/commit/412e40abd4eb8beabfb952d80abf949a2baf27a3"><code>412e40a</code></a> Bumped v3.1.7</li>
<li><a href="https://github.com/fastify/fast-uri/commit/9f4c943e4d2133e8d78e0941203879216255bb01"><code>9f4c943</code></a> fix: backport port and IP-literal validation to v3.x (<a href="https://redirect.github.com/fastify/fast-uri/issues/216">#216</a>)</li>
<li><a href="https://github.com/fastify/fast-uri/commit/1eb3ce436fe050807caba79f886ab894f485a588"><code>1eb3ce4</code></a> fix: treat unterminated bracket hosts as reg-names again (<a href="https://redirect.github.com/fastify/fast-uri/issues/214">#214</a>)</li>
<li><a href="https://github.com/fastify/fast-uri/commit/6f970b2951fd896aa0f3a7ff28eeb6640c137d33"><code>6f970b2</code></a> Bumped v3.1.6</li>
<li><a href="https://github.com/fastify/fast-uri/commit/d941579a84273ec7e96bde596b1f7a8be447df2a"><code>d941579</code></a> fix: never run IDN canonicalization on bracketed IP literals</li>
<li><a href="https://github.com/fastify/fast-uri/commit/c0f0279cf370cb89ee56b04bbcde2a7afbe81aba"><code>c0f0279</code></a> test: adapt decoded-scheme handler assertion to 3.x (no mailto scheme)</li>
<li><a href="https://github.com/fastify/fast-uri/commit/37f3417c82994279656854f83ce938acd81c3862"><code>37f3417</code></a> Merge commit from fork</li>
<li><a href="https://github.com/fastify/fast-uri/commit/607bfbe953f28a14c2e06ae64aff38c81ca2937f"><code>607bfbe</code></a> Merge commit from fork</li>
<li><a href="https://github.com/fastify/fast-uri/commit/ae92a4c5d8c4b6c9e447f048d5fcbde7eebd5514"><code>ae92a4c</code></a> Merge commit from fork</li>
<li><a href="https://github.com/fastify/fast-uri/commit/444ecdad447db2cc23c4d422acc6f0daa6fa8eef"><code>444ecda</code></a> Merge commit from fork</li>
<li>Additional commits viewable in <a href="https://github.com/fastify/fast-uri/compare/v3.1.2...v3.1.7">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/react/react/network/alerts).
</details>",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
},
{
"number": 37509,
"title": "oxc port: [correctness] support destructured context parameters",
"state": "open",
"user": "wbinnssmith",
"labels": [
"CLA Signed"
],
"comments": 1,
"created_at": "2026-09-02T22:11:13Z",
"updated_at": "2026-09-03T19:16:04Z",
"url": "https://github.com/react/react/pull/37509",
"is_pull_request": true,
"body": "Support object, array, and rest parameters whose bindings are captured by nested functions. Destructured parameters now lower through temporaries before storing context bindings, avoiding invalid destructure/context HIR.
Ported from oxc-project/oxc@4e591ed4ed82be2835c81b08dbf097efd905b60e by @Boshen.
## Benchmark
Compared exact `main` base `0bbf02475c7b61a618551f1cf10c9bebf336f285` against PR commit `a5c027c288` using the Criterion harness from `wbinnssmith/rust-compiler-criterion-benchmark` (`ed9ff959b7`, `3a63fa30b9`). Both binaries compiled the same fixed PR-head corpus: 1,812 fixtures, 755,951 source bytes.
Parameters: 20 samples, 2 s warm-up, 10 s measurement, 20 peak-RSS samples.
- `main`: 6.2096-6.2205 ms, peak RSS 7.34 MiB
- PR: 6.1979-6.2254 ms, peak RSS 7.36 MiB
- Relative change: -0.2834% to +0.1955% (95% CI)
- p-value: 0.76, significance threshold 0.05
No statistically significant performance change detected.
## Test plan
- `yarn snap -p destructure-array-param-to-context-var`
- `yarn snap -p destructure-object-param-to-context-var`
- `yarn snap -p destructure-rest-param-to-context-var`
- Rust variants of all three focused fixtures
- `yarn snap --rust` (1,813 passed)
- `cargo check --manifest-path compiler/crates/react_compiler_lowering/Cargo.toml`
- `cargo fmt --check --manifest-path compiler/crates/react_compiler_lowering/Cargo.toml`
- `yarn prettier`
- `yarn linc`
- `git diff --check`",
"scraped_at": "2026-09-08T17:13:06.204193+00:00"
}
]
}
GET
/v1/github/repos/{owner}/{repo}/issues1 credit / run VerifiedRepository Issues
Issues (and pull requests) on a repository. Items with is_pull_request=true are PRs.
Handled for you:Rate Limit
Parameters
| Name | Type | Req | Description |
|---|---|---|---|
| owner | string | yes | Repository owner. |
| repo | string | yes | Repository name. |
| Advanced filters | |||
| state | string | no | open | closed | all (default: open) |
| limit | integer | no | Issues per page, 1-100. (default: 30) |