files-community
Bug: Active tags widget causes home page to freeze
Description
I thought it was some known general performance issue, but I realized it's the tags widget's fault. If it's active, when I open the app it freezes for no less than 20 seconds. (On a 14700k).
And it always loads all tag elements in duplicate.
Steps To Reproduce
The exact steps to reproduce the issue are:
- Configure the files app to load the home page, or continue a session, or load pages that include the home page
- Have the tags widget enabled
- Have several tags with elements (8 tags in my case, with about 4–5 elements per tag, nothing excessive)
- Start a new instance from scratch (not running in the background)
Then the app becomes unresponsive for 20 seconds or more until the tag widget finishes "doing its thing" (leaving all items duplicated as well).
If I disable the tag widget, everything works fine, even when creating new instances.
Files Version
v4.0.11
Windows Version
10.0.26100.0
User ID
9baec1c2-1793-4175-a258-57a34bc58c31
Log File
No logs needed.
I only use the preview version so I don’t know, but I stopped using the app in version 3.9.2 because of this issue. When I saw the update to 3.9.9, I tested it to see if it had been fixed, and that’s when I discovered the tag widget was the culprit.
Given how old it is, I can confirm it’s not a bug introduced in recent versions, but something that was already there.
Testing in the stable version, the issue doesn’t occur, but I’m not sure if that’s because it’s an earlier version than 3.9.2 (I see it’s 3.9.1) or due to another reason, as I explain below.
When exporting the configuration from the preview version and importing it into the stable version, the tags are missing, but the tagged files appear with a tag labeled “unknown” (and the stable version crashed once). Since my tags weren’t there, I created new ones, and the error didn’t occur.
I went back to the preview version, to my first tag “Main” (which had about 10 files/directories associated with it), and opened the first one, “Downloads.” I navigated up one level (to my user folder) to view the Downloads directory and saw that it didn’t display any tag beside it. After reapplying the tag, all items previously tagged as “Main” were removed.
So the bug might happen due to some kind of tag corruption. I’m going to try recreating my tags and reassigning them from scratch in the preview version, but it’ll take me a bit of time.
Trying to create new tags in the preview version, but literally every time I try to create a tag and click the “Create” button, the app crashes. I’ve verified that if I create them directly, it doesn’t crash. It crashes with this flow:
- Edit an existing tag
- Click on the color square
- When switching to the third color tab, it appears as white (FFFF), so I have to close the color window. The tab becomes “broken” as shown in the image (it no longer displays any color in its selector).
- I cancel the edit and reopen it; this time, it shows the HTML color code and I can copy it.
- I create a new tag with a different name, open the color selector, go to the third tab (again, shows white when isnt), and paste the copied color from the previous tag.
I click the “Create” button. The app crashes.
When reopening the app, the tag is indeed created. But I delete it because I don’t trust that it’s not “corrupted.”
So I create new tags without assigning colors (no crash). I edit the previous tags twice to copy the color and apply it to the new ones without crashes. Then I go into each original tag to view all the items, select them all, and assign the new tag that replaces the previous one. I delete all original tags.
I enable the tag widget, fully close the app (including from the system tray), and when reopening it, the same problem occurs. Frozen for 20 seconds or more, and all the tag elements appear duplicated.
In summary:
- The bug is fully reproducible in the preview version
- It does not occur in the stable version
- It doesn’t seem related to corrupted tags
- There’s an additional bug when editing a tag’s color
Important note: I'm noticing that in certain cases there are "natively duplicated" items (they appear twice). At first, it didn’t seem like a bug (because each item has a completely different path, even though I definitely didn’t add both paths with the tag), but in fact, it’s a serious bug.
It happens because a certain level in the directory hierarchy is a symlink (yes, I know it’s uncommon in Windows, but some development environments use them out of necessity). So, if I tag an item that has a symlink somewhere in a parent directory, it appears duplicated/triplicated, etc., for that tag because each path that includes a symlink to the directory (which contains tagged subdirectories/files) is counted as a separate path. (Even if I only tag the item using the native path and not through the symlink path).
I removed the tags from those two items thinking it might be causing some kind of internal loop, but unfortunately this does not fix the issue.
In fact, since the paths are different, it shouldn’t matter whether symlinks are involved or not. And after testing the stable version, it also fails and ends up crashing. The directory is initially tagged, and then I tag one of its subdirectories with a different tag. These directories lose their original tag and get a system-generated tag called “Unknown”, and it crashes every time I navigate to directories with that tag.
Bug analysis summary: The stable version also has critical bugs with tags:
- Crashes when creating tags
- Crashes when navigating directories that are children of directories with symlinks (even if it’s the original directory)
- Tags are lost and replaced by a system-generated tag called “Unknown”
https://github.com/files-community/Files/issues/17128#issuecomment-2923542867
For the linked issue please make a new bug report as it different to this one
Answered in https://github.com/files-community/Files/issues/16447#issuecomment-3314746857