Attach the post add-on install dialog to the extensions button
Categories
(WebExtensions :: Frontend, task, P3)
Tracking
(Not tracked)
People
(Reporter: rpl, Assigned: rpl)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [addons-jira])
Attachments
(4 files)
The add-on post install dialog is currently still attached to the appmenu, but it was meant to be attached to the extensions button instead (e.g. as briefly mentioned in Bug 1805914 comment 3) and this bugzilla issue is tracking following up on that.
Attaching the post install dialog to the extensions button will also ensure that a new installation will not be overlapping with the post install dialog (issue tracked by jbug 1805914), and instead the two dialogs would instead be stacked and allow the user to see both of them.
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 2•1 year ago
|
||
| Assignee | ||
Comment 3•1 year ago
|
||
| Assignee | ||
Comment 4•1 year ago
|
||
| Assignee | ||
Comment 5•1 year ago
|
||
Hi Alan and Julian,
There is a change in behavior with just attaching the post install dialog to the extensions button instead of attaching it to the app menu that we wanted to gather your perspective about:
-
appmenu-attached popup notifications are global, which we feel like is particularly relevant when the extension will open a tab right after being installed (e.g. to let the user see and accept an extension-related user data collection consent). You can see that kind of install flow as it is going to behave currently with the post install dialog attached to the appmenu in the screencast attached to comment 2.
-
"extensions button"-attached popup notification are using PopupNotifications.sys.mjs internally and those are per-tab notification, and so they are being hidden and shown based on the currently selected tab, which for extensions that are opening a tab right after being installed for the first time translates into the post install notification being hidden pretty quickly after the extension is installed and opens a new tab (eventually being shown again if the user switches back to the tab that originated the installation). You can observe this behavior in the screencast attached to comment 3.
We have started to explore some potential other approach to deal with that (e.g. comment 4 is a screencast recorded with some more changes to make the appmenu notifications to be attached to the extensions button), but before considering to discuss in more detail other approaches with a Firefox Desktop frontend peer we wanted to gather your opinions from a Product and UX perspective on the behaviors described above and double-check if you also think that we may want to look into possible approaches to allow the post addon install notifications to be attached to the extensions button but behave as a global notification like the one attached to the appmenu.
Comment 6•1 year ago
|
||
After meeting with Luca and Julian today, I agree that attaching the dialog to the Extension toolbar icon AND making it appear globally if the user or extension opens a new tab would be the ideal outcome. Many extensions open a new tab after installation, and we do not want to lose the modal information in a different tab. Also, as the extension is creating this modal, this should be clearly indicated by linking it to the extension toolbar icon. The app menu is too Generic to give this context to the user.
Could we timebox investigation into achieving these goals to see how long implementation may take? Also, we shouldn't block the other post-install dialog changes by this.
| Assignee | ||
Comment 7•1 year ago
|
||
(In reply to Alan Byrne from comment #6)
After meeting with Luca and Julian today, I agree that attaching the dialog to the Extension toolbar icon AND making it appear globally if the user or extension opens a new tab would be the ideal outcome. Many extensions open a new tab after installation, and we do not want to lose the modal information in a different tab. Also, as the extension is creating this modal, this should be clearly indicated by linking it to the extension toolbar icon. The app menu is too Generic to give this context to the user.
Could we timebox investigation into achieving these goals to see how long implementation may take? Also, we shouldn't block the other post-install dialog changes by this.
As mentioned during out meeting, I agree that we should separate this effor for Bug 1911163 addon install dialog re-design, and so I already proceeded with splitting out Bug 1911163 patch stack from the patch attached to this issue (and which we will have to be reworking to aim to be able to anchor dialogs like the post install dialog to the extension button while also ensuring that the dialog is made visible across tabs and browser windows).
Comment 8•1 year ago
|
||
Hi! Yeah, echoing what Alan said and we discussed earlier: If we want to anchor popup notifications to the extension button, we should still behave like global notifications. I wouldn't resort to the somewhat hacky implementation you showed in comment 4 though, but I think you said you didn't like that either.
| Assignee | ||
Comment 9•1 year ago
|
||
Mike Conley and myself did meet today to discuss further about this issue and agree on what would be the preferred path forward and refactoring/rework panelUI.js (which is where the logic that manages AppMenuNotifications popup notifications and badges lives) to support popup notifications and/or badges on more than just the appMenu button feels like the best path forward and could definitely be something that other teams may want then to leverage to have globally persistent notifications attached to other Firefox toolbar buttons.
| Assignee | ||
Updated•1 year ago
|
Description
•