854905 - Make C:\slave\test\build\application\firefox\firefox.exe the default browser on Windows 8 test machines for metro

Status: RESOLVED FIXED

(Infrastructure & Operations :: RelOps: General, task)

Description

[Armen [:armenzg]]

To be able to run Windows 8 Metro UI tests we need to register it as the default browser.
Unfortunately, we can't do this programatically and I assume that the way to fix this is through GPO.

Can you please look into making C:\slave\test\build\application\firefox\firefox.exe the default browser?

If we can't, I don't know what other options we have if any.

Comment 1

[Jim Mathies [:jimm]]

Hmm, actually I'm not comfortable moving this to temp, since we always check it on startup, and anybody can create temp files.

Comment 2

[Jim Mathies [:jimm]]

bah, ignore that, wrong bug.

Comment 3

[Armen [:armenzg]]

I have verified that we can run the tests manually on that location.
We need this change before we can have win8 metro tests.

Comment 4

[Armen [:armenzg]]

Armen: can you clarify in the bug please:
 - do we need separate images for metro testing, or can the same image be used for non-metro testing?

The same image can be used. We only need to set the default browser.

 - how soon tests are ready to be run - when will this block ateam and/or devs?

As soon as I have a working mozharness/staging setup I could say that this bug blocks enabling this on production. At first we would only enable it on a limited amount of branches until they are greened out.

 - how confident we are that this is "all win 8 issues" - we do want to minimize the number of revisions to the GPO if needed.

For this Metro tests we're confident that this is the only needed change.
We're not aware of any other changes.

Comment 5

[Q]

This should be doable via several registry entries. By default firefox makes changes to the HKLM hive. However, this should be achievable via changes to HKCU which cltbld should be able to write to. If changes are made via GPO it will be difficult to make and maintain changes once it is in place. If possible this should be done at test runtime. We should chat real-time about some possibilities and to make sure we are all on the same page.

Comment 6

[Jim Mathies [:jimm]]

We can't set the default on Win8 by manipulating the registry, microsoft locked setting the default browser down. You can see this by monitoring registry changes in explorer.exe when you set the default. Explorer adds various UserChoice security related keys with hashes of the ProgId that the user chooses through control panel. We haven't found a way to simulate generating these hashes. This is why we open the control panel or prompt through a Windows UI to set file and mime type defaults.

http://msdn.microsoft.com/en-us/library/windows/apps/hh700321.aspx

"In Windows 8, apps no longer have the ability to set, change, or query the default handlers for file types and URI scheme names. When developing a Windows 8 desktop application version of your app, we recommend that you remove any user interface elements related to these functions. Instead, we recommend that you link to Set Default Programs in Control Panel."

I'd be willing to bet though that there is some sort of administrative way to do this designed for corporations that control these types of settings over the network.

Comment 7

[Jim Mathies [:jimm]]

Attachment: registry monitor log

This is a registry log generated by sysinternals Process Monitor if you're curious about what explorer does when you set a default browser via control panel's default programs applet.

Comment 8

[Brian R. Bondy [:bbondy]]

Here are some ideas:
1) Manually set an installed Firefox at this location on each test slave as default and then never touch the registry again per machine.
or
2) Manually create a .reg of the UserChoice per machine, and then download that before running the tests and import it.
3) We can try to *tweak* the already default delegete execute handler of IE to execute our code instead.  
4) Try to develop a new delegate execute handler which we will set as default everywhere, and then make it more dynamic about which code it executes.

I think #1 or #2.

Comment 9

[Armen [:armenzg]]

Would something like this but modified for Firefox work?
http://www.thewindowsclub.com/set-chrome-default-browser-windows-8

Could I ssh into all win8 machines and import such registry?

Comment 10

[Q]

As long as the program is registered consistently with the name "Nightly" upon first run/install I can make this happen via GPO on windows. I will speak with Armen to make sure this won't break "desktop"(as opposed to metro or charms) testing.

Comment 11

[Armen [:armenzg]]

