iOS 8 extension: fillLoginIntoWebView inserts „(null)"

aclauss

I’m just playing with the new 1Password iOS 8 extension (1Password 4.6b8) to add support for it in my own App („iCab Mobile“, a web browser).

I’ve noticed the following issue:
I’m using the „fillLoginIntoWebView:forViewController:completion:“ method on a WKWebView or UIWebView and select a login item in 1Password which only provides a password but no user name. In this case 1Password inserts „(null)" in the user name field on the web site. I guess this happens because of a null pointer for the user name item, and this should be better replaced by an empty string.
BTW: when trying this in Safari, I do not get „(null)“ inserted.

And I would like to have a counterpart for the „fillLoginIntoWebView:forViewController:completion:“ method as well. A method which passes a UIWebView or WKWebView to the 1Password extension, which is then either getting the login name and password from the web view or only getting the user name and lets the user generate a secure password for this page. This way users can not only fill out login forms in web views, but can also save login forms from web views from within other Apps.

I guess I can use the „findLoginForURLString:“ and „storeLoginForURLString:“ methods to implement something like this myself. But I think it would be great to have a direct counterpart for the "fillLoginIntoWebView:“ as well.

roustem

Thank you for reporting this issue, Alexander! We'll make sure it is fixed in the next update.

I agree that it would be great to have the methods to make saving new Logins easier. We will try to make them available.

We love iCab!

dteare

It's great to hear from you, @aclauss‌! I'm a big iCab user and am so happy to hear you are playing with the 1Password App Extension! I was thinking about you and our previous conversations while working on this new app extension :)

I'm sorry about the null bug; that's my issue. Long story short, I needed to rely on a very simple fill algorithm in the beta so we could ship. I'll be replacing it in the coming weeks with a much more sophisticated filling algorithm. I can certainly fix the null thing faster and I will, but I wanted to explain that you'll likely encounter filling issues in the short-term.

I really like your idea to allow saving logins from within the web view. This would be a great feature to add, and I'll do my best to add it. There's several dependencies that need to be addressed first, but it is a feature we'd love to add.

Please let us know if there is anything else we can help with.

Cheers!

aclauss

No need to be sorry. I know this is a beta with some great brand new features, so bugs are „expected“. And my test case is even a very unusual one (having a password but no corresponding user name), so it’s unlikely to happen in a real world scenario very often. I’m confident that you will fix this, so this is nothing I worry about ;-)

Much more interesting (for me) would be the „save login from web views“ addition.
Do you think this can make it into the first public release of the new 1Password App for iOS 8? Or should I better try to use "findLoginForURLString:“ and „storeLoginForURLString:“ to implement a similar feature (I do have my own form fill out methods already, so I do have methods to scan forms for name/password and fill them out)?
I this case I’d appreciate a hint about how to create the „URLString“ parameter when saving name/password of a login form so it works best for a general web browser and so that the password can be used by other Apps as well (using the iOS 8 extension). Or in other words: how does 1Password match the URLs when searching for passwords. Should I simply strip the query part of the web page URL? How to deal with URLs which have some kind of „Session ID“ as part of the URL path (like the amazon page)? Or is 1Password mainly interested in the domain?
If you think that the "save login from web views“ addition will be available in the public release from the beginning, those questions would not be relevant. Then I would simply wait until you add the "save login from web views“ method into your API, which then would be responsible to determine the correct way to remember the URLString so it works best in all cases.

Anyway, thanks for the new API for iOS 8, I love it :-)

dteare

Thanks @aclauss‌. You're right, I shouldn't be sorry about a bug in a beta, but I'm a perfectionist, plus I'm Canadian, so it's nearly impossible not to be sorry about this. I'm sorry about that ;)

Regarding the upcoming saveLoginWithinWebView:forViewController:completion: action, I really want this to be part of the initial release. Not only is it a great feature for the app extension, my planned new implementation promises to fix several tough issues that we've struggled with over the years. I would classify this as a high priority and therefore hope it will be done before Apple ships iOS 8. With that said, I'm hesitant to promise this as it is August already (can you believe that?!) and we have no idea if Apple will ship earlier than previous years.

Given you already have code that collects username and passwords, it should be relatively simple to use your existing code to collect the data and then pass it into storeLoginForURLString. The URLString we're expecting you to provide for the new login is the full URL used by the web view, including the query string. While 1Password is primarily interested in the top level domain, there are several special cases where the remainder of the URL is taken into consideration, so we need the entire URL.

thanks for the new API for iOS 8, I love it

This is music to my ears! Thank you for singing such a lovely tune :)