Bug 310288

Thanks for the bug report.

@Sebastian: I see that you have implemented this (bug 181823). Can you have a look? I don't have such a mouse, so I can't do much about this :-(

Yes, this report is correct, but the behaviour is intentional.
It was possible to do that before the history support was implemented and I kept it this way. This is especially useful if you have single-click enabled, because it make it possible to select items easily without having to exactly target the "+" part of the icon.

It might be debatable if it should be this way, but I thinks it is better to kept it as is. There is plenty of "white space" around icons and file names, where the history support triggers. Hence I'd vote to make this "WONTFIX". 

Burgess, if you have especially strong feelings about this issue, please explain your reasoning.

Your intention is considerate, but I'm used to double-click mode.

But if I have a lot of items in a directory, and each item has a large icon, or have a long name in the the details or compact view mode, the "white space" will be small, I have to carefully notice where is my mouse pointer stays. It's not very convenient.

Thanks Sebastian for the information and thanks Burgess for the description of your use case!

I think that this is more a feature request than a bug then because it requests to change the current intended behaviour. If we get feedback from many more users about this issue, we might reconsider it.

Isn't there already ctrl+click to select items even when using single-click?
Imo its not consistent to have an action not work because the mouse-pointer is not exactly between two items.
I at first didn't even know why it sometimes just worked and sometimes took 2-3 clicks.
Only after a few times using the feature I figured out what was going on and immediately wanted to file a bug-report because I couldn't imagine that this was intended behavior.

At least consider making it an option to choose.

I am also annoyed about this. The back and forward mouse buttons should go back and forwards. This is the expected behaviour and it is being used in all other programs, like e.g. web browsers, file managers, viewers etc. Dolphin is the sole program I have ever seen that uses those two buttons for something irrationally different like selecting items. Why do you try to reinvent the wheel is beyond me.

Furthermore I also consider this as a regular bug. The button functions should not change under any circumstances.

Did the commit for bug 327412 also fix this one? I have no mouse to test.

I also support removing this functionality. It is incredibly frustrating having to make sure my mouse is not on a folder when pressing back/forward, especially with a high DPI mouse. There really shouldn't be a need for 3 different buttons to do the same thing (left mouse, back, forward, all selecting a folder).

At the very least offer us a way to remove this "feature."

Git commit 7204392dcab240c59669dbf8046581bc8c49a8b9 by Frank Reininghaus.
Committed on 01/03/2014 at 11:14.
Pushed by freininghaus into branch 'KDE/4.13'.

Always go back/forward in history when pressing the respective buttons

Before this patch, pressing one of these buttons while an item is
hovered selected this item. The motivation for this behavior was to
provide a fast way to select items. However, this was counter-intuitive
and confusing for many users.
FIXED-IN: 4.13.0
REVIEW: 116469

M  +4    -5    dolphin/src/kitemviews/kitemlistcontroller.cpp
M  +7    -9    dolphin/src/views/dolphinview.cpp

http://commits.kde.org/kde-baseapps/7204392dcab240c59669dbf8046581bc8c49a8b9