I made a similar bug report 3 years ago:
https://bugs.kde.org/show_bug.cgi?id=454523
Hopefully someone has time to fix it.

(In reply to John from comment #1)
> I made a similar bug report 3 years ago:
> https://bugs.kde.org/show_bug.cgi?id=454523

I think this is just the same issue (I can't see a meaningful difference) so I'm marking this as a duplicate.

In principle this should be trivial to fix, but with such cases where the currentIndex is set on hover there's the chance of things breaking. I'll put it on my todo list to investigate here.

*** This bug has been marked as a duplicate of bug 454523 ***

(In reply to cwo from comment #2)
> (In reply to John from comment #1)
> > I made a similar bug report 3 years ago:
> > https://bugs.kde.org/show_bug.cgi?id=454523
> 
> I think this is just the same issue (I can't see a meaningful difference) so
> I'm marking this as a duplicate.
> 
> In principle this should be trivial to fix, but with such cases where the
> currentIndex is set on hover there's the chance of things breaking. I'll put
> it on my todo list to investigate here.
> 
> *** This bug has been marked as a duplicate of bug 454523 ***

Well I think you're were right into making this a duplicate of the other bug (which I've set as confirmed now).
Maybe also that's why nobody looked into it as it stayed only reported until now.

As for the currentIndex, I have no idea as I have no experience with Qt or KDE software, just a bit with web development.

But from what I've seen, web browser don't have such problem when they are multiple input input fields (text fields or not), like in a web form, but it's probably also because they don't do anything just on hover.

I'm thinking that Qt or KDE Frameworks, if it's involved here, should have an option that when an input field is focused and not only focused by hover, but focused level 2, by being clicked or  by pressing Enter (if the "hovering" was done by keyboard navigation) to not lose focus that is needed for input:

Let me rephrase that, maybe it's easier to understand:

Focus level 1, can be done by:
-Hovering with the mouse
-Up and down arrows of the keyboard

Focus level 2, can be done by:
-Clicking with the mouse
-Pressing Enter with the keyboard

Once a field gets focus level 2, which is used for typing, then no matter if the user continues co move the mouse or press the up and down keys of the keyboard, the field that has focus 2 level should continue to be focused for input.

Until another field that is having focus level one by the mouse hover or keyboard up / down arrows gets a click or an Enter which turns that field in focus level 2.

If no other field is getting a click or an Enter, but we still want to escape the focus level 2 of the first field, I think a click on the Desktop or pressing ESC on the keyboard should do it.

I'm not sure if this is such a good logic, if it makes any sense or it's even possible with Qt and other already existing KDE software, but If I were a developer this is how I would try to fix it first.

Thanks a lot for putting it on your TODO list, we appreciate it!

It's not a problem to have the highlight separate from input focus in principle (and probably not that hard to implement). And we'd still want the highlight to work as it does now, just not to take focus away from the input field. The problem is that other code may rely on the assumption that the hovered item is also the one that is selected in the listview, so it would need careful checking that nothing else breaks if that assumption is violated. We would also want it to (effectively) take focus some of the time, e.g. if the user opens the dialog, hovers over the third item, then presses the arrow key down on their keyboard, we'd want the fourth item to be selected, not the first one.

(In reply to John from comment #3)
> Once a field gets focus level 2, which is used for typing, then no matter if
> the user continues co move the mouse or press the up and down keys of the
> keyboard, the field that has focus 2 level should continue to be focused for
> input.

FWIW, I disagree on this - if the user presses the up or down keys, it should move to the previous or next items. That's what those arrow keys do, and the user pressing them is in my opinion a clear statement that they want this to happen. Having it be modal in the way you suggest would only make sense to me if it would actually open a separate dialog-type interface, where pressing escape to close is natural. Otherwise, escape should close the primary dialog (i.e. the networks popup)

(In reply to cwo from comment #5)
> (In reply to John from comment #3)
> > Once a field gets focus level 2, which is used for typing, then no matter if
> > the user continues co move the mouse or press the up and down keys of the
> > keyboard, the field that has focus 2 level should continue to be focused for
> > input.
> 
> FWIW, I disagree on this - if the user presses the up or down keys, it
> should move to the previous or next items. That's what those arrow keys do,
> and the user pressing them is in my opinion a clear statement that they want
> this to happen. Having it be modal in the way you suggest would only make
> sense to me if it would actually open a separate dialog-type interface,
> where pressing escape to close is natural. Otherwise, escape should close
> the primary dialog (i.e. the networks popup)

I think I'm not that good at explaining things.
I agree that if the user presses the up / down keys after selecting a network and clicking / pressing Enter (to enter its password), the selection focus (highlighted  rectangle) should move.

What I'm trying to say is that unless the user also clicks or presses enter on some other network, that was highlighted with its up / down key presses, the first network that has the click or the Enter pressed and its password field input opened (so it's now in a waiting for password state) should still get all the typed characters as there's none other network in a waiting for the password to be typed state.

I just deleted my saved network (which I will call "My-network") to do a test (as if it were the first time) like this:
1. Opened the networks widget and moved the in the network list until "My-network" was selected.
2. Pressed Enter which showed the 'Password' input field,  which became clearly focused as there was the blinking cursor waiting to type the password of the network.
3. Didn't type anything and pressed 'Down arrow' which moved the selection to the next network below.
4. Tried to type the password for "My-network" even though I was not there anymore (but one network down), though the password input field for "My-network" was still open and should have still received whatever I typed.
The typed characters were not going anywhere else anyway, so they were just ignored.

So the test failed!
Going back up one network, by pressing the "Up" arrow, so exactly on "My-network" also failed to regain focus and let me type the password!
Pressing Enter while exactly on "My-network" also failed to regain focus and let me type the password!

I also closed the networks widget and did another test like this:
1. Opened the networks widget and moved the in the network list until "My-network" was selected.
2. Pressed Enter.
3. Pressed the "Down" arrow key to be on the next network.
4. Pressed Enter.
5. Pressed the "Down" arrow key to be on the next network.
6. Pressed Enter.

This show another strange thing with multiple password input fields being shown, which in theory with only mouse hovering and focus could've work, but with keyboard navigation only one password field show by shown after Enter was pressed and that should have focus for input.

If the user continues to press up or down arrows then the selection / highlight rectangle should of course move up or down as the user requested but when it presses Enter, then any previous password input field should disappear losing its focus of course and the new one should be opened gaining focus.
I'm not sure I've explained it better this time, but a few quick test should reveal the problem(s) and hopefully what it should be done.

I did consider just forwarding all keys to the entry field (or the last active one in case multiple password entry fields are open for some reason), but there is a rather severe issue with this in my opinion: while we could forward characters, we can't really forward the final enter to confirm it as we don't know whether the user intended to send enter on the password entry field or on the newly selected item. If we forward it, allowing the user to arrow up/down after opening a password field is pointless and confusing, they can arrow to another entry but they can't actually do anything useful there. So it would be hard to recover from selecting the wrong network to show the password entry field. And if we don't forward it, the user can type the password into the field from elsewhere, but they can't actually connect without moving the focus back, so the forwarding seems rather pointless.

(This doesn't apply to your case of the user arrowing back to the entry with the open password field, I fully agree that then the user should be immediately able to type, though I'm not sure at the moment whether the best solution is to forward character key presses or just moving the keyboard focus to the entry field when the list entry with the password field becomes selected).

Anyway, I started looking into this. In principle it's not that hard, but in practice it's quite a challenge and requires some work in the underlying Plasma components and thinking and quite likely lots of other applets that should be adjusted for consistency to any changes we make here.

One of the main issues is that we need to separate keyboard-focus state from mouse hovered state. That's not all that difficult, but both can be active at the same time - if the user hovers over an entry and uses the arrow keys to move to a different entry, both need to be highlighted so that both mouse and keyboard use work properly. But they can't have the same type of highlight, or it'll be confusing which is which. We do have two different kinds of highlight (see for example in the Folder View panel widget, or outside Plasma in e.g. the sidebar in Discover. But the component we use in the Network widget does not really support this and needs to be adjusted for this, and it also looks somewhat unpleasant on the large list entries that we have there. So there's quite a bit of implementation work to be done here, and ideally we can work out a way that can be consistent with other widgets that use this component so that they all look and work the same even if the input issue isn't really relevant there. And probably also adjust the other components that use different components to also work the same way (e.g. the Kate sessions widget).

So we've gone from  "fix a small focus issue" to "redesign widget interaction in Plasma and implement it across everything". I do think that this is a worthwhile thing to attempt (also for increasing consistency and making the general experience better), but it's a large undertaking and will likely take a while, and no promises.

(In reply to cwo from comment #7)
> I did consider just forwarding all keys to the entry field (or the last
> active one in case multiple password entry fields are open for some reason),
> but there is a rather severe issue with this in my opinion: while we could
> forward characters, we can't really forward the final enter to confirm it as
> we don't know whether the user intended to send enter on the password entry
> field or on the newly selected item. If we forward it, allowing the user to
> arrow up/down after opening a password field is pointless and confusing,
> they can arrow to another entry but they can't actually do anything useful
> there. So it would be hard to recover from selecting the wrong network to
> show the password entry field. And if we don't forward it, the user can type
> the password into the field from elsewhere, but they can't actually connect
> without moving the focus back, so the forwarding seems rather pointless.

Oh, I see, I haven't thought about the problem of pressing Enter while the selection is on another item.
As is indeed confusing about what the user wants in that case.
But maybe we could infer what it want based on the status of the first password input field opened.
1. I mean, did the user typed anything there before moving to other network?
If not, he probably realized it pressed Enter on the wrong network and moved on to the correct one / the one that he really wants to connect to, so pressing enter should not be forwarded but instead open the password input field at the newly selected network.
2. Did the user typed some characters, but less the minimum 8 that are required for Wi-Fi passwords?
In that case pressing Enter to send them is useless as they will be rejected, so in this case too open the password input field of the newly selected network.
3. Did the user typed the minimum 8 characters before pressing enter?
I think it's would be really weird and uncommon for someone to move to another network and type the full 8 characters before pressing enter if he wanted to connect to another network.

> (This doesn't apply to your case of the user arrowing back to the entry with
> the open password field, I fully agree that then the user should be
> immediately able to type, though I'm not sure at the moment whether the best
> solution is to forward character key presses or just moving the keyboard
> focus to the entry field when the list entry with the password field becomes
> selected).
I'm not sure either and I'm just throwing some idea around with the hope that maybe some of them are good and make sense to you or somebody else.
Unfortunately I don't have a Windows VM anymore to see how they did it and even if I did, I'm not sure it would've showed any wireless networks as it got some virtual wired connection.
And I don't remember either how it was in Windows 7 that I used for many years, but I think there a small pop-up window with only the password input field and maybe an OK button appeared that had all the focus.
So you had to type the password and press Enter or click OK or you had to close it to get back to the networks.

> Anyway, I started looking into this. In principle it's not that hard, but in
> practice it's quite a challenge and requires some work in the underlying
> Plasma components and thinking and quite likely lots of other applets that
> should be adjusted for consistency to any changes we make here.
I'm glad that you started looking into this pretty old problem, but I'm sorry that it's that hard!

> One of the main issues is that we need to separate keyboard-focus state from
> mouse hovered state. That's not all that difficult, but both can be active
> at the same time - if the user hovers over an entry and uses the arrow keys
> to move to a different entry, both need to be highlighted so that both mouse
> and keyboard use work properly. But they can't have the same type of
> highlight, or it'll be confusing which is which. We do have two different
> kinds of highlight (see for example in the Folder View panel widget, or
> outside Plasma in e.g. the sidebar in Discover. But the component we use in
> the Network widget does not really support this and needs to be adjusted for
> this, and it also looks somewhat unpleasant on the large list entries that
> we have there. So there's quite a bit of implementation work to be done
> here, and ideally we can work out a way that can be consistent with other
> widgets that use this component so that they all look and work the same even
> if the input issue isn't really relevant there. And probably also adjust the
> other components that use different components to also work the same way
> (e.g. the Kate sessions widget).
I understand and I feel sad to hear that providing the ease of use  features (mouse hover) visual cues (higlighting items or buttons on them) and accessibility features (both mouse and keyboard navigation) are like a burden, hard to implement and maintain.

> So we've gone from  "fix a small focus issue" to "redesign widget
> interaction in Plasma and implement it across everything". I do think that
> this is a worthwhile thing to attempt (also for increasing consistency and
> making the general experience better), but it's a large undertaking and will
> likely take a while, and no promises.
I wish it didn't lead to this, but I think that's because this is probably the most complicated list of items that appears anywhere in Plasma, at least from what comes to my mind right now.
I don't know any other where items have two type of actions, like here:
-Show network properties
-Show password input field

And they differ a bit by with what physical device they are done with (mouse or keyboard):
Left click on the left side (on network name): Show network properties
Left click on the right side (on "Connect button): Show password input field
Right click on whatever side: Not used for anything / Not available
-------------------------------------------------------------------------
Enter on both sides (? whole row ?): Show password input field
Right-arrow (making Connect button highlighted) + Enter: Show password input field

Besides all the back-end / components complications in the code that you and other developers know better, I think there might be a bit of a problem with the logic / behavior / consistency too.

It's strange that I cannot replicate with the keyboard the same behavior that I can do with the mouse.
I mean left clicking with the mouse on the left side (network) name shows the network properties, which is great and probably what Windows does too.
But if I want to do the same thing with the keyboard I can't as it will jump straight into the connection mode by opening the password input field, which I didn't explicitly asked for.
If I wanted that I would've gone with they keyboard right-arrow once, until the "Connect" button was highlighted and then pressed Enter.
There's not way to specify with the keyboard that I want to highlight the left column / side (the network name) and press Enter because I want to just see the network's properties and not to connect to it.

Also one unexpected or unwanted behavior is this:
Move up or down with the keyboard's arrow keys.
Stop at some network and press Enter
The password input field opens (the current behavior)

Let's say I did a mistake, I don't want to connect to this password.
My expectation is that even with the wrong behavior of showing the password input field instead of the network properties, if I press Enter again the password input field should close, so Enter should be like a toggle to open close the password input field or if the network properties were shown, then those.
I tried after that with the ESC button and that, which is harder and more time wasting than just pressing Enter again.
I'm was thinking that Enter should work as a toggle because sending an empty password to a secure network it will not work anyway so it would be better to act as a toggle.

In my opinion if I were to work on this I would probably start to break the problem in multiple smaller ones like:
1. Make keyboard navigation consistent with the mouse hover and clicks.
While pressing the keyboard's up or down keys I would keep the whole row highlight but inside I would highlight the left side (network's name)
A. If the user presses Enter then the network properties should be shown
B. If the user wants to connect to the network, then it should press the right-arrow to highlight the right side (hence the connect button) and then press Enter.
-----------------------------------------------------
* With this case, the default highlight inside the row highlight being the left side (network name) and pressing Enter meaning just showing the network properties the use can move up and down and press Enter as long as it wants as it will just see the properties of each network and it's not problem with some password input being left behind, waiting for some input. Of course close the network properties of the last network and enter was pressed on another as the widget is not so tall by default and because of that it has limited vertical space.

* Now with the case of highlighting a network, then highlighting  its Connect button and press Enter, which should then open its password input field...
A. If the user presses the up or down arrow, consider that it has made a mistake (as it's pretty hard to press the up or down arrow by mistake), choosing the wrong network and wants to choose now the right network to do one of the two actions (show network properties or show password input), so I would close the password input field losing also its focus as a pressed Enter after the selection was moved with the arrow would be confusing.

B. If the user moves the mouse over the other networks, unless it clicks on the left side to show network properties or on the right side (Connect button) to show the password input field, IGNORE IT (and forward Enter to the open password input), assuming that the movement is was a mistake letting the mouse free with the hand so it could move the hand to the keyboard to type the password and accept and forward mouse to the open password input field and not towards whatever the moues cursor is hovering now.
When I opened the other bug report, this was the use case that I had, using the laptop and the wireless mouse in bed and as soon as I moved my hand from it to the keyboard to type my wireless network password and press Enter, the mouse moved a bit, maybe because the bed shook  a bit too from my typing movements or moving my feet.
This is the exception that I would do, just for the mouse hover, while a password input field is open and waiting for a password to be typed and Enter to be pressed.

I understand that whoever made "Press Enter" to show password input field (same as highlighting the Connect button and then press Enter) was probably thinking to make it as easy as possible and it is pretty easy, but it breaks the consistency with the mouse click on network's name (that shows the properties) and maybe it's why this got so complicated and hard to fix.
So at least I, while navigating with the keyboard, be willing to have to press the extra right-arrow before pressing Enter to show the password input field, if it helps in any way to solve this problem or at least be able to show the network's properties by keyboard too.

(In reply to John from comment #8)
> Oh, I see, I haven't thought about the problem of pressing Enter while the
> selection is on another item.
> As is indeed confusing about what the user wants in that case.
> But maybe we could infer what it want based on the status of the first
> password input field opened.

Yes, such a thing would be possible. But I think it's probably better to avoid complicated logic here; it might mean the user sometimes has to press an additional arrow key if they moved away from the entry for a network, but things work in a transparent way rather than the user having to guess what we're guessing what they think. It's likely an edge case anyway. We can also revisit this later when the other things are done and it turns out to be a real problem.
 
> I understand and I feel sad to hear that providing the ease of use  features
> (mouse hover) visual cues (higlighting items or buttons on them) and
> accessibility features (both mouse and keyboard navigation) are like a
> burden, hard to implement and maintain.

I think once everything is conceptually sorted out it shouldn't be hard to maintain. The problem is lots of things using the components differently and ending up with subtle (and sometimes not so subtle) differences in behavior. Sometimes this may even be a good idea. 
 
> It's strange that I cannot replicate with the keyboard the same behavior
> that I can do with the mouse.

FWIW, our default key for "do the same thing as clicking" is Space, which we largely inherit from Qt - Enter/Return we usually have to add explicit handlers for, and if we do it doesn't always do the same thing as clicking/space. For example, in a Dialog, Enter often means "use the Accept-equivalent dialog button, like OK, Save, Open etc.". If there's also something that can be clicked in the dialog, you activate it by pressing Space. And that works in the Network list to show the connection information.

(Except in menus where space doesn't work, only Enter... no idea why this is the case, but it seems to be rather consistent in our apps across both Kirigami and QWidgets).

I did think a bit about the issue you're raising as well. Sometimes having minor differences between the mouse and keyboard interaction patterns are justiied, and I think this is one of them. First, it's convenient (as you point out) in the default case. It's also something that I think makes the interacton clearer for screen reader users who can't see the extra button. Using enter to confirm (in this case to begin connecting) is rather natural, and we can even have the screen reader read out "Press Return to Connect" or similar. "The connect button is to the right" feels like an awkward announcement.

> Let's say I did a mistake, I don't want to connect to this password.
> My expectation is that even with the wrong behavior of showing the password
> input field instead of the network properties, if I press Enter again the
> password input field should close, so Enter should be like a toggle to open
> close the password input field or if the network properties were shown, then
> those.

Maybe, but you can also just not close it and move away again and that always works. If the user notices they're on the wrong network and they've already started typing, we can't have enter close the field as it would conflict with confirming the password and attempting to connect.

We could do it if the entry field is empty, but I'd wait and see if this is actually an issue in practice.

> I understand that whoever made "Press Enter" to show password input field
> (same as highlighting the Connect button and then press Enter) was probably
> thinking to make it as easy as possible and it is pretty easy, but it breaks
> the consistency with the mouse click on network's name (that shows the
> properties) and maybe it's why this got so complicated and hard to fix.

No, all the technical and consistency problems are still there without it I think.