Closed Bug 979249 Opened 10 years ago Closed 6 years ago

Disable "New app installed" notification from Win 8 and 8.1 nodes

Categories

(Mozilla QA Graveyard :: Infrastructure, defect)

Product:
Mozilla QA Graveyard
Component:
Infrastructure
Platform:
All
Windows 8
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: AndreeaMatei, Assigned: jimm)

References

Details

(Whiteboard: [needs update template]) 

We want to disable the notification that appears in the top right corner when a new application gets installed. In the case of Firefox, it says "You have a new app that can open webpages" or something like that. We've seen one case where the notification didn't fade out and several of them were waiting to appear after the first got finally closed.
Blocks: 978684
We'll need to agree on the best approach to disable this.

I've found these methods:
http://www.eightforums.com/tutorials/26244-new-app-installed-notification-disable-windows-8-a.html
No longer blocks: 978684
Given that we don't have a domain controller I would say lets use the .reg file and import that. The file can be stored on the share (fs1.qa.scl3.mozilla.com), and we refer to it from the ESX documentation.
Whiteboard: [needs update template]
Assignee: nobody → andreea.matei
Status: NEW → ASSIGNED
I'll start this today beside the tps work, with the staging machines. I will put the .reg file in the share and if everything works fine, we'll move to production.
So I have tried to change this on win-81-32 from staging, added the .reg file in share/config/disable_new_app_notification and applied it. After that I restarted Windows Explorer / logged off and installed a firefox build. The notification was still present. 

I also tried the second option of the documentation: 
Went from gpedit.msc -> Computer Configuration, Administrative Templates, Windows Components and opened File Explorer where I found "Do not show the 'new application installed' notification" and enabled it.
Same restart Windows Explorer/log off/restarted the machine, but still the notification is present.

Before all this, I tested the .reg file on my Win 8.1 VM and it did the trick after only restarting the explorer. Does anyone know what could be different on our machines that it's not working?
Have you tried to completely restart the VM? Does this help?
Yes, tried also to restart the machine when I did the second option with the UI, it didn't help :(

I can try again on another machine, maybe these solutions work on some only, but that would be strange.
I have seen several popups window hanging when I accessed mm-win-81-32-1.
Also the testruns on that machine failed one after another as explained in bug 987698 until I manually closed the notifications. Can this popups block us somehow from opening firefox ?
Those popups shouldn't block Firefox to get started.  They can only cause focus issues when accessing popups in the tests.

Andreea, would be good if you can have a look if other people are also affected. There might be forum posts or whatever which might help us.
I haven't found other people affected by this but I did wrote on that forum about the issue and if there can think of something like env variables or settings that can interfere with the option. 
 
It worked on my local VM, so something on the remote machines that is different is blocking this I guess. The option is still enabled to not show notifications, for the 2 staging machines, in gpedit.msc.
Ok, so lets wait for an answer. If we don't get one lets revisit this bug next week.
Someone else reproduced this issue with Firefox, but the interesting part is that when installing Chrome or Opera I don't get the notification anymore after disabling it. I wonder why only Firefox.

http://www.eightforums.com/tutorials/26244-new-app-installed-notification-disable-windows-8-a-2.html#post361827
Does it matter if you install Firefox by letting it set automatically as default browser, or not? I wonder what's different for us.

Jim, do you have an idea?
Flags: needinfo?(jmathies)
We reset these keys on every install/uninstall, maybe that has something to do with it?

http://mxr.mozilla.org/mozilla-central/search?find=%2Fbrowser%2Finstaller%2Fwindows%2Fnsis%2F&string=ResetWin8PromptKeys

