The system clock and other taskbar items causes false-positives for mozscreenshots comparisons. It would make things much easier for screenshots comparisons if the task bar was collapsed. Could the taskbar be collapsed by default on all Windows machines please? https://www.windowscentral.com/how-auto-hide-taskbar-windows-10-anniversary-update

NI all three windows folks since this will need to be addressed on all three types of platform.

if anyone knows of a cmd or powershell command to hide the taskbar on win 10, please paste it into the comments here. i'm struggling to find a scriptable solution.

https://www.tenforums.com/tutorials/23817-turn-off-auto-hide-taskbar-desktop-mode-windows-10-a.html mentions a registry key to set though I didn't test it.

i played with that registry key too but have been unable to figure out the right binary values, or the right command to set it. in powershell it should be something like: Set-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3 -Name Settings -Value ([byte[]](0x48,0x0,0x0,0x0,0x254,0x255,0x255,0x255,0x2,0x0,0x0,0x0,0x3,0x0,0x0,0x0,0x62,0x0,0x0,0x0,0x40,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x216,0x2,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x3,0x0,0x0,0x96,0x0,0x0,0x0,0x1,0x0,0x0,0x0)) but the above throws casting errors when i run it

It looks like you have decimal numbers prefixed with 0x rather than hex numbers (e.g. probably 0x255 should be 0xFF). I think it might be safer to read the full binary value, set the 9th byte, and write back the binary value, rather than having a copy of the full binary value in the powershell code. This would help protect against if those other values change for some reason, and would isolate the change to making sure only the 9th byte was set.

Something like: $key_path = 'HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3' $val = (Get-ItemProperty -Path $key_path)."Settings" $val[8]=3 Set-ItemProperty -Path $key_path -Name Settings -Value $val

Note, when not running as current user (i.e. creating task users) this will need to be executed after the task user is created. I believe it requires explorer to be restarted too. A script specified by the "runAfterUserCreation" generic-worker property is executed as the task user, after the user has been created and the machine has been rebooted into that user. Therefore, if this mechanism is used to trigger the powershell, it will need to take care of restarting explorer too.

(In reply to Pete Moore [:pmoore][:pete] from comment #7) > Therefore, if this mechanism is used to trigger the powershell, it will need to take care of restarting explorer too. Looks like the following should be enough to restart explorer, since it automatically starts up if it is stopped: Stop-Process -ProcessName explorer

Is this something that still needs investigation? There were some hacks we used for 8.1 but I don't know if the NI for me is still needed.

Q: this was to make sure we were doing it through GPO.

see c#10

This can be added for the few talos windows 10 machines via GPO the rest will have to be handled in the DSC configs for cloud / new hardware

This bug update got missed last week when this went out. New GPO created Hide_taskbar_win10 This GPO creates a scheduled task that runs a bat as cltbld that adds the following to the registry: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3] "Settings"=hex:30,00,00,00,fe,ff,ff,ff,03,02,00,00,03,00,00,00,3e,00,00,00,28,\ 00,00,00,00,00,00,00,88,04,00,00,40,06,00,00,b0,04,00,00,60,00,00,00,01,00,\ 00,00 It then HUPS explorer and makes sure that the schedule task is deleted and a done.ed marker file is written to c:\gpo\filies\hide_taksbar\ (batch and reg file lives there too). If the done.end file exists then the schedule task will not recreate

The key in the binary block: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3] "Settings"=hex:30,00,00,00,fe,ff,ff,ff,03,02,00,00,03,00,00,00,3e,00,00,00,28,\ 00,00,00,00,00,00,00,88,04,00,00,40,06,00,00,b0,04,00,00,60,00,00,00,01,00,\ 00,00 is the first 03 value (ff,ff,03,02) that value changed from 02 to 03 auto hides the taskbar

Confirmed this was rolled out to win 10 machines and is effective.

thanks pete for the ideas above. works a treat, will include in next win 10 deployment.

now also deployed to gecko-t-win10-64 and gecko-t-win10-64-gpu https://github.com/mozilla-releng/OpenCloudConfig/commit/5d58b5bad3f46749873ae39f086100f9867d05c8

This seems to be broken, I see the taskbar in recent screenshots of failures on try: https://queue.taskcluster.net/v1/task/NVc_ro25Rc2CjSg-jKh-Jw/runs/0/artifacts/public/test_info/mozilla-test-fail-screenshot_50oowi.png ^ from https://treeherder.mozilla.org/#/jobs?repo=try&author=jmaher@mozilla.com&fromchange=4dcb574fae73c45cf5ebeb7db795a05cae79f00a&selectedJob=132181293 :grenade, did something change, do we need to reopen this bug?

pete, is there some way we can get the output from the task-user-init script that runs before the task? you mentioned in bug 1400841 that the script was returning with a non-zero error code. it would be really useful to get both stderr and stdout from the script run (running the script as an rdp'd user on the instance succeeds so we need to know what the error says when gw runs it as the task user in order to debug what's going on.

It looks like standard error and standard out are both directed to the generic worker log file.

(In reply to Pete Moore [:pmoore][:pete] from comment #20) > It looks like standard error and standard out are both directed to the > generic worker log file. These are the pertinent source code links for v8.3.0: https://github.com/taskcluster/generic-worker/blob/v8.3.0/plat_windows.go#L123 https://github.com/taskcluster/generic-worker/blob/v8.3.0/process/process_windows.go#L199

reverting to g-w 8.3.0 to see if running task-user-init.cmd under the GenericWorker user account (with runAsCurrentUser set to true) resolves the user elevation errors from the init script. https://github.com/mozilla-releng/OpenCloudConfig/commit/3b3b385d449264adba2490393795ae6b19b286aa

see bug 1396168, comment 10. currently generic worker is failing to run the task user initialisation script (which contains the command which would hide the task bar) if we can get that fixed, the taskbar hide should work as expected.

Comment on attachment 8916620 [details] Bug 1373178 - use preflight mech to hide win 10 taskbar; https://reviewboard.mozilla.org/r/187730/#review192756 ::: testing/mozharness/configs/unittests/win_taskcluster_unittest.py:273 (Diff revision 1) > + '"&{$p=\'HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3\';$v=(Get-ItemProperty -Path $p).Settings;$v[8]=3;&Set-ItemProperty -Path $p -Name Settings -Value $v;&Stop-Process -ProcessName explorer}"' > + ], > + 'architectures': ['32bit', '64bit'], > + 'halt_on_failure': True, > + 'enabled': os.environ.get('ProgramFiles(x86)', False) > + }, will the pending , break things? I noticed prior to your change there was no pending ,

Comment on attachment 8916620 [details] Bug 1373178 - use preflight mech to hide win 10 taskbar; https://reviewboard.mozilla.org/r/187730/#review192756 > will the pending , break things? I noticed prior to your change there was no pending , no should be fine. i've seen some of our devs insist on it being there as a style preference.

Pushed by jmaher@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2aa3f925ceb2 use preflight mech to hide win 10 taskbar; r=jmaher