Register resource://services-sync before xpcshell tests get run

RESOLVED FIXED in 1.4

Status

Cloud Services
Firefox Sync: Backend
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Mardak, Assigned: philikon)

Tracking

unspecified
Points:
---
Bug Flags:
blocking-fx-sync1.4 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Seems like app-startup notification isn't sent.. or is sent after the xpcshell test tries to run.

We'll have to add the resource earlier.. maybe in the Weave.js's WeaveService constructor.

Or register it from the test head_
(Reporter)

Comment 1

8 years ago
Created attachment 453161 [details] [diff] [review]
v1
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #453161 - Flags: review?(mconnor)
(Reporter)

Updated

8 years ago
Flags: blocking-fx-sync1.4+

Updated

8 years ago
Attachment #453161 - Flags: review?(mconnor) → review+
(Reporter)

Comment 2

8 years ago
http://hg.mozilla.org/services/fx-sync/rev/94d14dc51035
Add the alias to resource://services-sync when loading the component instead of waiting for app-startup, which doesn't fire for xpcshell tests.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4
Comment on attachment 453161 [details] [diff] [review]
v1

>+(function addResourceAlias() {
>+  let ioService = Cc["@mozilla.org/network/io-service;1"].
>+                  getService(Ci.nsIIOService);
>+  let resProt = ioService.getProtocolHandler("resource").
>+                QueryInterface(Ci.nsIResProtocolHandler);
>+
>+  // Only create alias if resource://services-sync doesn't already exist.
>+  if (resProt.hasSubstitution("services-sync"))
>+    return;

While fixing the test issue on the trunk, this patch causes problems for the add-on case: the aliasing now happens when the top scope of Weave.js is executed. This apparently happens *before* the add-on's chrome.manifest is registered so the above if never triggers on the add-on.

I suggest backing this out and doing the aliasing separately for the tests.
(Assignee)

Updated

8 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 453375 [details] [diff] [review]
Fix add-on case

Put the call to addResourceAlias() back into the app-startup observer, but expose addResourceAlias() to other JS contexts so we can call it from xpcshell tests.
Assignee: edilee → philipp
Attachment #453375 - Flags: review?(mconnor)
(Reporter)

Comment 5

8 years ago
(In reply to comment #3)
> This apparently happens *before* the add-on's chrome.manifest is
> registered so the above if never triggers on the add-on.
Hrm. There must be a difference between cached manifests then. Seems like the add-on passes tests fine for existing profiles.
(Reporter)

Updated

8 years ago
Attachment #453375 - Flags: review?(mconnor) → review+
(Reporter)

Comment 6

8 years ago
http://hg.mozilla.org/services/fx-sync/rev/26b413905024
Don't try to create the alias too early, add-on chrome registration might not have happened yet, so do it during testing.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.