Closed Bug 749857 Opened 8 years ago Closed 8 years ago

Invalid history record with empty URI and no visits created

Categories

(Firefox for Android :: Android Sync, defect, P1)

ARM
Android
defect

Tracking

()

RESOLVED FIXED
mozilla15
Tracking Status
firefox14 --- fixed
blocking-fennec1.0 --- +

People

(Reporter: philikon, Assigned: rnewman)

Details

Attachments

(1 file)

I finally connected my Nightly on Android to my Sync account. I had been using Nightly on my Android phone as my main mobile browser since it went native. After it synced, the desktop popped up a Sync Error. I went to the log and found out it was a history record with the guid "Toebm22f68pV". Downloaded and decrypted the record manually:

[17:43:38.910] > var rec = [output of manual download goes here]
[17:45:53.502] > Components.utils.import("resource://services-sync/engines/history.js");
[17:46:37.473] > var hrec = new HistoryRec("history", "Toebm22f68pV");
[17:46:55.670] > hrec.deserialize(rec);
[17:47:24.686] > hrec.decrypt()
[17:47:24.703] < ({id:"Toebm22f68pV", visits:[], histUri:""})

So, it seems Android Sync created a history visit with an empty URI (which is invalid already) and an empty visit list (which is also not correct and will be rejected by mozIAsyncHistory::updatePlaces().
Primary problem: there's a history record in Fennec's database that doesn't have a URI.

Secondary problem: we shouldn't upload it.

(Tertiary problem: getting a DB off the device is a pain.)

I will prep a fix for the secondary problem, but still want to investigate whether Fennec did something wrong here -- either during some migration stage, or in storing a blank record.
Nominating as release blocker; if this happens in the wild it'll cause problems. Easy band-aid fix will be up for review shortly. Lucas, Margaret, anyone else wandering by: any idea how this might end up in the DB?
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
blocking-fennec1.0: --- → ?
(In reply to Richard Newman [:rnewman] from comment #2)
> Nominating as release blocker; if this happens in the wild it'll cause
> problems. Easy band-aid fix will be up for review shortly. Lucas, Margaret,
> anyone else wandering by: any idea how this might end up in the DB?

I'm not immediately aware of what could have caused this. If Phil has been using Fennec Native since it first moved to Nightly, it's possible his profile could have been busted by code that's since been fixed. We have a constraint that prevents this from happening:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/db/BrowserProvider.java.in#327

Looking at hg blame, that code was added when we moved to using our own database for history data. I'm not sure what happened when we switched from using the Android browser database to our own, but I imagine that could have caused problems.
Priority: -- → P1
blocking-fennec1.0: ? → +
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ef64adfb6a0
Whiteboard: [needs review]
Target Milestone: --- → mozilla15
Attached patch Patch.Splinter Review
Patch for uplift. Release blocker.
Attachment #619673 - Flags: review+
Attachment #619673 - Flags: approval-mozilla-aurora?
Whiteboard: [waiting for aurora+]
https://hg.mozilla.org/mozilla-central/rev/74108dd3201d
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Attachment #619673 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [waiting for aurora+]
philikon, is this fixed for you now?
Product: Mozilla Services → Android Background Services
Product: Android Background Services → Firefox for Android
You need to log in before you can comment on or make changes to this bug.