Closed
Bug 832501
Opened 11 years ago
Closed 11 years ago
Sync issues in metro fx
Categories
(Firefox for Metro Graveyard :: Browser, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: ally, Unassigned)
References
Details
Attachments
(2 files)
I'm seeing the following error logs show up all the time on my client. I suspect they are not related, but I am dropping them here. this might turn into a tracking bug. A)I did a metro-metro pairing and both computers spat out erroring logs (though mostly works), though at least some data appears to be moving between them. B) there is a series of these on the metro fx from the past 2 weeks. I noticed them when trying to troubleshoot (A)
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
from (A) I suspect this is the issue is with passwords: 1358544838464 Sync.Engine.Passwords WARN Got exception Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] Stack trace: resource://gre/modules/services-sync/engines/passwords.js:84 < resource://gre/modules/XPCOMUtils.jsm:177 < applyIncomingBatch()@resource://gre/modules/services-sync/engines/passwords.js:132 < doApplyBatch()@resource://services-sync/engines.js:813 < doApplyBatchAndPersistFailed()@resource://services-sync/engines.js:828 < resource://services-sync/engines.js:932 < SyncEngine__sync()@resource://services-sync/engines.js:1342 < WrappedNotify()@resource://services-sync/util.js:142 < Engine_sync()@resource://services-sync/engines.js:519 < _syncEngine()@resource://gre/modules/services-sync/stages/enginesync.js:192 < sync()@resource://gre/modules/services-sync/stages/enginesync.js:147 < onNotify()@resource://gre/modules/services-sync/service.js:1185 < WrappedNotify()@resource://services-sync/util.js:142 < WrappedLock()@resource://services-sync/util.js:97 < _lockedSync()@resource://gre/modules/services-sync/service.js:1179 < resource://gre/modules/services-sync/service.js:1170 < WrappedCatch()@resource://services-sync/util.js:71 < sync()@resource://gre/modules/services-sync/service.js:1158 < connect/<()@sync.js:328 < <file:unknown>, aborting processIncoming. 1358544838464 Sync.Status DEBUG Status for engine passwords: error.engine.reason.unknown_fail 1358544838464 Sync.Status DEBUG Status.service: success.status_ok => error.sync.failed_partial 1358544838464 Sync.ErrorHandler DEBUG passwords failed: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] Stack trace: resource://gre/modules/services-sync/engines/passwords.js:84 < resource://gre/modules/XPCOMUtils.jsm:177 < applyIncomingBatch()@resource://gre/modules/services-sync/engines/passwords.js:132 < doApplyBatch()@resource://services-sync/engines.js:813 < doApplyBatchAndPersistFailed()@resource://services-sync/engines.js:828 < resource://services-sync/engines.js:932 < SyncEngine__sync()@resource://services-sync/engines.js:1342 < WrappedNotify()@resource://services-sync/util.js:142 < Engine_sync()@resource://services-sync/engines.js:519 < _syncEngine()@resource://gre/modules/services-sync/stages/enginesync.js:192 < sync()@resource://gre/modules/services-sync/stages/enginesync.js:147 < onNotify()@resource://gre/modules/services-sync/service.js:1185 < WrappedNotify()@resource://services-sync/util.js:142 < WrappedLock()@resource://services-sync/util.js:97 < _lockedSync()@resource://gre/modules/services-sync/service.js:1179 < resource://gre/modules/services-sync/service.js:1170 < WrappedCatch()@resource://services-sync/util.js:71 < sync()@resource://gre/modules/services-sync/service.js:1158 < connect/<()@sync.js:328 < <file:unknown>
Comment 3•11 years ago
|
||
If this is based on XUL Fennec, that's probably Bug 686362.
Comment 4•11 years ago
|
||
Locking errors indicate that something died before releasing the sync lock, probably because something wasn't expecting an error, and thus didn't have a catch block to invoke an async callback. My guess would be that the error is a failed import in a lazy getter, which means some code that looks like an attribute access actually throws. So let's figure out why nsILoginInfo is different here, and see if the lock problem goes away.
Comment 5•11 years ago
|
||
Ally: let svc = Components.classes["@mozilla.org/login-manager;1"].getService(Components.interfaces.nsILoginManager); let item = svc.getAllLogins().pop(); console.log("Is a metainfo? " + (item instanceof Components.interfaces.nsILoginMetaInfo)); should print true. If it doesn't, that'll be what's up :)
Comment 6•11 years ago
|
||
covered by other, more specific bugs.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•