1Pmini sometimes doesn't select the first item on open

lumarel

Hey,
I have another question about a detail for you :chuffed:

I discovered a not really good reproducible misbehavior at the moment of opening the unlocked 1Pmini:
For some sites I have multiple items and so they are also all of them shown as I open the window in the browser, this looks like that:

Sometimes not the first item is selected but the second one.
This leads to the problem if I assume the first item is always selected and then hit enter to fill in the creds, from this sometimes the wrong one is used.

So my question is, is my assumption that the first item is always selected wrong or is there an issue? :unamused:

~lumarel

---

1Password Version: 7.3.684
Extension Version: 4.7.3.1
OS Version: Windows 10 1809 17763.437
Sync Type: Dropbox

bundtkate

I did some digging around to see if I could determine the intended behavior here, @lumarel, but it doesn't look like it's something we have documented. I'm admittedly a bit awful at searching our spec documentation, though, so I've asked the development team just to be sure. Regardless, I instinctively agree with you that the top item in the list should be selected consistently. Could you clarify the conditions under which you see this? Is it only right after unlocking that you'll see the second option selected, or does this happen when invoking the extension while it's already unlocked as well? What about the number of exact matches as shown in your screenshot – does this only happen when more than one Login is an exact match for the domain? Finally, do you find this is triggered only when you invoke the extension in a particular manner? That is to say, can this happen both when you click the 1Password icon in your toolbar, or does it pop up when using Ctrl + \ as well? Thanks! :chuffed:

lumarel

Hey @bundtkate,
Thank you for your effort :chuffed:
Ok I will look into all different scenarios and then report back ;)

AGAlumB

@lumarel: I have noticed this, but only in the context of 1Password (rightly) selecting one Login over (an)other(s) because its URL is an exact match for the subdomain. Is that maybe what's throwing you off? Items should be listed alphabetically, but when filling (which is the purpose of Ctrl \ ), 1Password should prefer the exact match for the current subdomain over other Logins matching only the domain. Let me know if that helps.

lumarel

So... I tried some different scenarios, for now it looks like as if it only happens with an unlock in the 1Pmini window, but I'm not completely sure (as of the unlocked state). But this is the only scenario where I could trigger it today more than once.

And yes I can confirm it only happens if there are more than one exact matches @bundtkate :unamused:
Further, there is no difference between clicking the extension-button in the browser window and using the filling-shortcut, in both cases it sometimes occurs to select the second item instead of the first one.

I also checked the console if I see anything interesting there, but on the unlock I only see the action from the browser '-> showPopup' or the action from the shortcut '<- getActiveURL' + '-> activeURL'. And off course the 3 backups of my 3 vaults on the unlock.

To answer your question @brenty, these are the two items (there isn't really any secret data so I can show them):


The interesting website-entries are the ones with the IP-address 10.0.0.215/ui, so as you can see also the URIs are the same ones (okay the location post is a difference but always in the URI) and if 1P cares of the order also the administrator item should be selected first..

Maybe it's about which item is first or latest available for 1P but I'm not sure, so to check this I exported the two items and the 'nauser' has the lower uuid number. I don't know if this makes any sense, but in my understanding 1P checks one band after another so the 6th band (in which the nauser is) is loaded before the other one and so it is not able to select the admin because it isn't ready until then :unamused:

But for now, happy easter! :chuffed:

lumarel

[update] It also happens with the exact same URIs :+1:

AGAlumB

@lumarel: The Windows app currently supports fully qualified domain names. I think that's where you're running into trouble. Are you also having this issue when using actual domain names, or just when there is an internal IP address involved?

ref: opw/opw#2072

lumarel

Hm, let me test this... @brenty

Ok I have found some items which use the exact same URIs for the external website (in this case a1.net and e-tec.at, but that should actually be irrelevant). In this cases I could reproduce it at any time up to now:
At the locked -> unlocked state always the second item gets selected (even if there are 3 items), but as I only tested 2 websites it could also look different.
At the already unlocked state it selects the first item.
One other thing to note is, if the 1Pmini page doesn't get refreshed (the 1st item is already selected before locking and it already shows the state/page which is shown after the unlock) the 1st item is selected.

So, here is the exact process for the a1.net-page:
1. Refreshed the 1Pmini with another page to force a refresh
2. Now the 1Pmini looks like that:

3. After this I refreshed the 1Pmini with another page and locked it
4. Then I went back to the testpage and unlocked the 1Pmini there, this looked then like this:

for the sake of completeness... this disproves my thought about the bands, the second one is not the one with the second highest/highest uuid.

bundtkate

I wonder if this might be an issue of attempting to direct focus and having it not quite work the same under certain circumstances. @lumarel, if you recreate the two scenarios above, are you able to type in the search field right away in one or both cases? I'd need to check with our development team to determine exactly what happens under the hood to put focus where we want it when you open mini, but I know that process of focusing the right field is a struggle on Windows and I'd not be surprised if we've made some efforts to improve focus that have had some collateral impacts on selected item.

lumarel

Hm... the pointer focus for writing is in both cases in the searchbox :+1:
But only in the case with the wrong selection I'm always able to write as well, with the correct selection only sometimes, looks like Windows/Firefox (in that case) already stole the actual focus back sometimes 8-)
Yeah, Windows and its focusing problems, a never ending story ^^

AGAlumB

Ah gotcha. Yeah that makes sense, in a way. Indeed, it's been an ongoing struggle. I think that it's good on the one hand that Windows tries to not let "background" apps steal focus from the foreground app in general, but 1Password is a bit of an odd case since, technically you're using the browser, but then you want 1Password mini to come up. We'll continue to work to see if we can find a good solution though. Cheers! :)

lumarel

Ok great :+1:

Cheers! :chuffed:

Greg

@lumarel: I am glad to hear that Brenty and Kate helped. :chuffed: :+1: We have no intention to stop making 1Password for Windows better, so please stay tuned for future updates.

Let us know if there is anything else that we can help you with. Thanks!

++
Greg

lumarel

Hey @Greg
That's always great to hear and I'm completely sure you mean that by heart :chuffed:
Off course I will stress all later builds of 1P as well and report back :+1:

As always thank you for your hard work!

AGAlumB

Likewise, thanks for your passion, and for participating in the beta! :chuffed:

lumarel

Looks like the insane performance or a fix of 7.4 resolved this problem, thank you very much :chuffed:

MikeT

Awesome, I'm glad to hear that! There are so many changes that I don't know which could've fixed this one.

Thanks for letting us know.