Zettlr
Documents un-selectable in the file manager.
Description
When browsing files and folders in the file manager, I am unable to select any documents. Navigating between folders works fine, but clicking a file (most often) does nothing — the document does not appear in the editor frame and the file manager UI does not indicate that the file has been selected.
On occasion, clicking a file will bring up the wrong document in the editor window — i.e., one other than the file with the name that I clicked on. When this happens, the file manager display UI will (usually) jump to the file that was opened, sometimes in a different workspace. This behavior is unpredictable and difficult to reproduce, but it seems likely that it's related to issue #4956 .
Reproducing
See above. Open Zettlr and click around between documents. It seems that this behavior has gotten worse between sessions — a few sessions ago I was able to select at least some files, but the file manager UI is increasingly paralyzed. Toggling between different file manager display modes does not seem to have any effect.
One hypothesis — and I know nothing about the file manager's styling, so take it with a grain of salt — is that there's a layering/z-index issue, in which a transparent element is somehow positioned atop the files the user aims to select, allowing the user to see the file names, but causing the click event not to be registered or to be captured by the wrong element.
Zettlr Version
Nightly
Specify version
Zettlr 3.0.5-nightly
Installation Method
From the Website or GitHub
Your Platform
- [ ] Windows
- [ ] macOS
- [X] Linux
Architecture
- [X] Intel 64bit
- [ ] ARM 64bit
Operating System Version
Manjaro (Rolling)
Additional Information
I use the AppImage.
I just tried to reproduce this issue across all settings of the file manager, but couldn't reproduce this. I don't know what might be causing it, but have you tried clearing the FSAL cache? I fixed a bug relating to that recently, and that may have caused a hiccup (the app won't clear the cache on each nightly, since the version number remains the same).
Otherwise, if that doesn't help, does removing all workspaces and re-adding them work?
I've installed the latest nightly (2024.02.26) and the bug persists. I tried clearing the FSAL cache. No effect. I also tried removing and re-adding all workspaces. Problem persists. One thing I did discover this time is that I can right-click a note and select "open in new tab" and access files this way. But left-clicking on files still has no effect.
When I right-click to open a note, I'm still having the issue where the wrong note sometimes opens. The whole thing is bizarre.
Resolved by deleting my application data folder (~/.config/Zettlr), re-launching Zettlr, and then re-adding my workspaces again/re-integrating my citation manager. I backed up the original application data folder, so I'd have my stats, snippets, etc. and in case anything there has any diagnostic value.
It may actually be a good idea if you could send your config just so that I could have a look -- maybe there's something in there that looks odd for me! Feel free to drop it over via email!
Closing, and hoping it stays gone! ;) If not, please ping me again!
Sadly, the problem is back almost as quickly as I fixed it. Clicking on files in the file manager either fails to open them or opens the wrong file. Additionally, as I click around the file manager strange gaps between file names sometimes appear (see image). These gaps go away again after more attempts to select files. Sadly, Nightly remains unusable for me until this is fixed.
Hmm. When those spaces open up, they collapse again upon scrolling in the file manager. However, afterward, it appears that Zettlr is misgridding — clicking on a file name might open a file several items further down the list and it seems that, at least some of the time, the distance in the file list between the document that I'm selecting and the document that actually opens may have to do with the size of the gap that opened and disappeared.
Other times the relationship between the file I click on and the one that opens appears totally nonsensical. I really have no idea what's going on, but it's super frustrating.
What you are seeing is that the virtual scroller is messing up. Specifically, it places documents based on an offset based on their index, and if that gets wrong, it will start producing gaps and overlaps. I've had this problem in the past. I am unable to reproduce it just yet, even with larger documents, so please keep the dev tools open in case there are any Vue warnings generated that might hint to that. I have the suspicion I need to adapt the v-for-keys in the list, but I'm not entirely certain.
Thank you for this update. I've had the JS console open for the past couple days. Only one error (and only one occurrence of it) so far, despite lots of clicking around:
GET safe-file:///home/josh/Dropbox/Slip Box/Literature Notes/:/e99a0eb9ca3b4fc8be06d315a8ba6f98 net::ERR_FILE_NOT_FOUND
Combined view is a little better than the other file manager views, but it's still squirrelly. For example, collapsed workspaces will sometimes re-expand unbidden when I select a file elsewhere in the tree. I've sent you a screen recording of one such occurrence.
Today, I had the same problem when I switched from stable 3.05 to beta 3.1 on macOS. I went back to 3.05 and the problem disappeared.
Just had a Zoom session with @wideaperture and now we're a small step further: I can reproduce the issue. I'll see to tracking down the bug in the coming days.
Quick update: I ran a bit of debugging, and I have a hunch that the issue might originate with vue-virtual-scroller. That library hasn't been updated in ages, and I believe it chokes a bit when it comes to the composable container that I use. I believe we may be better off turning away from that library and handling this ourselves.
However, virtual scroll lists are definitely a bit difficult to implement, so this could take a while.
For transparency reasons, I should also mention here that I'm not a fan of the file list component anyhow, and was pondering the thought of how much simpler it would be if I dropped support for that entirely. I know that many still use it, so it's not going to happen, but I believe it may make it more difficult for me to get working on this …
Thank you for the update. For what it's worth, the main advantage I see of the file list/"Thin" file manager view is that it allows me to focus on the documents that are part of the particular project that I'm working on at the moment. If there are a lot of workspaces open in Zettlr, or if workspaces have trees of subfolders, the combined view can be comparatively busy. If there were a way to focus the combined view a bit more — for example, to zoom in on a particular workspace and its subfolders — that would give some of the same benefits.
The quick stats displayed in the file list — word count and modification date — are nice, too, but they're of secondary importance to workspace focus for me personally.
Ah I can see that. And I guess that's probably one explanation for why many are still using the thin file list.
I'll have to think about it, or rather: I should think about this when doing the user survey ...
So let's table this issue for now and see to get to others first 👀
Sounds good. For what it's worth, other text editors and IDEs with a file tree browser like the combined view will often have a feature where the user right-clicks the folder they want to focus and chooses "Set as root" from a context menu to zoom in on that folder. This seems like it might be a relatively straightforward solution if you're looking to standardize around the combined view file manager. Here's what similar functionality looks like in Geany's Tree Browser, for example:
https://github.com/Zettlr/Zettlr/assets/3809531/66697c57-92df-4205-86df-9db3d10b0fc1
Yes, I understood that – the question is more how to technically implement this :D But there may be a way. Other than that, I could also try to just fix the thin file list, because apart from this very weird clicking behavior, it does work, so … well.
Today, I had the same problem when I switched from stable 3.05 to beta 3.1 on macOS. I went back to 3.05 and the problem disappeared.
Just wanted to mention that I'm also having this problem in the 3.1 beta on macOS but not in 3.05.
I'm here to report the same issue Windows 10, Zettlr 3.1.0 Beta. Never had this problem before. I can click on files in the folder manager but only already open/pinned tabs are recognized (= click on a file in the manager that is already pinned but not open jumps to the correct tab, no reaction for other files). Work-around so far is to use the global search and the right-click "Open in a new tab". Thank you.
Also here to report same issue with 3.1.0-beta and 3.1.0-beta.1 (on linux).
I'm also using thin view, and didn't realize that the bug occurs only with this view as well as with the expanded view. Until it is fixed I will therefore use the combined view which is not affected by the bug.
Work-around so far is to use the global search and the right-click "Open in a new tab". Thank you.
@tfr00 This is an important detail. Does this work consistently, especially when a regular click does not work? This would mean that the issue is exclusively related to left mouse clicks, which would disprove my theory that the virtual scroller may be at fault. Also, @wideaperture can you confirm this?
In my case, using the global search to find a file, I can then open the correct file with a left click, and with a right click + "open in a new tab". The right click + "open in a new tab" trick does not work in the file tree (in thin view).
I noticed something though since the 3.1.0-beta, I don't know if it can be related : on the loading panel when I launch Zettlr, some messages indicate "Impossible to open workspace [workspace-name]". It's really quick so I'm not sure if every workspace is concerned. The message is strange since then it correctly shows the folders and their content...
Work-around so far is to use the global search and the right-click "Open in a new tab". Thank you.
@tfr00 This is an important detail. Does this work consistently, especially when a regular click does not work? This would mean that the issue is exclusively related to left mouse clicks, which would disprove my theory that the virtual scroller may be at fault. Also, @wideaperture can you confirm this?
OK, I checked again: In "File Manager" left click works for tabs that are already open. Left click on some folders works but jumps to a "random" tab that is already open. Right click on a file + "open in a new tab" opens a "wrong"/different file in a new tab. In "Global search" right click + "open in a new tab" opens the correct file in a new tab.
I hope this helps. Feel free to ask me for a check again. Thank you.
Right-clicking and using "open new tab" in the thin file manager view/file list doesn't perform any differently than left-clicking. It's still broken — opens the incorrect file, and the right-click workflow opens the same incorrect file as left-clicking would. The Global Search view has worked consistently and has never been subject to this bug.
Right-clicking and using "open new tab" in the thin file manager view/file list doesn't perform any differently than left-clicking. It's still broken — opens the incorrect file, and the right-click workflow opens the same incorrect file as left-clicking would. The Global Search view has worked consistently and has never been subject to this bug.
Seems to be a bit different on veriying systems? For me left clicks (File manager) only work as described above (= under specific circumstances). So there are different patterns but one can assume that the veriying expressions are related to the same kind of problem. The Global search was mentioned by me as a work-around; here the right click "Open in a new tab" works as it should. Not knowing how filemanagement et al. work in Zettlr, I added this information as it might be helpful to solve the bug.
Seems to be a bit different on veriying systems? For me left clicks (File manager) only work as described above (= under specific circumstances). So there are different patterns but one can assume that the veriying expressions are related to the same kind of problem.
Quite possibly! It's also varied over time for me. When the bug first started occurring on my machine, more and more files became unclickable over the span of a week until nothing was selectable any longer and, when a click occasionally did work, it would open the wrong file or focus an already-open tab. When clearing the FSAL cache didn't work, I backed up and erased my settings folder, then re-added my workspaces. This started the cycle over again, with things working initially, then quickly becoming unusable again. Now clicks mostly work, but launch the incorrect file, sometimes from an entirely different workspace. However, I've reverted to Combined view, which isn't affected by the bug (or at least not as severely) and so I've not been working with the thin/file list view frequently enough to ascertain whether it would snowball again into a completely frozen state with continued use.
FOUND IT!
It really was an update issue as I already thought back when we had our meeting, @wideaperture.
I'm going to commence a new nightly today so that you should be able to confirm/not confirm that it's actually fixed tomorrow.