856436 - Add remoteMessageShown pref to remote API

Status: RESOLVED WONTFIX

(Firefox Health Report Graveyard :: Web: Health Report, defect, P2)

Description

[Mike Connor [:mconnor]]

Ideally this pref will be synced, so we don't force users to see the same notifications on every PC.  It should be an integer pref, so we can do future messages without having to add another pref.  That means we'll need a remote command that passes a value.

Sample API:

  var event = new CustomEvent("RemoteHealthReportCommand", {detail: {command: RecordMessageVersion,  value: <integer>}});
document.dispatchEvent(event);

New Prefs payload

{type: "prefs", content: {"enabled": true, "messageVersionShown": 0, ...}}

Should be low risk and backwards compatible.  Patch upcoming later today.

Comment 1

[Gregory Szorc [:gps]]

Can we just give the iframe access to local storage and/or cookies?

Comment 2

[Mike Connor [:mconnor]]

We could, but...

a) There are a lot of cases where cookies are discarded, not least of which is always-on private browsing (or "never remember history" in prefs).  From a Sync bug a while ago, we were at ~4-5% of users with that enabled.  See also "clear on shutdown" and other things like that.  I don't think that's right for what generally looks like an app feature.
b) It's a more invasive change, because we're embedding content in an iframe instead of loading it as a top-level this runs into fun third-party restrictions as a bonus.
c) I think it should be syncable, and cookies are not something I expect us to ever sync.

Comment 3

[Gregory Szorc [:gps]]

Also consider that the about:healthreport iframe content is technically not tied to Mozilla or Firefox. Introducing "remote message shown" to the API that about:healthreport speaks would leak the hosted site's implementation details and thus would not be a good API since it is vendor specific.

Given your response, I guess cookies are out. What about local storage?

Instead of a feature-specific event, how about exposing a simple "storage API" to the iframe. about:healthreport can then proxy this to local storage, a JSON file, series of prefs, etc. How robust do you want to go?

I guess what I'm trying to say is that I foresee this request being repeated for different states and I don't want to end up with N one offs.

Comment 4

[Georg Fritzsche [:gfritzsche]]

This didn't see action in a while, its unclear on whether this is currently needed.
I'll close and we can re-open if it comes up for future selfsupport/shield plans.