Here is some information about these prompts which should be helpful in making them work on GeckoView.
The API in question is documented here: https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using. When Gecko is ready to display a prompt, it creates a
StorageAccessPermissionRequest object https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/base/Document.cpp#12586 and calls
CheckPromptPrefs() on it. That function checks a bunch of prefs to determine whether it can synchronously determine the result of the permission check (which can only happen when our testing prefs -- which are used in the mochitests for the feature -- are set). The normal Web-facing path of this function would observe
PromptResult::Pending here. That would bring us to https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/base/Document.cpp#12629 where the prompt is requested to be displayed.
On desktop the prompt UI code for this prompt is here: https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/browser/modules/PermissionUI.jsm#963. The current code for this prompt does three things in the front-end parts: a) display the prompt, b) implement the "auto-grant" heuristics mentioned in comment 0, and c) add some telemetry measurements for the various actions the user may take (bug 1513309). It may be easier to look at bug 1490811 to see only the parts needed for the basic functionality of the prompt. For now, let's ignore the heuristics implemented in bug 1509047. Later on we can port those heuristics to Gecko so that they can be shared between desktop and GeckoView but no need to worry about them for now.
Here are a few notes to keep in mind about this prompt:
The prompt needs to display the domain of the top-level site as well as the domain of the third-party tracker iframe that the
requestStorageAccess() API has been called from. This information is attached to the
nsIContentPermissionRequest object that Gecko creates: the
principal field contains the principal of the third-party tracker frame and the
topLevelPrincipal field contains the principal of the top-level frame.
Please be careful to ensure IDN domain names are handled properly for displaying purposes in the prompt (see bug 1510015).
On desktop we designed the prompt carefully to ensure that the default button for the prompt is "Block Access" (see https://bugzilla.mozilla.org/attachment.cgi?id=9026500). This is important to ensure that users who may not read the prompt text carefully are nudged to the more privacy conscious choice rather than the privacy invasive choice ("Allow Access"). Not sure if this is the responsibility of the embedder app or is controlled by GV but thought to mention it. (Note that this was a difference between this prompt and the rest of our prompts and as a result we ended up with this regression: bug 1516889).
The "learn more" URL used in the prompt for desktop is defined here: https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/browser/modules/PermissionUI.jsm#1025
The desktop prompt has a third choice: "Allow Access on Any Site" besides Allow/Block. Feel free to expose this third choice on GeckoView as well, but also feel free to not do that, this one is optional. This is why
StorageAccessPermissionRequest takes three callbacks. In order for Gecko to differentiate between "Allow Access" and "Allow Access on Any Site", you would need to call
nsIContentPermissionPrompt.allow() with either of these JS objects: https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/browser/modules/PermissionUI.jsm#1063 or https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/browser/modules/PermissionUI.jsm#1072.
When testing this API, this test page will be handy: https://senglehardt.com/test/storage_access/. Please pay attention to the prefs listed at the top of the page, and also the link at the bottom of the page (you need to click on the link and interact with the page that opens up, e.g. click somewhere on it -- Gecko blocks calls to
requestStorageAccess() from third-party trackers which the user has never interacted with in a first-party context before.) If you decided to implement the "Allow Access on Any Site" feature you would need a similar test page on another top-level domain, and you can use https://ehsanakhgari.org/test/storage_access/ for that purpose.
The permission granted by this API will persist for 30 days. That's unhelpful when testing this feature! The permission is stored in Gecko's permission manager database, and you can clear it by doing anything that clears site data from the permission manager. For example, running this code somewhere with chrome privileges will do the trick:
Services.clearData.deleteData(Ci.nsIClearDataService.CLEAR_ALL, value => resolve());.
I hope this is enough information to get someone who has some free cycles to help out with this started. If you need any more information or have any questions please do not hesitate to ping me. I'd love to ensure that we fix all that we need here for Fenix so I'd be happy to help in any way that I can.