1543721 - Add support for the Storage Access API prompts on GeckoView

Status: RESOLVED DUPLICATE of bug 1543720

(GeckoView :: General, enhancement, P2)

Description

[(no longer active)]

The only missing piece for enabling the storage access API on GeckoView is enabling its user prompts. For desktop we implemented these prompts in bug 1490811. Bug 1509047 added heuristics for not displaying the prompt in every single case that the page calls the storage access API, and the heuristics were implemented as part of the desktop-specific prompt notification code.

The desktop code can be found here: https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/browser/modules/PermissionUI.jsm#963

Comment 1

[(no longer active)]

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.

Comment 2

[Chris Peterson [:cpeterson]]

Fenix UX issue:
https://github.com/mozilla-mobile/fenix/issues/1749

Vesta says Enhanced TP is not necessary for Fenix MVP.

Comment 3

[Chris Peterson [:cpeterson]]

fenix:p2 because we should implement Enhanced Tracking Protection soon after Fenix MVP.

Comment 4

[Chris Peterson [:cpeterson]]

Adding [geckoview:fenix:m8] whiteboard tag because Fenix would like to support full ETP, including Storage Access prompts.

Comment 5

[Chris Peterson [:cpeterson]]

Moving to [geckoview:fenix:m9] because Fenix doesn't need the Storage Access API for their ETP MVP.

Comment 6

[Chris Peterson [:cpeterson]]

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9

Comment 7

[Chris Peterson [:cpeterson]]

move up the P2 backlog for November.