Anchor panel jumps to top

[MikeTO]

When you rename an anchor or do pretty much anything else in the panel, the panel scrolls back almost to the top (but not quite to the top) and expands all collapsed anchors.

It doesn't change the selected anchor, it just scrolls it far out of view and expands everything. It would be easier if it didn't do either of these things.

Thanks,

Mike

[Dan C]

Thanks for your report Mike!

I can confirm that the Anchors list expanding is already logged with our team, so I'll be sure to 'bump' this report for you now.

In regards to the panel scrolling - in the latest beta on Win & macOS, I see the list moves up 1 entry when adding a new Anchor (regardless of where in the list the Anchor is added), but I'm not seeing the panel scroll as far as you've reported.

Does this also occur in the latest beta for you please?

[MikeTO]

1 hour ago, Dan C said:

Thanks for your report Mike!

I can confirm that the Anchors list expanding is already logged with our team, so I'll be sure to 'bump' this report for you now.

In regards to the panel scrolling - in the latest beta on Win & macOS, I see the list moves up 1 entry when adding a new Anchor (regardless of where in the list the Anchor is added), but I'm not seeing the panel scroll as far as you've reported.

Does this also occur in the latest beta for you please?

It is occurring in the latest beta for me. If I rename an anchor near the bottom of the list it scrolls to the top. If I scroll back down the renamed anchor is still selected. It scroll to the top if I delete an anchor, too.

[Dan C]

Thanks for verifying, I'm using a slightly newer version of the beta than is available publicly - so this may be the reason I'm not seeing the same issue.

Just to check, are the steps I'm taking in the below recording matching yours, when the panel scrolls? As shown, renaming or deleting Anchors does not scroll the panel for me, but I do see collapsed groups become expanded incorrectly -

I happen to have found a separate issue on Windows when renaming Anchors with the text caret not working as expected however, so I'm also logging this with the team now

[MikeTO]

5 hours ago, Dan C said:

Just to check, are the steps I'm taking in the below recording matching yours, when the panel scrolls? As shown, renaming or deleting Anchors does not scroll the panel for me, but I do see collapsed groups become expanded incorrectly

Your steps are the same but I tested by renaming with appended characters in the hope that it would remain in the same order to isolate its movement as a cause.

I tried it with a new doc and couldn't duplicate the issue at all until I made some nested anchors which seems to be the key factor. Here's a quick test doc with nested anchors. In this screen recording it's scrolling up but not all the way like with my real doc. That one has a lot more nested anchors which might be the reason.

test.afpub

 

 

[Hangman]

I think the 'issue' here is that every time you add, edit or drag an item into a group all the collapsed lists expand making the list of items longer which subsequently causes the list to scroll...

I would suggest that collapsed lists should only expand when dragging an item over the parent or when manually expanding the list leaving all other collapsed lists in their collapsed state.

[MikeTO]

4 hours ago, Hangman said:

I think the 'issue' here is that every time you add, edit or drag an item into a group all the collapsed lists expand making the list of items longer which subsequently causes the list to scroll...

I would suggest that collapsed lists should only expand when dragging an item over the parent or when manually expanding the list leaving all other collapsed lists in their collapsed state.

Yep, that's one of the issues. But it scrolls up even when no groups are collapsed, too.

[Hangman]

12 hours ago, MikeTO said:

Yep, that's one of the issues. But it scrolls up even when no groups are collapsed, too.

Agreed, it appears to be the groups themselves causing the issue...

[Dan C]

Apologies for the delay here, thanks for your further files Mike!

I can confirm this still isn't happening on Windows, however I've been able to replicate this on macOS and I concur that the list appears to 'jump' up, seemingly affected by the number of 'Parent' level Anchors created in the file.

I'm getting this logged with our dev team now

[Affinity Info Bot]

The issue "[Win] Mouse cannot control text caret when renaming existing anchor" (REF: AF-312) has been fixed by the developers in internal build "2.3.0.2083".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.

[Affinity Info Bot]

The issue "[macOS] Anchor panel 'jumps' up when editing existing anchor name, provided parent - child hierarchy group is present" (REF: AF-225) has been fixed by the developers in internal build "2.3.0.2083".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.