(In reply to Q from comment #10)
> As long as the program is registered consistently with the name "Nightly"
> upon first run/install I can make this happen via GPO on windows. I will
> speak with Armen to make sure this won't break "desktop"(as opposed to metro
> or charms) testing.

I'm away tomorrow. We can chat today or Monday.
I think meeting the four of us would be better.

FTR, I'm running the modified machine through staging to make sure that the normal win32 tests don't break.

We can't register it as Nightly since in other release branches the branding is different (even though the executable is still firefox.exe).

Comment 12

[Armen [:armenzg]]

We had a meeting today and Q will be setting t-w864-ix-042 the way that we believe should work.
jimm will be handing me an Aurora build (rather than Nightly build) and see if it would work as expected (even though we agreed an app name that is not related to any branch IIRC).

Comment 13

[Jim Mathies [:jimm]]

https://tbpl.mozilla.org/?tree=Try&rev=75d0b6cc032b

Nightly try build re-branded as Aurora.

Comment 14

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #13)
> https://tbpl.mozill...
> 
> Nightly try build re-branded as Aurora.

Oops, I didn't realize I had an old patch queue applied when I did that. Fired off another build, should be ready in a couple hours - 

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

Comment 15

[Armen [:armenzg]]

I have set t-w864-ix-001 as well on the side for Q to test on.

Comment 16

[Armen [:armenzg]]

Attachment: failing log

The job did not succeed on t-w864-ix-001.
jimm, would you please be able to have a look at the log?

We can loan the machine to help debug the issue.

I've run the following (the C:\slave\test path is needed since we added firewall exceptions hardcoded to that path):
cd C:\slave\test
rmdir /s /q build scripts
C:\mozilla-build\hg\hg.exe clone http://hg.mozilla.org/users/armenzg_mozilla.com/mozharness scripts
c:/mozilla-build/python27/python -u scripts/scripts/desktop_unittest.py --cfg  unittests/win_unittest.py --mochitest-suite metro-immersive --download-symbols ondemand --installer-url http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.win32.zip --test-url http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.win32.tests.zip --no-read-buildbot-config

The log comes from:
C:\slave\test\logs\log_info.log

On another note:
Q: is t-w864-ix-001 in a different network? I can't reach files from ftp/stage e.g.:
http://stage.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b49a0bd88fc6/try-win32

I've workaround it by putting those files on people.mozilla.com:
http://people.mozilla.com/~armenzg/metro_aurora_build/

Comment 17

[Armen [:armenzg]]

It seems that IE is the default browser on the machine:
http://cl.ly/O4BP

Comment 18

[Armen [:armenzg]]

Q: gentle ping about comment 16.

Comment 19

[Amy Rich [:arr] [:arich]]

armen: t-w864-ix-001 is on the same network as all of the other w864 talos machines.

Comment 20

[Armen [:armenzg]]

(In reply to Amy Rich [:arich] [:arr] from comment #19)
> armen: t-w864-ix-001 is on the same network as all of the other w864 talos
> machines.

Thanks arr! I wonder why I am not able to reach ftp files as the other win8 machines.

I guess I also need an answer wrt to comment 17 (IE being marked as the default browser)

Comment 21

[Q]

Sorry Armen. I missed that comment. I will look at the machine tonight or first thing tomorrow

Comment 22

[Q]

Attachment: Reged nightly build

Comment 23

[Q]

Hey folks this turned out to be a problem with cltbld being a local user. The xml that that registered the default programs was being pulled from the a domain network location. The gpo now checks a local copy that dynamically placed via gpo during boot. seems to be working: https://bug854905.bugzilla.mozilla.org/attachment.cgi?id=735303

Comment 24

[Armen [:armenzg]]

Attachment: failing log

The log is failing but I don't know why.

I can now see the correct association now:
http://cl.ly/OAry

Steps followed:
cd C:\slave\test
rmdir /s /q build scripts
C:\mozilla-build\hg\hg.exe clone http://hg.mozilla.org/users/armenzg_mozilla.com/mozharness scripts
c:/mozilla-build/python27/python -u scripts/scripts/desktop_unittest.py --cfg unittests/win_unittest.py --mochitest-suite metro-immersive --download-symbols ondemand --installer-url http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.win32.zip --test-url http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.win32.tests.zip --no-read-buildbot-config

Comment 25

[Jim Mathies [:jimm]]

Hmm, I'm not sure, everything launched fine, but it looks like the browser never booted up or ran tests. Are you in front of this system armen? I'm curious what this run "looked like" on the machine.

Comment 26

[Jim Mathies [:jimm]]

Is this run using a release or debug build of firefox?

Comment 27

[Jim Mathies [:jimm]]

We are making progress though, when the default browser wasn't set right the run time was miniscule - 

INFO -  INFO | automation.py | Application ran for: 0:00:00.032000

In your latest run it was active for 54 seconds.

Comment 28

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #26)
> Is this run using a release or debug build of firefox?

I see you were using the test auroral build. Why don't we start with a release build off mc for testing purposes.

Comment 29

[Armen [:armenzg]]

Adding :aki to see if he can't give us a hint on why mozharness does not get all of the output (I'm opening logs\log_info.log which is the largest file).

