Add about:studies

[Osmose]

Users should be able to visit about:experiments to see a listing of the experiments that they have participated in. An outdated visual mockup based off the about:addons listing is available here.

To simplify things, this issue only covers adding a blank page at that URL. Subsequent issues will cover the content.

[MattGrimes]

Any chance this could be about:studies instead of experiments? We try not to use experiments whenever possible because it has negative connotations.

[Osmose]

Works for me. @telliot does that work for Pioneer as well?

[Osmose]

@andymikulski's kicking butt on the admin side, so I'll be taking this on in his stead

[Osmose]

@gijsk I have a wip commit implementing about:studies based on your feedback via email and in the PR, but I'm having trouble figuring out how to test that I'm doing things correctly. My about page shows up, but I dunno how to test whether it has the right restrictions from being in the content process. Any guidance on how to test that patch, or if anything is missing?

Also, although out of scope for this particular issue, how would I get data from the parent process to the child process to get a list of studies / request that a study be disabled? Would I just use the child process message manager in the JS in the HTML page to send and receive events, and the parent process manager in the main add-on code?

[Osmose]

Whoops, forgot to link to the commit: Osmose@20e2b23

[Osmose]

Also, although out of scope for this particular issue, how would I get data from the parent process to the child process to get a list of studies / request that a study be disabled? Would I just use the child process message manager in the JS in the HTML page to send and receive events, and the parent process manager in the main add-on code?

Update: I have a simple listing that gets a list of studies from the child process message manager, but I'm stuck on how the parent process will know to send the list of studies (outside of whenever the list is updated). Should it listen for an event from the child process? Should I be using broadcastAsyncMessage, even though the docs say to avoid it?

[gijsk]

The simplest way I know of checking what's happening manually is to open the page as the selected tab and, with the browser console, check gBrowser.selectedBrowser.contentPrincipal. If that has isSystemPrincipal set to true, something's not working right. I think in principle, in this case, it should be a null principal. It looks like for this to happen for your page, you'll want to pass Ci.nsIAboutModule.URI_SAFE_FOR_UNTRUSTED_CONTENT as well as the ALLOW_SCRIPT flag.

This will stop you from running chrome-privileged script directly in the page. If you need to communicate with the page from a listener, you would do that from the content process script (shield-content-process.js). See e.g. this code for an example:

https://dxr.mozilla.org/mozilla-central/source/browser/base/content/content.js#324

The TL;DR is that your content page can dispatch a new CustomEvent("AboutStudiesLoaded") event on its window/document, and you can listen for this in the content process script. From there you can send a message to the parent process to get the list of studies. It can then send a message back using the target property of the message it received, so you wouldn't need to broadcast.

When you receive a message back from the parent, you check that the content page is still about:studies (see the code linked above) and then you can either pass the data via another custom event, or manipulate the page DOM directly from your process script. If you go the custom event route (which might be easier if you use react here) then I expect you'll want to use Cu.cloneInto to make the plain JS objects readable for the page, much like we do for the SHIELD sandbox.

Does that make sense? :-)