# Edit "title" misbehavior
**URL:** https://community.mp3tag.de/t/edit-title-misbehavior/57053
**Category:** No Bugs
**Created:** [April 16, 2022, 1:55pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053 "2022-04-16T13:55:38Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@ncfernan](https://community.mp3tag.de/u/ncfernan)
#### Post date: [April 16, 2022, 1:55pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/1 "2022-04-16T13:55:38Z")
Try this on version 3.14:
1. open mp3 file with title = "Remember I Love You - 1985"
2. delete " - 1985"
3. go to "L" letter and make it "l" (lower case "L")
The " - 1985" pops in again. It happens all times.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 16, 2022, 2:01pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/2 "2022-04-16T14:01:36Z")
I assume that you use the tag panel?
Because it does not happen if you use the files list and the corresponding field.
I can reproduce this - the reason is that the input field auto-completes the title with already known data from the loaded file.
The observed behaviour is not limited to the field with the contents of TITLE but applies actually to all the fields with a dropdown list.
The only workaround I could think of: do the other corrections first, then cut the unwanted parts.
---
### Author:  [@ncfernan](https://community.mp3tag.de/u/ncfernan)
#### Post date: [April 16, 2022, 2:41pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/3 "2022-04-16T14:41:54Z")
I use the field below:
If I cut the suffix first, the edit procedure starts and should not reload the field contents on the second change (letter). This is the behavior I would expect from this field.
If I change the letter first and let the suffix cut for last, it works.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 16, 2022, 2:44pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/4 "2022-04-16T14:44:56Z")
Still, I think that the auto-completion is a welcome feature in many use cases.
TBH I can't think of a real workaround except that you do it in 2 steps and save the modification after each step. (Ctrl-S)
Then the new (concatenated) data is saved and you do not get the old long one again. You should then be able to swap the case without problems.
---
### Author:  [@ncfernan](https://community.mp3tag.de/u/ncfernan)
#### Post date: [April 16, 2022, 3:47pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/5 "2022-04-16T15:47:07Z")
Regarding the copy, it is first made when you select the line on the right, so it doesn't need to reload when the edit starts, as it was loaded on select. There is a second (unnecessary) copy triggered by the first edit, in my opinion.
If I edit other field before doing any modification to the title field, it works as I expected. The (additional) copy occurs in the very first edit.
---
### Author:  [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [April 16, 2022, 5:53pm UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/6 "2022-04-16T17:53:29Z")
Auto complete functions this way in many applications. The current value of the field is what is retained until you save the changes. I wouldn’t want to change this behaviour.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 17, 2022, 7:26am UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/7 "2022-04-17T07:26:28Z")
As far as I can tell, all of this is intended behavior — moved to #bug-reports:no-bugs for future reference.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [May 17, 2022, 7:26am UTC](https://community.mp3tag.de/t/edit-title-misbehavior/57053/8 "2022-05-17T07:26:54Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.