I just realized that there is a bunch of code that does not make it into the logs but only shows up on CMD.
This is why we get a T-FAIL since mozharness cannot match the logs for results.
...
14:55:15     INFO -  INFO | metrotestharness.exe | Waiting on child process...
... a bunch of code that is not in the log.
TEST-INFO | checking window state

INFO TEST-START | Shutdown
Browser Chrome Test Summary
        Passed: 327
        Failed: 33
        Todo: 1

*** End BrowserChrome Test Results ***
[ A 9 3 7 A B 0 ]   M e t r o W i d g e t : : D e s t r o y   m W n d = 0   t y
p e = 0
 M e t r o A p p S h e l l : : E x i t
 [ 6 A 8 C D 0 0 ]   M e t r o W i d g e t : : D e s t r o y   m W n d = 6 0 2 C
 C   t y p e = 0
 m o z i l l a : : w i d g e t : : w i n r t : : M e t r o A p p : : S h u t d o
 w n X P C O M :   I s M a i n T h r e a d : 1   T h r e a d I d : 5 C 4
 m o z i l l a : : w i d g e t : : w i n r t : : F r a m e w o r k V i e w : : U
 n i n i t i a l i z e
 m o z i l l a : : w i d g e t : : w i n r t : : M e t r o I n p u t : : ~ M e t
 r o I n p u t
 [ 6 A 8 C 1 5 0 ]   M e t r o W i d g e t : : D e s t r o y   m W n d = 0   t y
 p e = 4
 M e t r o A p p S h e l l : : E x i t
 m o z i l l a : : w i d g e t : : w i n r t : : F r a m e w o r k V i e w : : O
 n W i n d o w A c t i v a t e d
 E x i t i n g   F r a m e w o r k V i e w : : R u n ( )
 m o z i l l a : : w i d g e t : : w i n r t : : F r a m e w o r k V i e w : : U
 n i n i t i a l i z e
 E x i t i n g   C o r e A p p l i c a t i o n : : R u n
 14:56:09     INFO -  INFO | metrotestharness.exe | Exiting.

Comment 30

[Jim Mathies [:jimm]]

I brought that log output over to the correct console via bug 855407. But maybe it needs to be routed someplace else or picked up in some way.

Comment 31

[Jim Mathies [:jimm]]

background: the mozilla test harness (desktop_unittest.py?) doesn't launch the browser. It launches metrotestharness.exe, which makes a request to Windows to launch the browser. metrotestharness and firefox communicate via a tests.ini file the harness writes out and the browser reads in. Through that I'm passing the console id that metrotestharness is attached to. The browser attaches to that console when it starts up so test output ends up in the right console window.

Comment 32

[Aki Sasaki (not active)]

Cool, I hope that fixes it.

Comment 33

[Armen [:armenzg]]

jimm, would you mind borrowing the machine and trying out the steps in here?

