Crash to Desktop when containing object is destroyed while renaming inventory item

Environment

Second Life Release 26.3.0.31203661088 (64bit)

Description

The viewer crashes immediately with an Access Violation (0xC0000005) if an in-world object is destroyed (via llDie(), temp expiration, or deletion) while an item in its task inventory is being renamed. When the view is torn down, the focused rename field attempts to commit on focus loss after the folder view model has already been cleared.

Reproduction steps

1. Rez any prim/object in-world.

2. Place a script inside the object that calls llDie() after a short timer, Set the object temporary, or simply have another user delete the object when instructed to do so.

3. Add any second inventory item into the object (e.g., a notecard, landmark, or script).

4. Right-click the item in the contents tab and select Rename so the inline text edit field is active with keyboard focus.

5. While the text editor still has focus and there is a pending change to the name, trigger the destruction of the object.

Observed Result:

The viewer crashes to desktop immediately.

Expected Result:

The rename operation should abort cleanly without crashing the viewer.

Suspected cause:

The rename isn't canceled when the object is destroyed

When the containing object dies, LLPanelObjectInventory::clearContents() queues the scroller for deletion (die()) and sets mFolders = NULL. However, it never cancels the active rename or drops keyboard focus from the text field (mRenamer).

When LLMortician cleans up the views on the next pass, LLFolderView::~LLFolderView() runs first and sets mViewModel = NULL.

As the base destructors finish tearing down the view hierarchy, focus is finally stripped from mRenamer. Because the field is set to commit on focus loss, it tries to finish the rename and calls arrange().

Inside arrange(), it calls getFolderViewModel()->sort(this). Since mViewModel was already cleared in step 2, this immediately blows up with a null-pointer dereference (0xC0000005).

Fix:

The fix is to cleanly cancel the rename and drop focus before destroying the views, rather than letting focus loss trigger a commit during teardown.

1. Add cancelRenaming() to LLFolderView: Disables commit_on_focus_lost, removes the popup, and cleanly releases focus.

2. Cancel renaming during cleanup: Call cancelRenaming() in ~LLFolderView(), deleteAllChildren(), and LLPanelObjectInventory::clearContents().

3. Add null checks: Guard against a null mViewModel in commitRename() and finishRenamingItem() so arrange() won't attempt to sort a destroyed view.

Start with LLFolderView cleanup and rename paths, especially cancelRenaming(), commitRename(), finishRenamingItem(), and LLPanelObjectInventory::clearContents(). Reproduce the destruction-while-renaming scenario, then verify that cleanup cancels the rename before the views are destroyed and that the viewer no longer crashes when focus is lost.