Unable to see the settings option after installing an add-on from AMO
Categories
(Firefox for Android :: WebExtensions, defect, P1)
Tracking
()
People
(Reporter: amejia, Assigned: rpl)
References
Details
(Whiteboard: [addons-jira] )
Attachments
(4 files, 1 obsolete file)
STR
- Install an add-on from the AMO website.
- Go to settings -> add-ons -> tap on the installed add-on.
Expected behaviour.
At step 2 , the "Settings" option should be visible.
Actual behaviour.
At step 2 , the "Settings" option is hidden, and only shown after restarting Fenix .
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Hi Arturo, can you please clarify why this was nominated for tracking status?
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 2•2 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #1)
Hi Arturo, can you please clarify why this was nominated for tracking status?
Sorry, the priority was incorrect I updated it.
| Reporter | ||
Comment 3•2 years ago
|
||
Updated•2 years ago
|
| Reporter | ||
Updated•2 years ago
|
| Assignee | ||
Comment 4•2 years ago
|
||
This patch includes the following changes:
-
A new AddonManagerDelegate.onReady delegated method: this new delegated method is expected to be called when an extension
has been started.
On the firefox-android's android-components side (in particular the components providing the building blocks used by the
Fenix AddonManager UI) are meant to be using this new delegated method to make sure that the resolved optionsPageUrl will
be stored in the installedExtension map kept on the android-components side (by the WebExtensionSupport class to be precise),
as a side-effect of that the settings button in the addon detail view is expected to become visible after having
installed a new extension from AMO (as it was already the case for addons installed from the recommended set directly from
the Fenix Addon Manager). -
Removes the implicit await on the extension to be ready from the underlying logic handling on the Gecko side the calls to
the WebExtensionController.install method (which before these changes was the hack meant to make sure the settings button
would be visible after installing an addon from the Fenix AddonManager UI). -
Replaces the previous test case asserting that the optionsPageUrl was going to be available right after having installed
the extension (which was working only thanks to the implicit await described right above) with a test case covering the
new expected behavior.
NOTE: To fully fix the issue tracked by this bugzilla ticket, this change has to be complemented with some more changes on the
firefox-android github repo side, in particular the once included in this draft patch:
| Assignee | ||
Comment 6•2 years ago
|
||
Comment 7•2 years ago
|
||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 8•2 years ago
|
||
Added leave-open keyword, so that we can then explictly mark this as closed once the github PR is also merged on the firefox-android github repo side.
| Assignee | ||
Comment 10•2 years ago
|
||
Depends on D193085
| Assignee | ||
Comment 11•2 years ago
|
||
Depends on D193325
Comment 12•2 years ago
|
||
| bugherder | ||
Comment 13•2 years ago
|
||
Authored by https://github.com/rpl
https://github.com/mozilla-mobile/firefox-android/commit/a9db74712946025a84fbc8c980ededd8c9fc5728
[main] Bug 1859585 - WebExtensionSupport should update installExtensions entries on AddonManagerDelegate.onReady calls.
| Assignee | ||
Comment 14•2 years ago
|
||
Both the change to be landed to mozilla-central and the one to be landed in the firefox-android github repo have been merged, the two remainig patches are docs only or not strictly related to the issue tracked by this issue and so we can move them in a separate followup if they are not going to land today or tomorrow. In the meantime we can close this issue as fixed (and proceed with qe verify it if we want to in addition to the quick manual testing Arturo and I did before these patches have been merged).
| Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 15•2 years ago
|
||
The patch landed in nightly and beta is affected.
:rpl, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox120towontfix.
For more information, please visit BugBot documentation.
Comment 16•2 years ago
|
||
| Assignee | ||
Updated•2 years ago
|
Comment 17•2 years ago
|
||
| bugherder | ||
Description
•