| Summary: | Details view mode: race condition between scrolling and switching view modes (causes horizontal gap before first column) | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | ratijas <me> |
| Component: | view-engine: details mode | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | amolagodbole, felixernst, kfm-devel |
| Priority: | NOR | ||
| Version: | 21.08.1 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
The bug in a nutshell
Left gap in libs directory How to reproduce |
||
Yesterday I accidentally triggered this bug again, by switching between view modes. Unfortunately, I don't have any new info on how to reproduce it. I'm getting more and more of these lately. Just now I triggered it by switching from Icons to Compact, scrolled a bit to the right (in a big directory full of libs), and then switched from Compact to Details mode. My initial guess is that there's some race condition between switching modes and updating scroll position. It is important to note that I mostly switch modes with shortcuts Ctrl+1,2,3, which my cursor is still over the view with right hand usually on the touchpad. Created attachment 146265 [details]
Left gap in libs directory
Yes, it is easily reproducible by scrolling and letting the scroll snap animation continue while quickly pressing Ctrl+3.
Created attachment 146266 [details]
How to reproduce
Adding a video showing how to reproduce this bug
I wouldn't have believed it if I didn't see it with my own eyes — that's such a direct hit! There are literally properties all over widgets code named leadingPadding:
/**
* Sets the width of the column *before* the first column.
* This is intended to facilitate an empty region for deselection in the main viewport.
*/
void setLeadingPadding(qreal width);
qreal leadingPadding() const;
Where were Dolphin devs when I needed them so much to triage this issue? :c
The leadingPadding variable was only introduced in Dolphin 22.04 (https://invent.kde.org/system/dolphin/-/commit/d3839617193e92463806580699caa595c892b8a6) so it can't be the source of this bug. This might be related to the scrollOffset variables in KitemListView https://invent.kde.org/system/dolphin/-/blob/master/src/kitemviews/kitemlistview.cpp?ref_type=heads. There are m_oldScrollOffset, m_oldMaximumScrollOffset, m_oldItemOffset, m_oldMaximumItemOffset, and m_layouter->scrollOffset. There is also the chance that the bug is somewhere in the code for the details view specifically, but since this seems to be a shared property between the compact view mode and the details view mode, I would assume that the common base class and its scrollOffset are responsible in some way. *** This bug has been marked as a duplicate of bug 393152 *** |
Created attachment 141676 [details] The bug in a nutshell SUMMARY It is somehow possible to get a huge horizontal gap on the left of the table, before the first column. It is scrollable, everything works as it should, except this padding should not exist. Observations: 1. It is persistent when switching different view modes, although only occurs in "details". 2. It is persistent when changing directories. 3. It is local to one tab. 4. It is gone after detaching a tab into a new window. STEPS TO REPRODUCE 1. Launch dolphin 2. Change directories and view modes 3. ??? OBSERVED RESULT See the screenshot attached. EXPECTED RESULT Should be no gap. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 970M/PCIe/SSE2 ADDITIONAL INFORMATION