1191008 - Notification to users about disabled signed add-ons on startup only displays on one window

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

When a user starts a Firefox session with multiple windows and we show the notification about disabling some of their signed add-ons we only display the notification on one of the windows and at least in some cases (maybe all) it won't be the foreground window.

Markus, showing the notification on the foreground window is the obvious thing here, should we also be showing it on all the other windows?

Comment 1

[jen strickland :jenstrickland]

Tracked for 41 and 42, to ensure the notification is visible to the user in the released version.

Comment 2

[Dave Townsend [:mossop]]

Attachment: patch

This moves the check to after all windows have been restored so we display on the front-most window. This is a pre-requisite to displaying on all windows if that is what UX want so might as well do this now and do all windows in a follow-up.

Comment 3

[Dave Townsend [:mossop]]

Attachment: patch

Accidentally snuck in another change

Comment 4

[Markus Jaritz [:markus] (UX)]

For release, showing it in the foreground window is perfect.
For pre-release it would be great to have it more prominently on all windows. (If we can clear the notification from all windows once the user acts on it in one of the windows.)
This might help make this message more prominent for add-on developers and ensure that they do not miss it, even if the foreground window was not relevant and quickly closed.
If it is not possible to differentiate the behavior in release/pre-release showing the notification in the foreground window is fine.

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/dac4fbb3f906

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/dac4fbb3f906

Comment 7

[Dave Townsend [:mossop]]

Comment on attachment 8643846 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: Signed add-ons
[User impact if declined]: Some users may not see the notification about unsigned add-ons being disabled as it would appear on a background window
[Describe test coverage new/current, TreeHerder]: Tested manually, we don't have tests for the feature during Firefox startup
[Risks and why]: The change is a straightforward code move so low risk
[String/UUID change made/needed]: None

Comment 8

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8643846 [details] [diff] [review]
patch

Let's uplift to Aurora as the fix seems straightforward.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8aec302ea187

Comment 10

[Vasilica Tamas, QA [:vtamas]]

Verified fixed on Firefox 41 Beta 2 (20150817163452) and Firefox 42.0a2 (2015-08-20) under Ubuntu 14.04 32-bit and Windows 7 64-bit. 

There is an exception when the notification is not displayed on the foreground window. This happens in Firefox 42.0a2 when the Developer Edition firstrun page is the only opened tab in one of the opened windows. Updating the Developer Edition from a version where the add-ons signatures is not required (e.g Firefox 41.0a2 from 2015-07-21) to a latest version where the pref xpinstall.signatures.required is set to true, the foreground window in this situation is that window which contains the Dev Edition firstrun tab. The notification about disabling some of their signed add-ons is displayed in the second window.

See screenshot: http://i.imgur.com/meernQY.jpg

But this is an edge case and I am not sure if it’s worth filed a bug for this issue. Dave what do you think?

Comment 11

[Dave Townsend [:mossop]]

I'm guessing that the use of the UI tour is bringing that window to the front after we've already shown the notification elsewhere. Presumably this requires the user to already have a window like that open before they update? In that case I think we don't need to track it.

Comment 12

[Vasilica Tamas, QA [:vtamas]]

(In reply to Dave Townsend [:mossop] from comment #11)
> I'm guessing that the use of the UI tour is bringing that window to the
> front after we've already shown the notification elsewhere. Presumably this
> requires the user to already have a window like that open before they
> update? In that case I think we don't need to track it.

Yes, that window needs to be opened before update in order to reproduce this issue.

Based on the above mentioned I am marking this bug as Verified.