Closed Bug 1073680 Opened 7 years ago Closed 9 months ago
not all passwords are sync'd between FF desktop and FF for Android
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140831201947 Steps to reproduce: I have close to 500 pwords sync'd between 3 desktop FFs and that seems to work find. However, not all of my pwords are sync'd with FF for Android. Accessing my pwords on FF for Android via Mobile Password Manager: https://addons.mozilla.org/en-US/android/addon/mobile-password-manager/?src=hp-dl-featured I seem to have only 33 pwords. Actual results: Visit site with password requirement which is auto filed on FF desktop Password is not auto filed Check for password in Mobile Password Manager and it isn't there. Expected results: Passwords from FF desktop should ALL be sync'd with and appear in FF for Android.
Component: General → Android Sync
OS: Linux → Android
Product: Firefox for Android → Android Background Services
Hardware: x86_64 → ARM
Yes I have this issue too. It seems that only my recently changed or recently used passwords are synced. All passwords which I used before I set up Sync on Firefox for Android are not synced. (Until I use them to login e.g.) Maybe this is also related to bug 1167944.
Started using FF for Android (beta, 46) a couple of weeks back and Sync generally works for tabs, history and bookmarks, but none of my passwords have been synced from my desktop profiles. I checked on desktop and a handful have a "last modified" time stamp past the date when I have set up Sync on my Android, still about:logins is completely empty. Everything is working fine on Mac (multiple profiles) and PC (multiple profiles) Master PW set on all profiles, including Android. Kevin, as this is slightly different to the issue described - 1.5y and 13 versions ago - should I maybe open a new bug? If I do file a new bug, would these steps still be required or is there something simpler put in palce by now? http://160.twinql.com/how-to-file-a-good-android-sync-bug/
mixed up the version, correct is Firefox for Android beta/45.0b6
Check about:logins. Though if you can show this then a new bug would be better.
The passwords synced in the meantime. Problem I have now is that they don't (all?) update.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1253899
Un-duping this, because it's about partial sync.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Albert, are you still experiencing this? If so, can you describe STR, even if approximate?
Checked again. Latest and oldest pws are there, some pws I updated a while ago via desktop and it reflects on mobile, _but_ - I had one site with four entries (same user) stored for several subdomains; deleted two on desktop and one on mobile with a confusing result: Before sync: - subdomain1.domain.tld -> deleted via desktop - subdomain2.domain.tld -> deleted via mobile - subdomain3.domain.tld | pw1 -> deleted via desktop - subdomain3.domain.tld | pw2 -> kept Desktop after sync (as expected): - subdomain3.domain.tld | pw2 Mobile after sync: - subdomain1.domain.tld - subdomain3.domain.tld | pw1 - subdomain3.domain.tld | pw1 (entry duplicated!? not sure if it's new or I overlooked it before.) - subdomain3.domain.tld | pw2 Next I deleted "subdomain3.domain.tld | pw2" via desktop and re-entered the user/pw on the site, with no different result for mobile after forcing syncs on both ends again. I hit "sync" a couple of times on both devices, restarted FF (Android), force stopped the app completely and even restarted the phone just to make sure.
Currently using Firefox for Android 54.0.1 with same master password on both PC and mobile. Password sync works on my old Gen1 Moto G running Lollipop but not on my new Moto G5 Plus running Nougat. Adding new passwords to FF Android or FF Desktop don't result in them syncing with each other
Am I right here? I am using Firefox for Android. I have 2 devices with the latest Play Store FF release and (finally bug #1369979) both setup with sync. I only sync passwords to these devices. Maybe 200, no idea, how to count this easily. On one device (ancient Android 4.2) things seem to be in sync. The other device is an Android 6.0.1 Lenovo Yoga Tab and it claims to sync since yesterday. It also claims to be in sync. But it does only show 4 logins, the ones it had before sync. So experience no sync happening to this device at all. (Remark, while checking for this post. The devices seem to be attached to the same account, since I can share pages between FF instances on all devices. In total 5 instances of FF on 4 devices: 2 PCs, 2 Android. 4 instances seem to be well in sync. I just spotted a minor spelling difference in the account used to log on. One letter is in uppercase on the Android, that actually syncs and in lower case on the other Android. However the desktop FF I use for this post, also has a lower case letter, so it does not really seem to matter.)
Could you please try to replicate, Thom?
See also this twitter discussion https://twitter.com/jakeMsantos/status/920041880305393664 User is experiencing an issue with passwords not syncing from Android mobile to desktop Firefox 56. Other data types are syncing just fine. Problem started with version 56 of the Desktop Firefox client according to the reporter.
I think I've managed to replicate this, and that it isn't fixed by bug 1404044 (at least not in all cases -- which makes sense, we have both `store` and `fetch` exceptions in our telemetry, and that one is about storing). Assigning to myself to look into it further.
Assignee: nobody → tchiovoloni
Priority: P2 → P1
fetch:unknown errors are now 90-100% of all password engine errors, after Bug 1404044 landed. Noisy graph from the nightly channel: https://screenshots.firefox.com/MfE4hXNKUCOxEPPx/localhost
I did some analysis in telemetry. Since October, about 0.3% of android users who sync passwords have this issue, and about 30% of the ones that did got better after having it once. This is bad, but not as catastrophic as an >50% failure rate for password sync indicates.
(In reply to Thom Chiovoloni [:tcsc] from comment #16) > and about 30% of the ones that did got better after having it once. sheesh, that's really quite confusing - so "almost" transient? :) (In reply to Thom Chiovoloni [:tcsc] from comment #14) > I think I've managed to replicate this It's not clear what the current hypothesis is - can you elaborate?
> sheesh, that's really quite confusing - so "almost" transient? :) Well, to be clear, by "once" I really mean "one or more times". From the samples I inspected in the notebook, it looked like they tended to have a lot of failing syncs for a long time before it got better. But yeah, confusing. > It's not clear what the current hypothesis is - can you elaborate? I managed to replicate it essentially by putting a breakpoint in the catch clause and waiting. Unfortunately where the breakpoint was set, the relevant error had already been rethrown as one that isn't particularly meaningful, which also means that it's possible that I actually experienced a different error. Regardless, my hypothesis is/has been that there's a case where if the OS triggers the sync, NSS isn't properly initialized some of the time. Possibly if password sync is the first/only engine that needs to do work. The fetch:unknown error is consistent with that, but it also could be consistent with, well, a variety of other things. Given the small % of users that are experience, it really might be the same error as `Services.logins is undefined`, but on the Fennec side. I suspect this would mean that 1. Multiple errors are coming through as fetch:unknown (this is almost certainly true) 2. The ones that fix themselves probably represent different problems. 3. The issue I experienced was one of those different problems that is reported similarly.
If this affects so few users, that's strange. As I can/could (not tested with recent versions) reliably reproduce it. The thing is all passwords are password-generated, use many, many characters, special characters (even üöä) or so, so if that could be one reason… My workaround always was to create a new Firefox account… :|
That's very helpful, thanks. The fact that creating a new Firefox Account fixed it makes me think that it is unrelated to NSS, and special characters gives a point to look into. Worth noting that users that created a new firefox account would have a new deviceID.
Yeah, well… IIRC basically I just created a new account, logged of from the old one. Logged in to the new one in all my devices. I think it is quite obvious that it works then, because everything is new. It may be that some old or manually added passwords were never synced, however (e.g. I added some passwords manually on Android, because some apps required some, but IIRC they never appeared on the desktop).
I don't use android regularly, nor can I repro this when trying in an emulator. I think we should still figure it out, but I'm going to unassign myself from it since I don't think I should be the one investigating it. Clearing priority as well at andym's recommendation (so we can re-triage).
Assignee: tchiovoloni → nobody
Priority: P2 → --
We should try to get to the bottom of why local password store fetches fail. We're bridging to moz_logins, and a sudden spike back in 56 without relevant java-side changes indicates that something changed on that side. Not assigning myself yet, but NI-ing myself to look into it.
Priority: -- → P2
Folks - as the original reporter, I'm not entirely sure this bug still holds. The OP was 4 years ago, since at least Quantum for Android I have not noticed any pwords missing. (But, Quantum does crash when trying to load all my pwords... But, that's another story...) Many thanks
Hi, I can confirm, there seems still a problem with android here. I am using Firefox beta on one PC, Waterfox on all PCs and Firefox on 2 Android devices. I do not observe problems with the PCs. I did not observe problems with one Android device in the past, but the 2nd Android device still shows a mere 4 Passwords of around 200, by the time of checking the other Android device Firefox keeps on crashing when I try to verify passwords and scroll beyond (about) page 5, i.e. password 40 or so. Both devices have up to date FF, but not up to date Android.
I'm afraid this is still a bug - my logins are not syncing between ff for Android and ff for gnu/linux desktop
P1, since this probably could corrupt logins data on all clients (in the case of a node reassign).
Priority: P2 → P1
Moving to p3 because no activity for at least 24 weeks. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P1 → P3
I'm afraid this is still a bug - my logins are not syncing between ff for Android and ff for gnu/linux desktop (again) So, 'activity'. Can this now be moved back to P1 please, so that something might get done about it - it really is very frustrating. And, very much detracts from the impression that Firefox is usable browser... Perhaps next time it's proposed that the priority be bumped down due to inactivity - the proposer could ask those on the bug list if the bug still exists?
I was too frustrated to write what Morgan Read wrote: The problem is still there, and obviously no one even cared about writing a unit test or so, just waiting for the user to give up, reduce priority, close bug. What do they expect? Monthly reports "bug still there"? For reasons, Android is the last environment, where I still use Firefox.
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: REOPENED → RESOLVED
Closed: 5 years ago → 9 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.