Site Editor Identity screen crashes blank (React insertBefore error) after saving Site Icon with stale cached site data

[369work]

Bug Report

Description

Site Editor (Appearance > Identity) goes completely blank after uploading and saving a new Site Icon, when the browser has accumulated site data (Cache storage / IndexedDB / Local storage) from prior use of this site. In my case that prior use was repeated media uploads in the block editor.

Environment

• WordPress: 7.1
• Subdirectory: No
• PHP: 8.4.24
• Server: PHP/8.4.24 (Development Server)
• Database: WP_MySQL_On_SQLite (Server: 8.0.38 / Client: 3.53.2)
• Browser: Edge 152.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.5
• MU Plugins:
  • 99-studio-loader.php
• Plugins:
  • Query Monitor 4.0.7
  • Test Reports 1.3.1

Steps to Reproduce

1. Use a browser profile that has previously used this site's Site Editor and accumulated site data (Cache storage / IndexedDB / localStorage). A clean profile does not reproduce it.
2. Go to Site Editor > Styles > (or Appearance > Editor) > Identity.
3. Upload a new Site Icon and confirm the crop (removing an existing Site Icon reproduces the same crash as well).
4. Click Save, then confirm in the review/publish dialog.
5. The entire admin screen goes blank (only the admin toolbar remains visible).

Please note: these steps may still not be enough to reproduce this. There is an additional precondition in the browser's stored state that I have not been able to identify.

Query Monitor's toolbar item shows "Data collection ceased". The browser console shows:

Uncaught NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.

at react-dom.min.js?ver=18.3.1.1 (multiple frames)

Expected Results

1. On a normal successful save, the screen does not change/reload at all — a success toast/snackbar notification appears in place, and that's it.

Actual Results

1. The Site Editor screen renders fully blank (no error message shown to the user) after the save confirmation. The site icon IS actually saved successfully server-side (visible elsewhere in wp-admin after reload) — this is a client-side rendering crash, not a save failure.
2. wp-content/debug.log stays empty — no PHP error is logged.

Additional Notes

• Confirmed this is not caused by browser extensions: reproduced with no extensions installed, and does NOT reproduce in an InPrivate/incognito window with a clean profile.

• Reproduction stops entirely after clearing this site's data via DevTools > Application > Storage > Clear site data (Cache storage, IndexedDB, Local/session storage, Cookies).

