Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebView Demo fatal hang on iOS 11 (org.appextension.fill-browser-action bug) #385

Closed
garvankeeley opened this issue Sep 13, 2017 · 13 comments

Comments

@garvankeeley
Copy link

garvankeeley commented Sep 13, 2017

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 )

@gks
Copy link
Contributor

gks commented Sep 22, 2017

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.

@garvankeeley
Copy link
Author

garvankeeley commented Sep 22, 2017

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.

@gks
Copy link
Contributor

gks commented Sep 25, 2017

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 :)

@st3fan
Copy link

st3fan commented Sep 25, 2017

@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?

@gks
Copy link
Contributor

gks commented Sep 25, 2017

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.

iccub pushed a commit to iccub/browser-ios that referenced this issue Oct 4, 2017
@iainbeeston
Copy link

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?)

@st3fan
Copy link

st3fan commented Oct 15, 2017

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.

@gks
Copy link
Contributor

gks commented Oct 16, 2017

@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...

@farhanpatel
Copy link

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

@gks
Copy link
Contributor

gks commented Oct 30, 2017

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.

@farhanpatel
Copy link

Sent a build to kyle @ company and support just in case you didnt get it 😄

@gks
Copy link
Contributor

gks commented Oct 30, 2017

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.

@gks gks closed this as completed Oct 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants