Closed garvankeeley closed 6 years ago
Hi @garvankeeley
Thanks for sending us this report. I'm seeing the same behavior but was unable to figure out why this is failing to work correctly. We're still investigating and have filed rdar://34417922.
Is there anything that you've come up with that makes you think this is an issue on our side? I'm pretty puzzled about what we'd be doing that would make the Add to Notes part completely break everything like it does.
Agreed it looks like a bug on Apple's side. Is there a possibility the extension could be changed to respond to 'public.url' instead of (or in addition to) 'org.appextension.fill-browser-action'? Not being a fix, just a workaround of course.
Hi @garvankeeley
We don't want to switch it to public.url because that would put us in places where we would simply not handle the result properly. Click a link in a Twitter client? It would want us to handle that link in some way, like opening it, or sharing it, or something.
With the "org.appextension.fill-browser-action" we know exactly what is being requested of us by the host app, it wants us to fill into the browser window. So one is very generic and just describes the type of data we need to act on, the other gives us the context we need to actually do something really constructive with that data.
We're still investigating though, hopefully I'll have something more for you soon... but, as you can imagine we're also at the mercy of others in some respects on this one :)
@gks we would also be interested in a short term workaround - if possible, i know that is pretty unclear right now.
What is the current thinking? Is this a bug in iOS 11 or is this simply a change of behavior? If the latter, is it document anywhere?
Hi @st3fan
We believe this is a bug in iOS 11. I've reported it via rdar and am awaiting some feedback from Apple whether my suspicions are correct. We really hope to see a resolution soon but obviously that's outside of our control as you can imagine.
If you'd like to have a conversation on this I'd certainly be open to it. You can email me at support+appex@agilebits.com and I'll see if I can't get some additional information for you.
The 1password app extension works in chrome for ios. Unfortunately it’s code is not open source, so I can’t see how it is doing it. Is there another way to integrate with 1password? (Possibly the way that chrome is doing it?)
Or Chrome is still linked against the iOS 10 SDK, which may have different behaviour.
Their code is at https://chromium.googlesource.com/chromium/src.git/+/master/ios/ - let's take a peek and see what they are doing.
@st3fan
Chrome does not use our filling mechanisms. I believe, correct me if I'm wrong, that you all at Firefox are relying on our code to do all the filling into the page. Chrome acts as an "app" in this case, and it requests login items that pertain to the current webpage in the browser. Once the user taps on an item to choose it, that results in the username and password being sent to Chrome, which then handles filling into the page.
We generally do not recommend this as it results in different filling behavior across apps and browsers. The methods that Chrome is using is more specifically for apps who have native login solutions. The methods you are using are meant more for web browser windows, like those that Firefox and Safari are using. This results in the same behavior across each browser and if a login item fails to fill we know immediately that it is our fault.
In the case of Chrome though, we have to direct users to Chrome to fix any filling issues, and if you also implemented your own filling system we'd have to do the same. It really fragments the filling features and adds more work to your plate. We're already doing this work for you.
So I would not recommend following Chrome's lead here unless you want to make more work for yourselves...
I was able to fix this using
func activityViewController(_ activityViewController: UIActivityViewController, dataTypeIdentifierForActivityType activityType: UIActivityType?)
if let type = activityType, isPasswordManagerActivityType(type.rawValue) {
return "org.appextension.fill-browser-action"
}
return activityType == nil ? "org.appextension.fill-browser-action" : kUTTypeURL as String
My understanding of this is that public.url
must be passed to Apple apps (notes). So if the activityType is not a passwordManager type then simply return public.url
I seen this! That is amazingly straight forward.
Is there any chance I can get a test build or beta or something of this to help just double check things are working? If I can do anything to help you please let me know.
Sent a build to kyle @ company and support just in case you didnt get it 😄
As i said in the email, and just to complete the chain here. The fix appears to work fine for me. I ran into one minor snag but it was actually unrelated to 1Password. I'll be using this build for the next few days at least to give it a real stress test as well. I'm going to close this down here as it appears fixed but I'll be in touch if I find anything along the way.
Thank you again for your hard work and dedication in getting this fixed. I'll have to see what kind of things we need to update in our sample application to make this work as well. We may need to update our instructions as a result of this.
If you need anything from me, just reach out here or in email and I'll get whatever I can to help.
The UTI type org.appextension.fill-browser-action won't support other types of extensions in the same share sheet, they won't share the URL as expected. Even stranger, if you tap iOS "Notes" app the app will hang completely. In our app (Firefox iOS), we found that changing the UTI type to 'public.url' will work for all extensions (and LastPass extension oddly) but 1PW will no longer show in the action sheet.
( Firefox iOS bug for my reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1394786 )