Bug 1546248 - Loosen Client-ID check in unit test r=rpl

The client_id part of browser_html_discover_view_clientid.js was failing
on TV because of a pre-existing, test-specific issue in Telemetry.
Fixing this is not trivial, so just check that the ID was set instead of
checking its exact value.

See the comment for more details; the fix will be part of bug 1537933

Differential Revision: https://phabricator.services.mozilla.com/D30001

--HG--
extra : moz-landing-system : lando

toolkit/mozapps/extensions/test/browser/browser_html_discover_view_clientid.js

@@ -62,7 +62,18 @@ add_task(async function clientid_enabled() {
 
   ok(isNoticeVisible(win), "Notice about personalization should be visible");
 
-  is(await requestPromise, EXPECTED_CLIENT_ID,
+  // TODO: This should ideally check whether the result is the expected ID.
+  // But run with --verify, the test may fail with EXPECTED_CLIENT_ID being
+  // "baae8d197cf6b0865d7ba7ddf83829cd2d9844374d7271a5c704199d91059316",
+  // which is sha256(TelemetryUtils.knownClientId).
+  // This happens because at the end of the test, the pushPrefEnv from setup is
+  // reverted, which resets datareporting.healthreport.uploadEnabled to false.
+  // When TelemetryController.jsm detects this, it asynchronously resets the
+  // ClientID to knownClientId - which may happen at the next run of the test.
+  // TODO: Fix this together with bug 1537933
+  //
+  // is(await requestPromise, EXPECTED_CLIENT_ID,
+  ok(await requestPromise,
      "Moz-Client-Id should be set when telemetry & discovery are enabled");
 
   let tabbrowser = win.windowRoot.ownerGlobal.gBrowser;