Closed Bug 576084 Opened 14 years ago Closed 14 years ago

Firefox Sync failing to load on Android: error creating resource://services-sync substitution

Categories

(Firefox :: Sync, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mbrubeck, Assigned: philikon)

Details

Attachments

(1 file)

The built-in (non-addon) Firefox Sync fails to load on Android with an NS_NOINTERFACE error at Weave.js line 88:

http://mxr.mozilla.org/mozilla-central/source/services/sync/Weave.js?mark=76-93#88

After that, there is a failure whenever trying to import a file from resource://services-sync/*.
Assignee: nobody → philipp
Component: General → Sync
Product: Fennec → Weave
QA Contact: general → sync
Version: Trunk → unspecified
Attached patch v1Splinter Review
Weave.js unnecessarily assumes that the resource://gre/modules/services-sync URI resolve to a file URL. This breaks for the OmniJAR case. Turns out we can just avoid the file URL dance and use the resource URI directly.
Attachment #455530 - Flags: review?(mconnor)
Comment on attachment 455530 [details] [diff] [review]
v1

this makes so much more sense, woo!
Attachment #455530 - Flags: review?(mconnor) → review+
http://hg.mozilla.org/mozilla-central/rev/d2f3475002d4
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Mm.. How should we track bug status of landings on mozilla-central vs landing on fx-sync?
I think people shouldn't land stuff on m-c, but we'll probably have to diff somehow.  This is not awesome, but hg makes it hard to protect areas.  I guess I'll post to dev.planning.
(In reply to comment #3)
> http://hg.mozilla.org/mozilla-central/rev/d2f3475002d4

Thanks for the checkin, Michael!

(In reply to comment #4)
> Mm.. How should we track bug status of landings on mozilla-central vs landing
> on fx-sync?

Well, the bugs' component would be Weave/Sync like in this case, no? We already track commits in the bugs, so it doesn't seem that hard.

(In reply to comment #5)
> I think people shouldn't land stuff on m-c, but we'll probably have to diff
> somehow.  This is not awesome, but hg makes it hard to protect areas.  I guess
> I'll post to dev.planning.

I think for this particular patch it made sense to land in m-c because it was blocking the omni jar work. It's probably the exception, not the rule. Either way, I think we should land this in fx-sync as well to avoid total confusion for now. hg should recognise the identical changeset once we re-convert and re-merge fx-sync to m-c.
(In reply to comment #6)
> Well, the bugs' component would be Weave/Sync like in this case, no?
Sure. I meant how do we keep sane in terms of easily searching for bugs that have yet landed on mozilla-central vs have yet to land on fx-sync?

I believe tracemonkey bugs get marked fixed-in-tracemonkey when it's landed on that branch and actually marked fixed when it lands on mozilla-central. But I'm not sure what they do if a fix is applied directly to mozilla-central.

Also, we're also kinda odd in that not everything that lands in fx-sync ends up in mozilla-central in that we have firefox specific ui bits, fennec specific, add-on specific, and then the general services bits.
http://hg.mozilla.org/services/fx-sync/rev/1796bf3fe141
No need for the file URI dance, just use the resource:// directly. 

Should this go on the 1.4.x branch?
Mmm, yeah, likely, as that's what our next merge will be.
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: