how to deal with iOS firefox and 1password bookmarks?
using a lot of 1password bookmarks in firefox in the form of onepassword7://open_and_fill/SOMELONGSTRING. Idea is they open and fill as indicated by the name when clicking them. that is an awesome feature.
Problem
using firefox sync to keep firefox bookmarks in sync on all devices, which is great. but on ios with firefox 15, when I open such a bookmark, firefox opens the default search engine with the url as search string. that's unexpected.
Is this the bug that would solve this? https://bugzilla.mozilla.org/show_bug.cgi?id=1490081
how are others dealing with this? just manuelly enter the url and then use the password fill option of iOS? it's a bit cumbersome to be unable to use my bookmarks. or in other words what's the route forward here?
1Password Version: 7.2.4
Extension Version: iOS 7.2.7
OS Version: macOS 10.14.3, iOS 12.1.3
Sync Type: wifi
Comments
-
Hello @LosInvalidos,
The bug you linked to seems to be quite separate from the issue you're reporting. The bug, I believe, relates to the fact that Firefox associate a domain with the iOS app but the result is rather than using the tab's URL for determining what credentials match every attempt uses the associated domain. The domain association was more for dedicated apps and it doesn't work too well for browsers where they may be asked to visit any site. We also had some trouble as well because we associate certain domains with 1Password for iOS and we had to work around it. Now all that being said, I find that the current version of iOS Firefox will offer me a Firefox Login item automatically if I visit their sync sign-in page but for all other pages I get the generic AutoFill Passwords option but once there things are filtered correctly by the open page so that bug seems to be partially addressed already.
The URI is a different matter. One of our developers, whose technical skills eclipse mine by a staggering magnitude (imagine trying to spot me as an individual standing next to our Sun) tells me this isn't going to work on iOS, not with how things differ there from the likes of macOS. Maybe future versions of iOS will allow us to do more but it looks like you may find the easiest way around this is to search in 1Password for iOS and copy the URL over. It's a lot more steps and given the trade-off a lot will depend on how much you use iOS Firefox. If you use it equally as much as compared to the desktop than storing open-and-fill URIs may not be the best solution, it may be better to store the URL for the sign-in page and then on the Mac use the keyboard shortcut ⌘\ as those bookmarks will work equally well on your iOS device.
I apologise that I don't have anything more promising at the moment.
0 -
That's a great reply and thanks for sharing all those details. I wonder if there is a pending feature request in rdar:// to support URIs in iOS. That should solve the problem, no? And if not where to file that, as I don't have a personal apple dev account to file rdar tickets.
One follow up question though about the current non solvable issues with iOS firefox: does safari on iOS share all those problems or does the behavior differ?
0 -
Hello @LosInvalidos,
Good questions, I'll do my best to answer them :smile:
I don't know if there is a rdar. My understanding is only the person reporting an issue can see the rdar they submit and there's no way to know if it is a duplicate or not. It is possible somebody on our team has filed a rdar, all I can say with any confidence is I know I haven't. I have to confess I don't know what options Apple offers us users in terms of requests etc. I clearly haven't been active enough :lol:
I didn't know the answer to your second question so I did a bit of testing. iOS Safari does share the same issue. When I tried to open a 1Password URI I received the error message
Safari cannot open the page because the address is invalid
Possibly not too surprising. It's worth noting that browsers such as iOS Firefox, Chrome, Brave etc. are all effectively wrappers to iOS Safari and that is all they're allowed to be so for something like this that would require support from the web focussed API and iOS itself support would probably come to iOS Safari first and then the others could potentially leverage it for free.
0
