Cursor removed after adding new object in built-in type queries

Bug Reports Closed
, , , , ,
1

What’s The Bug?

When adding a new object to a query (or regular query) via the “New” button at the top or “New Object” at the bottom (with Grid view), the cursor would previously plug in the template name (or “Untitled” for blank template) and the user’s cursor would immediately follow the new object’s name so you could modify it easily if you want.

Now, when following the same process, the cursor is not added inside the Grid’s column so the user has to click on the edit caret to edit the object name.

How To Reproduce It

  1. Go to any regular query or object type query
  2. Click the “New” button or “New Object” in Grid view, with or without a default template. The object created will be either “Untitled” or “templateNameHere”, but the cursor will not appear at the end of the object name, so you need to click on the object to make it show up again

Image or Video


The Expected Behavior

  • Cursor should appear immediately after the object name when adding a new object.
  • Clicking “Move to bin” should move the object to the bin immediately, not after reload.

Device

MacBook Air M2 2022

OS

15.6 Beta (24G5065c)

Anytype Version

0.47.21-beta

Network Mode

AnySync

Technical Information

OS version: darwin arm64 15.6.0
App version: 0.47.21-beta
Build number: build on 2025-07-02 12:39:20 +0000 UTC at #303e24de035baac910b683124df4d80469c52c94
Library version: v0.42.0-rc10
Anytype Identity: A7NKJThv3PxQdy4p11emUyhvjEh7rxPCXq2iup2Kb4tWhW3n
Analytics ID: A9FwjZbSqB7esWk5h2y3inwoFK8GZBJuTKZFSN7XFVVPMThe
Device ID: 12D3KooWGxZG3BooFEBMvmZYAgV5U4BdkBawLYGdXq2CzY3utvR9
Ethereum Address: 0x2b5813b35893fCF3417783E4407d76af6aFcC671

2

I’m unable to reproduce this in our latest internal version.

We’ll make a new beta soon. Do you mind checking there again?

4

Can do!

5

Just confirmed that the issue is still occurring on 0.47.30-beta.

I’m using the built in queries for the most part (when you’re on the Object Type page). I assume that wouldn’t make any difference, but at least wanted to mention that.

6

Actually, it made all the difference because I’m able to reproduce it now (only in the build- in queries). Thanks!

8

This report has been added to our issue tracker and received by the Development Team.

10

I believe this has been fixed in 0.47.6?

@Filip would you mind double checking me please? I can always use a sanity check :slight_smile:

11

Yap, seems to be fixed for me as well. :slightly_smiling_face:

12

This issue has been fixed by the Development Team and will be implemented in an upcoming release.

13

It was fixed because it does not contain a bug yet, .47.6 is from previous release. Bug was introduced due to addition of record editing in other views apart from grid.

14

Interesting! Should this be reopened/marked as unresolved? Can we confirm that it will be fixed in future versions that allow record editing in non-grid views?

Also just out of curiosity, how I could have gone from 0.47.21 to 0.47.6? I haven’t changed my version set to “pre-release”, but I’m not totally clear on versioning conventions.

15

No, I fixed it today. It happened because stable version was later then beta version and is considered upgrade by the updater mechanism. We usually try to avoid this but it was required to make another hotfix.

16

Thank you for the explanation!