Skip to content

nemo-icon-container.c: Keep icon-view rename open across scrollbar allocations - #3851

Closed
rolanddeboer wants to merge 1 commit into
linuxmint:masterfrom
rolanddeboer:cursor/icon-view-rename-scrollbar-8eef
Closed

rolanddeboer wants to merge 1 commit into
linuxmint:masterfrom
rolanddeboer:cursor/icon-view-rename-scrollbar-8eef

Conversation

@rolanddeboer

Copy link
Copy Markdown

Prepared by an automated coding agent, not a human maintainer.

A Linux Mint user encountered this bug and asked a Cursor cloud coding agent to investigate and fix it. This pull request was written by that bot. The base model was Grok 4.7. Please review it as an automated contribution.

Fixes #3155
Fixes #3755

Problem

In icon view, F2 rename commits after every keystroke when the window is at the size where a scrollbar is just about to appear or disappear. That includes a maximized window on some monitors. Making the window a few pixels shorter or taller, so it is clearly away from that threshold, makes rename work normally.

Root cause

size_allocate() in nemo-icon-container.c relayouts when the allocation width or height changes. Relayout calls icon_set_position(), which commits an in-progress rename (end_renaming_mode(TRUE)) if the icon moves.

Near the scrollbar threshold, GtkScrolledWindow allocates the view twice (narrower with the bar, then wider without it, or the reverse). Commit 39392d0 (issue #1948) skipped only the first of those allocations (renaming_allocation_count == 1). That covers entering rename mode. Typing changes the editable label's requisition and repeats the allocation pair. The later allocation still relayouts, the grid width changes with the canvas width, the icon moves, and the rename is committed. Every key acts like Enter.

Overlay scrollbars do not change the allocation, which is why this shows up with classic scrollbars.

Fix

While a rename is in progress, skip icon relayout for the whole session, not only the first allocation. If a relayout was needed (scrollbar toggle or a real resize), run it once renaming ends.

Enter, Escape, selection changes, and clicks still commit or cancel as before. The container focus-out handler was left as-is: during rename, keyboard focus is on the editable label, and the commit path for this bug is icon_set_position() during relayout.

How to reproduce

  1. Open a folder in icon view.
  2. Resize the window until a scrollbar has just appeared (or the window is maximized and happens to sit on that boundary). A few pixels either way should make the bar appear or vanish.
  3. Select a file and press F2.
  4. Type more than one character.

Before this change, each character commits the name. After it, the edit stays open until Enter, Escape, or an explicit click or selection change.

GtkScrolledWindow toggles scrollbars when the view is sized so the
icons only just need a bar. Each keystroke changes the rename label's
requisition and repeats that allocation. Relayout then moves the icon
and icon_set_position() commits the rename, so every key acts like Enter.

The 2018 workaround only skipped the first allocation of a rename.
Skip relayout for the whole session and run a deferred one when it ends.

Prepared by a Cursor cloud coding agent (an automated bot, not a human
maintainer) on behalf of a Linux Mint user. That person encountered
this bug and asked the agent to investigate and fix it. Base model:
Grok 4.7.

#3155
#3755

Co-authored-by: Roland de Boer <rolanddeboer@users.noreply.github.com>
@mtwebster

mtwebster commented Oct 2, 2026 •

Copy link
Copy Markdown
Member

Cleaner fix: b554532

@mtwebster mtwebster closed this Oct 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unable to rename files Renaming a file stops after first character if the window is just small enough for a scrollbar to appear

3 participants