The log should show up inside of logs\log_info.log

(In reply to Armen Zambrano G. [:armenzg] from comment #24)
> Steps followed:
> cd C:\slave\test
> rmdir /s /q build scripts
> C:\mozilla-build\hg\hg.exe clone
> http://hg.mozilla.org/users/armenzg_mozilla.com/mozharness scripts
> c:/mozilla-build/python27/python -u scripts/scripts/desktop_unittest.py
> --cfg unittests/win_unittest.py --mochitest-suite metro-immersive
> --download-symbols ondemand --installer-url
> http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.
> win32.zip --test-url
> http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.
> win32.tests.zip --no-read-buildbot-config

Comment 34

[Jim Mathies [:jimm]]

(In reply to Aki Sasaki [:aki] from comment #32)
> Cool, I hope that fixes it.

It hasn't, that work landed a few weeks ago.

Comment 35

[Jim Mathies [:jimm]]

(In reply to Armen Zambrano G. [:armenzg] from comment #33)
> jimm, would you mind borrowing the machine and trying out the steps in here?
> 
> The log should show up inside of logs\log_info.log
> 
> (In reply to Armen Zambrano G. [:armenzg] from comment #24)
> > Steps followed:
> > cd C:\slave\test
> > rmdir /s /q build scripts
> > C:\mozilla-build\hg\hg.exe clone
> > http://hg.mozilla.org/users/armenzg_mozilla.com/mozharness scripts
> > c:/mozilla-build/python27/python -u scripts/scripts/desktop_unittest.py
> > --cfg unittests/win_unittest.py --mochitest-suite metro-immersive
> > --download-symbols ondemand --installer-url
> > http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.
> > win32.zip --test-url
> > http://people.mozilla.com/~armenzg/metro_aurora_build/firefox-23.0a1.en-US.
> > win32.tests.zip --no-read-buildbot-config

I know nothing about build's mozharness code so I'm not sure I'm the best person to look at this. I can try though. Is there anyone who understands logging in mozharness we can cc into the bug?

Comment 36

[Aki Sasaki (not active)]

That's me.
It basically opens a subprocess that eats both STDOUT and STDERR for log parsing, so if the script is outputting to those, like all unix scripts do, then we're golden.

Sounds like it's redirecting output to a console or something though ?

Comment 37

[Jim Mathies [:jimm]]

(In reply to Aki Sasaki [:aki] from comment #36)
> That's me.
> It basically opens a subprocess that eats both STDOUT and STDERR for log
> parsing, so if the script is outputting to those, like all unix scripts do,
> then we're golden.
> 
> Sounds like it's redirecting output to a console or something though ?

Yep. For reference:

run_command:
http://mxr.mozilla.org/build/source/mozharness/scripts/desktop_unittest.py#347
open process:
http://mxr.mozilla.org/build/source/mozharness/mozharness/base/script.py#558
read std out:
http://mxr.mozilla.org/build/source/mozharness/mozharness/base/script.py#573

On the browser side we attach to the console, not to stdout of the metrotestharness process. 

http://mxr.mozilla.org/mozilla-central/source/browser/app/nsBrowserApp.cpp#110

I'm not sure something like this is possible, since the processes are not related. We do have the browser process handle in metrotestharness, so maybe we can do something with that.

Comment 38

[Aki Sasaki (not active)]

If we're logging to console + a file, we can, at the very least, cat the file at the end.

Comment 39

[Jim Mathies [:jimm]]

(In reply to Aki Sasaki [:aki] from comment #38)
> If we're logging to console + a file, we can, at the very least, cat the
> file at the end.

I think we might be able to get the stdout handles linked up, but it will take some experimenting to see. If not something like this might be our next best solution.

Armen, I think we can close this bug out as fixed. Q got the default browser working. I'll file a follow up in the parent about experimenting around with sharing handles between processes and in getting python's popen stuff working with metro land.

Comment 40

[Armen [:armenzg]]

Q, I will re-open this bug or file another bug to deploy the change you wrote.