• This site has always been WordPress 7.1. No version upgrade was involved, and the Gutenberg plugin had never been activated on it — the accumulated data is from ordinary use of 7.1 itself. Before hitting this, the same browser profile had been used for repeated media uploads in the block editor (HEIC upload testing for ​https://github.com/WordPress/gutenberg/issues/81043).
• I cleared the storage before inspecting its contents, so I cannot say which piece of stored state actually triggers this.

[369work]

console error

[369work]

white monitor

[369work]

console error

[wildworks]

Thanks for the report. Since the identity screen is a new page in 7.1, it might be better to fix it in a minor release.

[wildworks]

I cannot reproduce the problem.

the browser has accumulated stale site data (Cache storage / IndexedDB / Local storage) from a previous WordPress/Gutenberg version on the same site.

@369work Could you tell me more about this point? Should we test it with Gutenberg enabled? Or should we simply access the Site Editor in WordPress 7.0 and then update to 7.1?

[369work]

@wildworks, Apologies — I need to correct my own report.
The phrase "from a previous WordPress/Gutenberg version" in the description was my speculation, not
something I actually verified, and it is misleading. Please disregard it.

Here is what I can actually confirm:

• This site has always been WordPress 7.1 (Studio-based trunk environment). There was no version upgrade involved.
• The Gutenberg plugin had never been activated on this site at the time of the crash.
• Only Query Monitor and Test Reports were active, as listed above.
• Shortly before hitting this, I had been testing HEIC media uploads for that same Gutenberg issue #81043, in the same browser profile. Those uploads hang by design of that bug, so the editor's client-side upload state may have been left in an unusual condition — but I have not verified any connection, and I am flagging it only as a possible lead.
• What I did verify: the crash reproduced repeatedly in my normal browser profile, did NOT reproduce in a clean InPrivate window, and stopped reproducing entirely after clearing this site's data (Cache storage / IndexedDB / Local and session storage / Cookies).

Unfortunately I cleared that storage before inspecting its contents, so I cannot say what in it triggered the crash.
Sorry for the noise in the original description.

[wildworks]

@369work Thanks for the reply. Could you update the ticket description and remove any speculation or unsubstantiated points? This will help other contributors test correctly without confusion. In any case, we still need to find a reliable way to reproduce this issue.

[adamsilverstein]

Please note the RC for 7.1.1 is September 10th if we want it included in that version. Otherwise it is fine to punt to 7.1.2.

[369work]

Earlier I suggested that leftover browser data from some HEIC upload testing might be the trigger here. I've now tested that directly, and it does not hold up.
Correcting that below.

What I did

1. Cleared this site's data (DevTools > Application > Storage > Clear site data) and logged back in.
2. Captured the browser storage for this origin right after that — localStorage, sessionStorage, cookies, Cache storage, IndexedDB and service workers.
3. Opened the post editor and the Site Editor once each without doing anything, and captured again.
4. Repeated the exact HEIC upload cycle from ​https://github.com/WordPress/gutenberg/issues/81043 13 times (the original run was "10 or more", so this goes past it).
5. Captured again.
6. In Site Editor > Identity, tried both setting a new Site Icon and removing it.
7. Captured again.

Environment: WordPress 7.1, Edge 152, Windows. SCRIPT_DEBUG was false, so the same minified React build as the original crash was loaded.

Results

• It did not reproduce. Neither adding nor removing the Site Icon blanked the screen.
• Cache storage, IndexedDB and service workers were empty in all four captures — before, during and after. Nothing is ever written to them.
• The only thing that accumulated across 13 rounds was 153 bytes in localStorage:

"WP_DATA_USER_1": {
  "core/block-editor": {
    "preferences": {
      "insertUsage": {
        "core/image":     { "count": 26 },
        "core/paragraph": { "count": 27 }
      }
    }
  }
}

That is just a counter of how many times each block type was inserted.

What this means

• The repeated HEIC uploads are not the precondition. I had flagged them as a possible lead; that lead is now ruled out.
• Clearing the site data did stop the crash — that part stands. But what I actually used was "Clear site data", which wipes localStorage and cookies (logging you out) alongside Cache storage and IndexedDB. Which of those actually mattered was never established.
• That leaves localStorage (editor preferences and state) and cookies as the remaining candidates.

The precondition is still unidentified. Whatever had accumulated in my original profile is gone, so I can't go back and inspect it.

[wildworks]

No one has been able to reproduce this bug yet, and I haven't heard of any similar reports. If it proves difficult to reproduce, I suggest we close this ticket for now.

[369work]

Thanks for reading through the test results.

I agree — it can't be reproduced on demand, and my own attempt to reproduce it failed too.
I have no argument with that part.

What still holds, though, is that it did happen: repeatedly, in my normal browser profile, both when setting a new Site Icon and when removing an existing one.
It happened at least three times in a row, counting the runs I did specifically to verify it for this report.

Same symptom every time — an insertBefore NotFoundError from react-dom.min.js and a blank Site Editor.
It never happened in a clean InPrivate window, and it stopped once I cleared this site's data.

The one thing I couldn't pin down is which piece of browser state triggers it.

So: would it be reasonable to leave this open for a while with something like needs-testing, rather than closing it now?
If someone else hits the same symptom, the notes here would save them the steps I already ruled out.

If you'd rather close it as worksforme to keep the queue manageable, that's completely fine by me.
I'd appreciate it if it could be reopened later, should similar reports come in.

[wildworks]

Let's close this for now. We can reopen it at any time if someone else can reproduce it or if we figure out the steps to reproduce it.