1Password 4 -- very slow to present logons for a website.
I'm a professional developer and use this product like mad all day every day.
I appreciate a lot of the improvements in v4 but there's an ongoing issue with the responsiveness that wasn't there with v3. Navigating to a page, the available logons for that page aren't immediately available. It's usually because all the page's external assets like javascript etc haven't completed loading.
But this wasn't an issue with v3. As soon as the form was available, so were the logon options.
This is very frustrating, especially since this is such a constant need of mine.
I'm fairly certain this is happening both in Firefox as well as Chrome.
Comments
-
Hi @reubidium,
I do apologize for the inconvenience here. This behaviour is no different between version 3 and version 4: the webpage does need to be fully loaded for 1Password to recognize it.
However, I have a suggestion that might improve your workflow: instead of typing the web-address into your browser and then invoking 1Password to fill, you can use the 1Password Mini to open the webpage itself. Simply hit ⌘\ (or your chosen shortcut) to open the Mini and start typing the unique title of the Login you are looking for. Hit enter when it is selected and 1Password will open the page and load your credentials. :)
0 -
reubidium is completely correct. 1password 4 IS slower. used to be with 1password 3 extension you could hit command \ and 1p would recognize the website and select the correct entry. with 1p 4 if you hit command \ before a site finishes loading, it defaults to "favorites" and you have to wait for it to continue loading.
as for megan's suggestion, that requires a substantial overhaul of habits and undoing of ingrained muscle memory. Sometimes we don't remember if a site requires a password or even if it has been saved in 1password, or what we saved it AS in 1password.
1P seems unwilling to admit that the 1p4 "mini" is slower than the 1p3 extension.
0 -
1Password mini is much faster than the previous 1Password 3 extension in all of our testing since it is now native Cocoa rather than JavaScript. But we'll certainly keep an eye on this.
I agree that it shouldn't be required to change any habits, but for the life of me I've always been a ⌥⌘\ user since I have found it to be much quicker to Go & Fill all at once rather than navigate to a page and then fill it.
What I've done for years:
- Press
⌥⌘\ - Type the first characters of the Login's name to find it (optionally using up and down arrow keys)
- Press
Return
It is just as fast now as it ever was, but I understand what you mean about the list of available Logins when pressing ⌘\ before the page has loaded. It's sort of a nebulous thing since there will always be some edge cases with certain sites (just like in v3), but we're always working to improve.
What is the URL of a site where you are experiencing this?
0 - Press
-
I just tried it on three: bankofamerica.com verizonwireless.com and mint.com, all the same results.
I know from muscle memory that i would hit command \ as soon as the login fields became visible with a blinking cursor in them, and the 1p3 browser extension would select the correct entry. Now every time I do that, it only gives me the default " Favorites / Password Generator" drop down. Then I hit command \ AGAIN to deselect 1p mini, and AGAIN, and THEN finally, 1p mini shows the correct entry and website.
It's a maddening extra 3 seconds of wasted time each time.
It would also be useful of 1P admins on this site didn't always pre-emptively start their responses with some variation of "No, what you are claiming is wrong. Now that we've settled that, let's see if we can help you with your little problem"
In both responses from Megan and khad above, the first response is essentially that.
In my case, if 1P mini was indeed faster than 1p3 extension, I wouldn't have posted here in the first place. What matters here is not "your testing" but rather the customer's real world user experience. Isn't it possible that a javascript app might recognize the correct URL more quickly than your cocoa app, regardless of its "testing" speed?
0 -
My experience is that even when sticking to one particular site I sometimes hit this problem and sometimes it works fine. Perhaps the trouble is that 1PW4 is actually faster, and so sometimes tries to fill in before the page has completed loading, while 1PW3was slow enough that the page had always loaded first.
0 -
Hear, hear --- I notice this constantly. The form has completely finished loading and shows, input fields have focus and I can even type into them, but background assets are still going -- so for some reason 1Password's extensions don't have access to the page URL yet? Not sure why that should be the case.
I'm not sure why 1Password speed should impact this at all. Doesn't the extension have access to the active tab's URL, regardless of the status of the DOM tree or document assets?
Anyway, +1 for requesting a fix. This is a real usability decline in an otherwise very nice new product version.
0 -
Hi all.
I hope I'm understanding this correctly, but do let me know if I'm not.
It turns out that filling in data into webpages is very hard. There's no API or anything to call to do this automatically. So, you end up having to write your own code to do this. We inject some javascript into each page that is loaded to get username/password data (for saving) and for inserting username/password/credit card/identity information into the page.
This doesn't get loaded fully until the page is finished loading (the browser does this, not us). So, we can't fill until the page has fully loaded as our code for filling into the page is not yet there to call it and fill.
This was true in 1Password 3 as well, so nothing major has changed here.
Keep in mind that you can select an item to fill, even while it's loading and when the page is done loading it will fill for you.
I do apologize for the trouble though. It's just not something that we can get around.
0 -
This is what is so maddening about this kind of response:
It essentially says "nothing is different from 1p3" therefore you must all be mistaken. If the user experience with regards to this had not CHANGED from 1p3 to 1p4, none of us would be writing in about this, right? But clearly, SOMETHING happened, otherwise, this thread wouldn't' even exist.
If your final answer is "it's just not something that we can get around" than you are at least tacitly admitting that, as @Sharik14 says "there is a real usability decline"
If you are simply saying, "you all must be wrong," what do you want us to do, run a screencast comparison of 1p3 and 1p4 in action loading a browser?
Muscle memory does not happen by accident. It requires a repetitive, reliable rhythm of events to become ingrained. And that makes the breaking of said pattern all the more reliable as a symptom.
0 -
I just tested this in 1Password 3. I also recorded videos. Now for testing this, I setup the super slow network connection tool again because it helps show this a lot better. My normal connection loads immediately so when I request a page it is extremely hard to see this without slowing the video down. Instead I slowed my connection down which does the same thing in essence.
I am using Go & Fill here because it: 1) Loads the page 2) Auto fills immediately when it can. You'll notice that in each video both extensions do not fill until after the page is loaded. I am using the latest extension available for each
version 3.9.20 and version 4.0.1
For the network connection, I am using Apple's own Network Link Conditioner which is available for developers to test poor network conditions. Mine is set to not have any dropped packets, but have a very slow 56kbps connection both upstream and downstream. This makes loading the page very slow and you can see when the page finishes loading and then right after the auto-fill happens.
Here's the version 4 video: http://i.agilebits.com/kyle/users/redzep/SlowTwitterJSE4.mov
Here's the version 3 video: http://i.agilebits.com/kyle/users/redzep/SlowTwitterJSE3.mov
For watching the videos. I do suggest opening Quicktime Player and going to File->Open Location and pasting each in. I recorded on a retina display so it's a very large resolution video. Using Quicktime Player you can resize the window as needed, whereas Safari or your favorite web browser will not.
I hope these videos do in fact show that the two extensions behave the same. Perhaps these videos will help you realize that I am misunderstanding and you can correct me. But based on the information that has been given me this is what I am understanding your discussion to be about. If I am wrong, please correct me and I can attempt to figure out what is going on with revised information.
0 -
In addition to this, @reubidium has the question with the real answer to it.
In 1Password 3, we had the entire interface for the extension in the extension itself.
In 1Password 4, we have an extension but all it does is fill, the interface is written entirely in Cocoa. For the Cocoa app to get information it must request it from the extension, such as the URL. The Extension then sends the URL to the Cocoa app and it can figure out which logins should be displayed for that page/tab/window. The extension does this by using the same type of scripts as the filling does. So, these scripts have to be loaded in order to get the URL.
There may be a delay here as the information has to be sent to the interface side of it. This information cannot be sent until the scripts are loaded into the application. So, yes, there may be a slightly longer delay than normal. Unfortunately, there is no way around this.
Hopefully that answers both ends of the question though.
0 -
I'm not sure if anybody has this problem and after quickly browsing the forum I didn't notice it mentioned but is seems when I use my hotkey to fill logins "Command + backslash" it takes sometimes 5 seconds or more to fill a login? It never did this in the past and was virtually instant and while things still work and eventually it gets filled it kind of concerns me things are taking so long?
I upgraded to Mavericks when it came out, of course I have rebooted my machine many times since then so any suggestions to make things work as fast as they use to would be greatly appreciated.
Thanks
0 -
Hi ripper. This will be one of those replies that offers little help and more sympathy. When I upgraded to Mavericks everything in my computer, including 1Password, performed slower. I followed a number of strategies including repairing permissions 20 times, using various utilities and (for me) a new program Memory Clean. At the same time v4 of 1Password is such a bug ridden steaming pile of dung who knows what is really causing your problem. Things are better, but I really regret the upgrade (Mavericks and Password). I have had Mac since the late 80s and it used to be that system upgrades were fun and made life easier. Those days are gone. As for this little firm v3 of 1Password was solid as a rock and now I barely trust it with my absolute most important information!!! Did Agile somehow forget how important passwords are to people?
0 -
Hi, @ripper.
I've merged your topic with a similar one that started a few weeks ago which has replies from our team that include more recent ones from @AGKyle, starting at post #9 and ending just above your post.
I hope the information here will at least partly address your issue and concern. If you would like additional help looking for any more specific reasons for sluggish form filling with the 1P4 extension on your system please let us know.
One thing you could try is testing the 1P4 extension with other extensions temporarily disabled and see if there's any noticeable improvement. If doing that does make a worthwhile difference then you could reenable extensions one at a time, retesting after each is reenabled, to see if any specific one(s) that impact 1P4 most can be isolated and maybe left disabled. That's not a thorough method of testing and probably considered a workaround even if it does help. Just something to consider. :)
0 -
Megan writes:
...the webpage does need to be fully loaded for 1Password to recognize it.I have the same issue in 1PSW4 on my iPad when using the 1PSW4 browser (which I discussed in another thread). I don't understand WHY the entire web page needs to load before 1PSW recognizes it. Why can't you just grab the web address in the address bar and then quickly enable 1PSW as the page loads?
0 -
You're going to want to review my replies starting from #9 down:
The reason we cannot do what you ask is the API does not allow for this. Webpages don't provide a method for us to just fill data into them, neither do the APIs. So, we have to include some Javascript that does this for us. This code does not actually get inserted into the page until the page has fully loaded. We'd love to fill like you're asking about, but it's just technically not possible.
When it comes to the various browsers we are, in many cases, bound to the limitations of their developer kits and APIs. We're always trying to improve things to make the experience better but this particular issue isn't one we can get around I don't think.
0 -
I appreciate you taking the time to make the videos. Unfortunately, they don't prove anything precisely because you keep stubbornly refusing to acknowledge the problem described head on. For your videos, you are using "Go and Fill" which, as you say, "only fills when it can" which makes the comparison irrelevant.
The problem being described here is when you DON'T use "Go and fill," i.e. when you type in a webpage and then hit command-\ the way many of us happily used 1p3 and therefore became embedded in our instinct and muscle memory. When you want to go to a web page, it is years of habit to either
1) type in the URL
2) click on a bookmark or button"Go and Fill" requires retraining instincts, which you are basically forcing us to now do, if we want to maintain anything resembling the previous speed.
At least in your response #12 above, you are finally tacitly admitting that the travel time to Cocoa that 1p4 requires as opposed to 1p3 being an embedded extension, slows things down.
Ergo 1p4 user experience when using command - \ is slower than equivalent in 1p3. That's a serious step backwards in usability.
0 -
@redzep my second reply answers your question directly. I'm not avoiding your question or refusing to answer any of your questions. Please review here.
If you deem this a step backwards then I do apologize for the inconvenience. But technical limitations prevent us from loading the javascript before the page has finished loading. Therefore, we cannot obtain the URL for the current page without the page having been fully loaded.
1Password 3's extension had direct access to the tab's URL and so it was faster for that to do the work. The new method we use in 1Password 4 requires the javascript be loaded into the page, which requires the page to be fully loaded, because that's when the browser injects our scripts. If there were a way around this we would be happy to use it if it didn't sacrifice stability and was consistently reliable.
We'll continue to look into ways to improve it, but I think technical limitations are going to cause this one to something we cannot improve on with the new app.
0 -
Thanks to you both for taking the time to think seriously about this issue.
@AGkyle -- really appreciate your taking this seriously and taking the time to reproduce/compare and record videos.
If I understand you right -- (1) the 1Password 4 extension does have some limits and make things awkward in the way we're seeing, (2) this is a fundamental limit with the new interface.
It sounds like moving to a Cocoa-based extension, and using the provided URL as the interface, gives you less control over timing than you had w/ the "the entire interface in the extension". I'm not totally sure I understand this, but if it degrades performance -- why switch approaches and move to Cocoa? I assume this had other benefits, like making the code much simpler and easier to maintain .. but does it have other benefits from a consumer standpoint? Are there things we as users gained by this shift?
Just curious .. it sounds like this is not easily fixable and you're saying we're going to have to live w/ it. Might be helpful to know the context ..
Thanks again.
Ben.
0 -
@redzep You're welcome. Please don't assume I was avoiding your question or avoiding the answer. Merely misunderstood the question in this thread, which is why I had asked for clarification. I don't think I said it wasn't a step backwards either. I just happen to know the limitations so there's not much I can do to help here. If we could improve it we would, see the answer below for more reasons why we won't be going back to the old way though.
@sharik14 Anytime. This is a good question so hopefully I can explain.
In version 3 the entirety of the extension interface was written in Javascript, HTML and CSS. Of course, to do this and to do it quickly we had to store data both in the extension and in the application itself. So, when you added an item in version 3, it was added to a database in the extension. Then synced to the main app. This could become out of sync and you end up with data in the extension but not the app and vice versa.
Not only that, but every extension, while similar in look and feel required us often implement the same feature for each. Every web browser did things differently enough that we had to account for it in a variety of ways. This wasn't always a big deal but when you're a small team it hinders development.
In version 4, we split it. The extension basically does what it did before, filling, detection of auto-save and things like that. But the interface is completely Cocoa. This means that the interface (and much of the functionality is in one codebase). Lets put an example out there, in 4.1 we changed the auto-save dialog to allow for updating existing logins and to do it in a very graceful way (Thanks Rad!). While updating an existing login was there, the new interface was lightyears ahead of the previous one. This was made even better because we only had to do it once. One developer and a couple of hours later we had a great new auto-save and update dialog. In version 3 we would've had to account for each browser separately and it would've taken significantly longer to issue this update. What if this had a bug? Well, in version 3 we would've had to possibly fix it in 3 places. In the new one, we fix it in 1 place.
Shared preferences! Now you can turn off auto-save and it holds across browsers. Turn off filling animations and it holds across browsers. Before, we could've done this but we would've had to hold the preferences in each extension and sync it.
I think we gave some specifics somewhere but the overall size of the Safari extension went from 1.4mb down to 300k or so due to this change (approximate numbers). I'm sure it was similar for all of the other browsers as well. This includes assets (html, images, etc), word dictionary for password generation, and code.
Pros:
- Reduced code - Big win for us, but a reduction in possible bugs is a win for you
- Faster realization of features - Definite win for all of us
- More consistent interface and behavior across browsers - Win for all users
- More browsers (we now support Opera) - Win for Opera users!
- Data no longer has to sync (major win in terms of complexity, in line with Reduced Code) - Win for us and you
Cons:
- Some areas may be a little slower because the Cocoa side needs to wait for the browser to report back
- We have to issue an app update to add new features to the interface (before we just updated extension which auto-updated)
We're always looking to improve 1Password and at the moment, I think the new way we're doing things is a big win over the previous one. It allows us to be agile, just like our name implies. All of the decisions we made in this new version was to try to make your lives better. Trade offs of course have to happen. We felt that the bigger wins in the Pros category outweighed the cons.
I hope that gives some insight into why the change occurred.
0 -
@AgKyle -- terrific. Thanks so much for taking the time to write up this detailed response. I'll feel a bit better about retraining myself to pause. BTW, I had submitted a bug email and just traded a note w/ one of your support folks .. I sent him a link to this thread, and it sounded like he hadn't yet heard about this. You might share it with other support folks or on your blog, I'm sure people would appreciate it.
0 -
@sharik14 You're very welcome. I'm happy to do what I can to help explain why things are the way they are. That often makes it easier for both sides to be on the same page and then progress can be made :)
I'll do my best to pass this information along to the appropriate people.
0 -
@AGKyle - Thanks also for the detailed explanation. I think "SOME areas MAY be a LITTLE slower" is disingenuous spinning at its worst. A more honest response would have been:
"the functionality used 95% of the time by most users (command /)" IS slower"
I am sure the Pros outweigh the Cons for you guys as developers, which is of course your right, but from the one HUGE con of 3x slower user experience far outweighs the pros. FWIW sync was never an issue with 1p3 for me, so the "benefits" are lost on me.
@sharik14 - i guess i am grumpier about having to "Retrain" myself to WAIT for the new 1p4 (more stable! slower!)
I find myself basically now hitting Command \ THREE TIMES. Once to turn it on (and see that the proper entry hasn't been selected), Once to turn it off in frustration, and Once again to turn it on now that the app has caught up with the browser.
0 -
@redzep -- yeah, I get it. Don't get me wrong, it's still driving me crazy, and feels flaky.
I think the product would be much better if the developers added a workaround to this problem. For example, I could see having a browser-specific, JavaScript-based shim -- to prenotify the Cocoa code when a form was ready. It would be less burdensome than maintaining the entire plugin/filler in JS/CSS/HTML, but it would make the system more reliable and responsive.
0 -
I have a feeling that there may not be anything I can say that will help right now, but without future updates to improve 1Password one thing you can actually do right now is to use Go & Fill.
- Press ⌥⌘\ (or whatever you have customized the "Show 1Password mini" shortcut to be)
- Enter the first few letters of the Login (and optionally use the arrow keys if you want to move up and down in the list as it narrows down the selection based on what you type)
- Press Return.
Then 1Password will "Go" to the login page and automatically "Fill" the Login without any further interaction from you. You don't have to wait for any page to load since 1Password will do the filling (and waiting) for you.
I hope that helps. We'll see what can be done in the future to keep improving the workflow of both "Fill Login on current page" and what we call "Go & Fill".
Thanks again for all your feedback on this! It really helps us to know folks' perceptions of the app and their different workflows. For perhaps obvious reasons we don't track any 1Password usage, so feedback like this is essential.
If there is anything else we can help with. Please let us know.
Cheers!
0 -
The problem is for us early adopters, we developed our habits of working with 1p BEFORE "Go and Fill" even existed... but I surrender.
0 -
Go & Fill has been available for at least 4 years or longer. It's been at least since 1Password 3, and I think it was even in 1Password 2.
But no one is trying to argue with you. If it helps you now that is a win. :)
If not, we'll just keep improving 1Password in this and other areas for you.
0
