Prototype an AOM SitePermsAddonProvider to support synthetic Site Permissions addon type install flows
Categories
(Toolkit :: Add-ons Manager, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox107 | --- | fixed |
People
(Reporter: rpl, Assigned: nchevobbe)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-needed, Whiteboard: [addons-jira])
Attachments
(7 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
This bug goal is to prototype a new AOM provider to support a synthetic Site Permission addon type, which should:
- derive the list of synthetic SitePermsAddon instances from the list of site origins with any addon gated permission granted;
- provide a synthetic install flow (which should provide the same kind of install flow that the previous signed xpi version of the "sitepermission" addon type was providing) triggered when a gated addon permission is being requested.
The goal of the prototype is to help confirming that an AOM provider would be a viable, clean and simple enough approach, and if that is confirmed and if we will agree to proceed with that approach to then help informing and guiding the actual implementation work.
Reporter | ||
Comment 1•2 years ago
|
||
This patch includes a basic (but still working) version of a new SitePermsAddonProvider.
NOTE:
- In this basic version of the provider, the list of synthetic addons is recomputed from
the list of the granted permission on each call to getAddonByID / getAddonsByType
that matches the parameters expected by the provider. - These two provider methods (getAddonBYID / getAddonsByTypes) are in practice only called
when the user navigates to about:addons, but it may be reasonable to iterate on this
initial prototype by introducing a cache file where we can list all origins with a gated
addon permission and keep that cache file updated through an "perm-changed" notification
observer and a new scan of all permission on each provider startup.
Reporter | ||
Comment 2•2 years ago
|
||
This patch includes:
- a new AddonManager method to trigger a new SitePermsAddon install flow
- a few more changes to the SitePermsAddonProvider to support the synthetic addon install flow
Depends on D151476
Reporter | ||
Comment 3•2 years ago
|
||
This patch includes a new PermissionUI.SitePermsAddonInstallRequestPrototype helper, it inherits from PermissionPromptForRequestPrototype
and override the prompt
method to trigger the synthetic SitePermsAddon install flow when a addon gated site permissions is requested
(currently only "midi/midi-sysex").
The new SitePermsAddonInstallRequestPrototype helper is then set as the proto for the MIDIPermissionPrompt.prototype, which
makes sure that every time the MIDI site permissions are being requested, the user is prompted to install a synthetic addon
as part of the site permission request.
NOTE:
- the rest of the MIDIPermissionPrompt is currently unused in this version of this exploratory patch, a finalized version
of the patch should also consider if there is any scenario that would require the regular permission prompt for the
gated site permission requests
Depends on D151477
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Reporter | ||
Comment 4•2 years ago
|
||
As a side note:
- Along with the 3 patches attached to the bug, the following check in MIDIPermissionsRequest::Run needs to be removed (or commented out) to make sure requestMIDIAccess will trigger the install flow (by reaching the call to “nsContentPermissionUtils::AskPermission” that follows it):
NS_IMETHODIMP
MIDIPermissionRequest::Run() {
...
// If the add-on is not installed, auto-deny (except for localhost).
if (!nsContentUtils::HasSitePerm(mPrincipal, kPermName) &&
!BasePrincipal::Cast(mPrincipal)->IsLoopbackHost()) {
Cancel();
return NS_OK;
}
...
}
Assignee | ||
Comment 5•2 years ago
|
||
I pulled the patches today and tried to see the various parts of the work, using navigator.requestMIDIAccess()
to trigger the prompts.
If the installation of the addon doesn't go through, the promise rejects with the following error: https://searchfox.org/mozilla-central/rev/f655bdf6b4bf01b42609750ab94fc37635397260/dom/midi/MIDIPermissionRequest.cpp#62-65
I guess we'll have to tweak this a bit a it probably refers to a previous implementation
Reporter | ||
Comment 6•2 years ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #5)
I pulled the patches today and tried to see the various parts of the work, using
navigator.requestMIDIAccess()
to trigger the prompts.
If the installation of the addon doesn't go through, the promise rejects with the following error: https://searchfox.org/mozilla-central/rev/f655bdf6b4bf01b42609750ab94fc37635397260/dom/midi/MIDIPermissionRequest.cpp#62-65I guess we'll have to tweak this a bit a it probably refers to a previous implementation
yep, I totally agree, that error message would need to be tweaked accordingly to how this will be working once there isn't any website opt-in.
Honestly I think that it also be reasonable to make that error to just states that the user rejected the permission request, the developer are not going to be opting in by installing an addon in this version of the sitepermission addon type and so:
- from a website perspective, that rejection means that the user didn't let the install flow to complete (and basically not granted the permission request)
- from a user perspective, that error wouldn't be directly visible, and the users wouldn't definitely need to look to our extension developers docs.
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
When the pref is true, we want to go through the new SitePermissionAddon
install flow.
Depends on D151478
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 8•2 years ago
|
||
Depends on D156192
Updated•2 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
This will be used in SitePermsAddonInstallRequestPrototype
to discriminate permission
requests coming from localhost, where we want to fallback to regular permission prompt.
Depends on D151477
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1a68797d8bbc
https://hg.mozilla.org/mozilla-central/rev/58083286fe3d
https://hg.mozilla.org/mozilla-central/rev/2f1a9eb03661
https://hg.mozilla.org/mozilla-central/rev/3913eb81b668
https://hg.mozilla.org/mozilla-central/rev/21a65ff1007c
https://hg.mozilla.org/mozilla-central/rev/1ef96ac13291
Comment 12•2 years ago
|
||
This feature is explicitly disabled in Thunderbird, in extensions.manifest, so the test doesn't work there.
Comment 13•2 years ago
|
||
A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
bugherder |
Description
•