Summary: | Terminal panel can become de-synced with the view, such that deleting the folder that the terminal panel is showing and then focusing the terminal panel will cause the main view to try and fail to enter the deleted folder | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | ferweer <gyrlgith> |
Component: | panels: terminal | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander.kowalski, felixernst, firlaevhans.fiete, kfm-devel, nate |
Priority: | NOR | ||
Version: | 19.04.3 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/system/dolphin/commit/e70e12e3bdf3ce4e9cca4c8f003655ea10b21d7e | Version Fixed In: | 22.04.1 |
Attachments: | Screen recording |
Description
ferweer
2020-01-24 12:29:57 UTC
I'm not quite sure if what I'm experiencing is exactly what you are describing but I'm regularly encountering a similar bug: The folder doesn't need to be on an external drive. Select a folder and hit shift+delete to delete it without moving it to the trash first. In the confirmation dialog, just hit the enter key. The dialog window will close, the folder will be deleted, but then dolphin will enter the (deleted) directory and show a warning that the folder doesn't exist. This bug doesn't always occur, and I have not been able to find out how exactly you can reproduce this bug. I just had that bug happen again, but after that I created and deleted a bunch more test folders and couldn't reproduce it again. First I thought maybe the main dolphin window still registers the press of the enter key after the dialog closes and moves into the directory right as it is being deleted, but when I purposely keep the enter key pressed a bit longer, that doesn't make the bug occur. I'm on Dolphin 20.12.3 on Arch Linux right now but I've encountered that bug every so often for months if not years. Sorry, I'm having a hard time understanding the problem. Could you attach a screenshot--or even better, a screen recording--that shows the issue? Thanks! (In reply to Nate Graham from comment #2) > Sorry, I'm having a hard time understanding the problem. Could you attach a > screenshot--or even better, a screen recording--that shows the issue? Thanks! Unfortunately it's kind of difficult to get a screen capture of a bug that you can't reproduce on purpose. I just tried to make the bug happen again with OBS running but... I couldn't... But in short, sometimes when you delete a folder in dolphin, and press enter in the confirmation dialog, dolphin will enter the deleted directory (and complain that the path no longer exists). I haven't figured out if there's a specific reason why this would occur, because, again, this bug never happens when I WANT it to happen, but it happens rather often in normal use. I see, that helps. Probably what happens is that the return key gets forwarded to the view after the dialog closes, and there' a brief second in which the folder is still visible, so Dolphin tries to enter it, but this fails because a micro-second after that, it gets deleted. That said, I cannot reproduce the issue with the current git master version. Could you please try again with the version of Dolphin in Kubuntu 21.04, which is due to be released in a few days? (In reply to Nate Graham from comment #4) > I see, that helps. Probably what happens is that the return key gets > forwarded to the view after the dialog closes, and there' a brief second in > which the folder is still visible, so Dolphin tries to enter it, but this > fails because a micro-second after that, it gets deleted. > > That said, I cannot reproduce the issue with the current git master version. > Could you please try again with the version of Dolphin in Kubuntu 21.04, > which is due to be released in a few days? I just tried it on the Ubuntu 21.04 Beta as well as git master and couldn't reproduce it either, but then again, I can't even reproduce it with the version on which I just experienced that bug a few days ago (also 20.12.3 on Arch). So even if you couldn't reproduce it the bug may very well still exist, I just have no idea how to trigger it (probably the timing and perhaps the size of the folder have to be just right?) But then considering that this bug only happens every once in a while and is barely annoying I don't know whether it is worth spending too much time trying to hunt it down. But the enter key being forwarded to the main dolphin window in the split second where the folder is still there would be my best guess too. OK. :) Let's re-open if it happens again with a recent version. Created attachment 148270 [details] Screen recording I just noticed the recent activity here (compared to my comment on bug 391380 at least) and while I am still not absolutely sure that this is a duplicate of that one, the description in the new comments sounds very much like that to me, I can still reproduce this issue reliably using the latest version and I also found out what the cause was back then, just no easy and reliable fix (see comment there). I made a recording of encountering the issue, the only time-critical step is changing between the views fast enough that the terminal does not keep up (this does not require split views, happens with other navigation too). (In reply to Alexander Kowalski from comment #7) > Created attachment 148270 [details] > Screen recording > > I just noticed the recent activity here (compared to my comment on bug > 391380 at least) and while I am still not absolutely sure that this is a > duplicate of that one, the description in the new comments sounds very much > like that to me, I can still reproduce this issue reliably using the latest > version and I also found out what the cause was back then, just no easy and > reliable fix (see comment there). I made a recording of encountering the > issue, the only time-critical step is changing between the views fast enough > that the terminal does not keep up (this does not require split views, > happens with other navigation too). Interesting, so this issue does definitely look like a sub-issue of the one you reported (which I've definitely encountered before as well). So at least we finally know how to reproduce this reliably, the steps are: 1. Open Dolphin and open the F4 terminal panel 2. Create a folder and enter it 3. Quickly press Alt+left arrow and Alt+right arrow repeatedly to go back and forth until the terminal can't keep up any more and thinks you're still inside the new folder when you aren't 4. Delete the folder while the terminal panel is still inside it -> Dolphin enters the folder after deleting it and then complains that the folder doesn't exist (I reopened this issue for now but maybe it should be marked as a duplicate of your bug instead, I don't know) Thanks, I can confirm the issue with those steps! Seems like we should fix the problem of the terminal panel becoming de-synced from the view. Then the bug can't happen. I opened a merge request: https://invent.kde.org/system/dolphin/-/merge_requests/382 Git commit e70e12e3bdf3ce4e9cca4c8f003655ea10b21d7e by Felix Ernst. Committed on 27/04/2022 at 10:40. Pushed by felixernst into branch 'release/22.04'. Fix terminal panel not keeping up with dir changes The terminal panel is supposed to show the same location as the currently active Dolphin view at all times. However there was an issue when the terminal is supposed to quickly switch to a new location and then back again to the old one. The terminal ignored the switch to the old location unless it had already fully switched to the new location. Because it isn't particularly fast at fully switching to the new location, it would never do the expected thing of switching back to the old location. This commit makes it so the switch to the old location is only ignored if there are no in-progress switches to a different location. Related: bug 391380 FIXED-IN: 22.04.2 Not totally sure if this fixes everything but it seems like an improvement. M +5 -3 src/panels/terminal/terminalpanel.cpp https://invent.kde.org/system/dolphin/commit/e70e12e3bdf3ce4e9cca4c8f003655ea10b21d7e |