Closed
Bug 1334354
Opened 8 years ago
Closed 8 years ago
Post-install notifications are dismissed immediately if AMO redirects to a contribute page
Categories
(Toolkit :: Add-ons Manager, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla54
Tracking | Status | |
---|---|---|
firefox54 | --- | verified |
People
(Reporter: aswan, Assigned: aswan)
References
Details
(Whiteboard: triaged)
Attachments
(1 file)
This was originally discussed over on bug 1333071. The problem is that if an extension has a contribute page, AMO immediately redirects the browser to that page after installing. But with the new post-install notifications as they are currently implemented, this navigation causes the notification to be dismissed before the user has a chance to see it.
Passing the option "persistence: 1" when creating the popup prevents the notification from being dismissed in this case but it means that in other cases (installs from sites other than AMO or installs of extensions that don't have a contribute page), the notification will stick around.
Assignee | ||
Comment 1•8 years ago
|
||
Oops, I should have cloned the original bug. Coyping the cc list over manually.
What do folks think, can we live with the situation described in the initial description for this bug? (notification sticks around even if AMO doesn't navigate away)
Assignee | ||
Updated•8 years ago
|
Blocks: webext-permissions
Comment 2•8 years ago
|
||
I'm not sure I fully understand the problem. The 'timeout' option may also be interesting, depending on what you try to do.
Assignee | ||
Comment 3•8 years ago
|
||
(In reply to Florian Quèze [:florian] [:flo] from comment #2)
> I'm not sure I fully understand the problem. The 'timeout' option may also
> be interesting, depending on what you try to do.
Maybe it isn't a huge problem but I was just pointing out that AMO doesn't always redirect after an install finishes (in fact, I think the redirect is the uncommon case). So if we use the persistence option, that means the notification can remain present through another unrelated navigation. That seems unlikely though as this notification is not "persistent" (not to be confused with "persistence") so it is likely to be dismissed pretty quickly by the user.
Comment 4•8 years ago
|
||
If AMO is our main concern and they want to keep this feature, I suggest that we get AMO to change how it acts in this scenario. It doesn't have to do a redirect, it could just show something inline as soon as it gets the trigger.
Flags: needinfo?(jorge)
(In reply to Andrew Swan [:aswan] from comment #3)
> (In reply to Florian Quèze [:florian] [:flo] from comment #2)
> > I'm not sure I fully understand the problem. The 'timeout' option may also
> > be interesting, depending on what you try to do.
>
> Maybe it isn't a huge problem but I was just pointing out that AMO doesn't
> always redirect after an install finishes (in fact, I think the redirect is
> the uncommon case). So if we use the persistence option, that means the
> notification can remain present through another unrelated navigation. That
> seems unlikely though as this notification is not "persistent" (not to be
> confused with "persistence") so it is likely to be dismissed pretty quickly
> by the user.
When the extensions.webextPermissionPrompts pref is false the "... has been installed successfully" doorhanger persists and is still shown when the post-install contribution page is loaded - is that implemented differently or is it timing related that it works in this scenario?
Flags: needinfo?(aswan)
Assignee | ||
Comment 6•8 years ago
|
||
Ah, the existing notification uses timeout as Florian suggested in comment 2. I didn't fully grasp what it did before but it seems like the best option here...
Flags: needinfo?(aswan)
Comment hidden (mozreview-request) |
Assignee | ||
Updated•8 years ago
|
Attachment #8831320 -
Flags: review?(florian)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → aswan
Updated•8 years ago
|
Priority: -- → P1
Whiteboard: triaged
Comment 9•8 years ago
|
||
mozreview-review |
Comment on attachment 8831320 [details]
Bug 1334354 Provide timeout for post-install notification
https://reviewboard.mozilla.org/r/107876/#review109904
Attachment #8831320 -
Flags: review?(florian) → review+
Comment 10•8 years ago
|
||
Pushed by aswan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bfd5466351b0
Provide timeout for post-install notification r=florian
Comment 11•8 years ago
|
||
During Bug 1308310 testing I’ve noticed that while installing from Disco Pane the new confirmation pop-up is not so visible, because after installation, the focus is automatically changed to add-on confirmation tab.
After returning back, the doorhanger is dismissed and I am not so sure how noticeable is the puzzle icon from toolbar: https://www.screencast.com/t/eVuSPqrecsG
Could this confirmation tab be somehow delayed in order to give enough time for permission doorhangers to be observed by users? Or is there a way to maintain displayed the pop-up though the focus is switched to another tab?
To be noticed that add-on confirmation page differs from contribution page and it is displayed in a new tab. For example DownThemAll! add-on displays both contribution and confirmation pages: https://www.screencast.com/t/iLb09izi
Comment 12•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Comment 13•8 years ago
|
||
Verified fixed on Firefox 54.0a1 (2017-02-23/24) under Windows 10 64-bit, Ubuntu 16.04 32-bit and Mac OS X 10.12.1. The Confirmation doorhanger remains displayed while AMO redirects to contribution page: https://www.screencast.com/t/YEjyaA6zmp
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•