I can try testing the registry fix to see if it work on my tablet.
Flags: needinfo?(jmathies)
Jim, so this has been landed with other patches on bug 981166? Why is it necessary to remove this registry setting? I looks like that with that behavior we mess up with the users system, and its settings.
Kamil will help us here given that the causing patch was part of a Metro bug.
Flags: needinfo?(kamiljoz)
QA Contact: kamiljoz
(In reply to Henrik Skupin (:whimboo) from comment #14)
> Jim, so this has been landed with other patches on bug 981166? Why is it
> necessary to remove this registry setting? I looks like that with that
> behavior we mess up with the users system, and its settings.

Test slaves don't use the installer correct?
(In reply to Jim Mathies [:jimm] from comment #16)
> (In reply to Henrik Skupin (:whimboo) from comment #14)
> > Jim, so this has been landed with other patches on bug 981166? Why is it
> > necessary to remove this registry setting? I looks like that with that
> > behavior we mess up with the users system, and its settings.
> 
> Test slaves don't use the installer correct?

Ah I think I see a possible problem, we added this call to RemoveDEHRegistration which runs on every PostUpdate. Taking that ${ResetWin8PromptKeys} "HKU" "$1\" call out there may solve the problem.
(In reply to Jim Mathies [:jimm] from comment #16)
> Test slaves don't use the installer correct?

They have to. There is no other installation method available.
Jim was also wondering if you would be able to work with try builds to check if the fix was working on the VM machines?
Flags: needinfo?(kamiljoz) → needinfo?(hskupin)
mozmill-ci does not support try builds, but we can install run the testruns by hand with the try build installer selected as source.
Flags: needinfo?(hskupin)
(In reply to Henrik Skupin (:whimboo) from comment #18)
> (In reply to Jim Mathies [:jimm] from comment #16)
> > Test slaves don't use the installer correct?
> 
> They have to. There is no other installation method available.

Hmm, what test infrastructure are we talking about here? For test run like mochitests, the browser and tests are unpacked from zips. 

Regardless, I don't think the registry changes we make in PostUpdate, install, and uninstall should change the behavior after setting the global system settings mentioned in comment 1. We can build up test builds with that routine commented though to test to be sure. The registry changes we make only impact systems that have prompted once before. With test slaves, we reboot before the run to reset the system, so the prompting would not have happended yet.
This is about Mozmill tests, which do not run on buildbot. We also cover beta and release builds for each locale. There are no zip archives for such builds.

Steps which should be enough for this to test:
1. Download and unzip the latest mozmill environment: https://mozqa.com/mozmill-env/
2. Execute the run script inside the environment folder
3. Disable new app notifications
4. Run 'testrun_l10n %path_to_installer%
5. Check new app notifications

Step 4 will install the build via the silent installer, run the tests, and finally uninstall the build.
Kamil, you wanted to help us here. So can you please give us feedback about the current state? It would be great to see progress here because it will be a blocker soon.
Flags: needinfo?(kamiljoz)
Jim and Kamil, any news here? We really would like to see this problem addresses sooner than later. Thanks!
Flags: needinfo?(jmathies)
I can work up a try build with the notification clearing code removed. In fact I think we're close to being able to disable the conversion code in general, most of the metro installs are now dead.

https://crash-stats.mozilla.com/daily?p=MetroFirefox&v=
Assignee: andreea.matei → jmathies
Flags: needinfo?(jmathies)
Test build - 

https://tbpl.mozilla.org/?tree=Try&rev=12c2af43d3d1

This just removes the call that resets the toast keys. Once you get prompted and response during an install, you shouldn't get prompted again. This might fix the disabling hacks we've been playing with here as well.
Thanks Jim. Andreea will check that build tomorrow.
Flags: needinfo?(kamiljoz)
I tried this build several times:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.com-12c2af43d3d1/try-win32/

which is the one used on tbpl and I still get the notification, although the setting is disabled.
(In reply to Andreea Matei [:AndreeaMatei] from comment #28)
> I tried this build several times:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.
> com-12c2af43d3d1/try-win32/
> 
> which is the one used on tbpl and I still get the notification, although the
> setting is disabled.

Ok, so that's not surprising. Have we confirmed both the policy changes here have no effect?

http://www.eightforums.com/tutorials/26244-new-app-installed-notification-disable-windows-8-a.html

I don't see anything in our installer that could override settings like this. The toast key entries were a bit of a hack on our part, with that removed I'm not sure how we could retrigger these prompts on new installs.
Apologies for not replying earlier, I was on vacation and couldn't get an internet access.

Using the try build from comment #28, I went through Option #1 and still ended up getting the notification once Nightly was installed. The following key is always "Disabled" but Windows seems to completely ignore it:

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer (under this, NoNewAppAlert = 1)

I couldn't go through Option #2 as it's only available under Windows 8 Pro & Windows 8 Enterprise editions, which unfortunately I currently don't have.

I also tried going through the same tests with Chrome and I'm getting the same behaviour. Once I download and install Chrome, I get the notification even though the above key was created. I tried installing Chrome with and without the "Make Chrome Default" option selected and still got the notification.

Chrome standalone: https://www.google.com/chrome/browser/index.html?standalone=1 (received the notification)
Chrome from net: https://www.google.com/intl/en-CA/chrome/browser/ (received the notification)

Reading the thread from comment #28, it looks like if a file type is already associated with another application, you cannot change it within another program hence the prompts from Windows. As this is happening with Chrome, I don't think this is related to FX alone.

Steps that I went through with both FX/Chrome:

* Reset the VM to a fresh state where IE is set as the default browser
* Set the reg key that is mentioned above and restart the machine
* Install FX or Chrome (receiving the notifications)
Actually I rechecked this on a Win 8.1 VM with the setting enabled via the gpedit file, and after I installed Chrome, the notification appeared.
Status: ASSIGNED → NEW
Mozmill-CI will be shutdown on Monday next week. So this is not needed anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.