Closed Bug 1261188 Opened 8 years ago Closed 7 years ago

test_Edge_availability.js fails on Win10 in automation

Categories

(Firefox :: Migration, defect)

Product:
Firefox
Component:
Migration
Platform:
Unspecified
Windows 10
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox48 --- affected

People

(Reporter: RyanVM, Assigned: grenade)

References

Details

Attachments

(3 files)

Bug 1261188 - support test suite setup commands
59 bytes, text/x-review-board-request
dustin
: review-
Details
Bug 1261188 - remove edge data migrator assertion
59 bytes, text/x-review-board-request
Gijs
: review+
Details
Bug 1261188 - enable xpcshell tests on tc win
59 bytes, text/x-review-board-request
jmaher
: review+
Details 
Windows 10 is available for opt-in on Try (albeit with a whopping one total slave). I've been toying around with it to see where things stand and this failure was one that popped up.

https://treeherder.mozilla.org/logviewer.html#?job_id=18578946&repo=try

13:12:07     INFO -  TEST-START | browser/components/migration/tests/unit/test_Edge_availability.js
13:12:07  WARNING -  TEST-UNEXPECTED-FAIL | browser/components/migration/tests/unit/test_Edge_availability.js | xpcshell return code: 0
13:12:07     INFO -  TEST-INFO took 136ms
13:12:07     INFO -  >>>>>>>
13:12:07     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
13:12:07     INFO -  (xpcshell/head.js) | test run_next_test 0 pending (2)
13:12:07     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
13:12:07     INFO -  running event loop
13:12:07     INFO -  browser/components/migration/tests/unit/test_Edge_availability.js | Starting
13:12:07     INFO -  (xpcshell/head.js) | test pending (2)
13:12:07  WARNING -  TEST-UNEXPECTED-FAIL | browser/components/migration/tests/unit/test_Edge_availability.js |  - Edge should be available for migration if and only if we're on Win 10+ - false == true
13:12:07     INFO -      C:/slave/test/build/tests/xpcshell/tests/browser/components/migration/tests/unit/test_Edge_availability.js:null:10
13:12:07     INFO -      _run_next_test@C:\slave\test\build\tests\xpcshell\head.js:1540:9
13:12:07     INFO -      do_execute_soon/<.run@C:\slave\test\build\tests\xpcshell\head.js:692:9
13:12:07     INFO -      _do_main@C:\slave\test\build\tests\xpcshell\head.js:209:5
13:12:07     INFO -      _execute_test@C:\slave\test\build\tests\xpcshell\head.js:533:5
13:12:07     INFO -      @-e:1:1
13:12:07     INFO -  exiting test
13:12:07     INFO -  (xpcshell/head.js) | test run_next_test 0 finished (2)
13:12:07     INFO -  Unexpected exception 2147500036
13:12:07     INFO -  undefined
13:12:07     INFO -  exiting test
13:12:07     INFO -  "CONSOLE_MESSAGE: (error) [JavaScript Error: "Error reading typed URL history: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWindowsRegKey.open]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource:///modules/MSMigrationUtils.jsm :: getTypedURLs :: line 666"  data: no]" {file: "resource:///modules/MSMigrationUtils.jsm" line: 711}]
13:12:07     INFO -  getTypedURLs@resource:///modules/MSMigrationUtils.jsm:711:5
13:12:07     INFO -  EdgeTypedURLMigrator.prototype._typedURLs@resource://app/components/EdgeProfileMigrator.js:98:26
13:12:07     INFO -  EdgeTypedURLMigrator.prototype.exists@resource://app/components/EdgeProfileMigrator.js:104:5
13:12:07     INFO -  EdgeProfileMigrator.prototype.getResources/<@resource://app/components/EdgeProfileMigrator.js:420:32
13:12:07     INFO -  EdgeProfileMigrator.prototype.getResources@resource://app/components/EdgeProfileMigrator.js:420:10
13:12:07     INFO -  PMB__getMaybeCachedResources@resource:///modules/MigrationUtils.jsm:359:51
13:12:07     INFO -  this.MigratorPrototype.sourceExists@resource:///modules/MigrationUtils.jsm:335:25
13:12:07     INFO -  MU_getMigrator@resource:///modules/MigrationUtils.jsm:520:7
13:12:07     INFO -  @C:/slave/test/build/tests/xpcshell/tests/browser/components/migration/tests/unit/test_Edge_availability.js:8:18
13:12:07     INFO -  TaskImpl_run@resource://gre/modules/Task.jsm:319:40
13:12:07     INFO -  TaskImpl@resource://gre/modules/Task.jsm:280:3
13:12:07     INFO -  createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:254:14
13:12:07     INFO -  Task_spawn@resource://gre/modules/Task.jsm:168:12
13:12:07     INFO -  _run_next_test@C:\\slave\\test\\build\\tests\\xpcshell\\head.js:1540:9
13:12:07     INFO -  do_execute_soon/<.run@C:\\slave\\test\\build\\tests\\xpcshell\\head.js:692:9
13:12:07     INFO -  _do_main@C:\\slave\\test\\build\\tests\\xpcshell\\head.js:209:5
13:12:07     INFO -  _execute_test@C:\\slave\\test\\build\\tests\\xpcshell\\head.js:533:5
13:12:07     INFO -  @-e:1:1
13:12:07     INFO -  "
13:12:07     INFO -  <<<<<<<
Looks like we just need to deal with there being no typed URL history. IIRC this has come up before but I don't have a bug number handy right now. Will look.
Flags: needinfo?(gijskruitbosch+bugs)
See Also: → 1255526
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=b56d9b420361

has the patch for bug 1255526. I *think* that might fix it, or at least fail differently, but it's annoying because the "unexpected exception" is not actually logged by xpcshell - just the caught one that happens earlier. :-\

Failing differently would be because after the change from that bug I expect we'll find 0 history entries on the machines on which we run infrastructure, and that will then produce a lack of history to import... We'll tackle that when we get there. :-\
(In reply to :Gijs Kruitbosch from comment #2)
> remote:  
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=b56d9b420361
> 
> has the patch for bug 1255526. I *think* that might fix it, or at least fail
> differently, but it's annoying because the "unexpected exception" is not
> actually logged by xpcshell - just the caught one that happens earlier. :-\
> 
> Failing differently would be because after the change from that bug I expect
> we'll find 0 history entries on the machines on which we run infrastructure,
> and that will then produce a lack of history to import... We'll tackle that
> when we get there. :-\

This didn't really help, from looking at:

http://archive.mozilla.org/pub/firefox/try-builds/mozci-bot@mozilla.com-b56d9b4203613cb77ddfbd77616154bd4d5e333a/try-win64/try_win10_64_test-xpcshell-bm109-tests1-windows-build0.txt.gz
So, after talking to Matt a bit, the ideal solution here is to make sure the machine has some Edge history (and thereby cookies, favourites, etc.) of some description.

Failing that, the test does not do anything useful, so if it's holding something up, rs=me to temporarily disable it, provided someone pings me when we're ready to take such steps on infra as are necessary to re-enable it.
Flags: needinfo?(gijskruitbosch+bugs)
Q, what would it take to pre-populate some Edge history on our Win10 test slave(s) so this test can do something useful?
Flags: needinfo?(q)
It took a bit of testing but it looks possible to populate. I may need to test the feature by hand to make sure it is legit for the import.
Flags: needinfo?(q)
Q: if you can give me some idea of what needs to happen to get some prepopulated history, i can work on getting that integrated into the test in question.
Flags: needinfo?(q)
sorted now. it was a case of just adding some registry entries. eg:

reg add "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TypedURLs" /f /v url1 /t REG_SZ /d "http://mozilla.org/"
reg add "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TypedURLs" /f /v url2 /t REG_SZ /d "http://firefox.com/"
Flags: needinfo?(q)
Gijs:

in taskcluster, we're now able to get past the missing history issue (using the registry hacks above). The next failure we get is "All the data types we expect should be available" (see: https://dxr.mozilla.org/mozilla-central/source/browser/components/migration/tests/unit/test_Edge_availability.js#17).

test exception (https://public-artifacts.taskcluster.net/C_6FiEdOTOSOCyIK_ohoHQ/0/public/logs/live_backing.log):

13:13:22  WARNING -  TEST-UNEXPECTED-FAIL | browser/components/migration/tests/unit/test_Edge_availability.js |  - All the data types we expect should be available - 4 == 54
13:13:22     INFO -      Z:/task_1485435210/build/tests/xpcshell/tests/browser/components/migration/tests/unit/test_Edge_availability.js:null:16
13:13:22     INFO -      _run_next_test@Z:\task_1485435210\build\tests\xpcshell\head.js:1566:9
13:13:22     INFO -      run@Z:\task_1485435210\build\tests\xpcshell\head.js:713:9
13:13:22     INFO -      _do_main@Z:\task_1485435210\build\tests\xpcshell\head.js:210:5
13:13:22     INFO -      _execute_test@Z:\task_1485435210\build\tests\xpcshell\head.js:545:5
13:13:22     INFO -      @-e:1:1

it looks like the expected types are: COOKIES | BOOKMARKS | HISTORY | PASSWORDS

do you have any ideas on how we can automate creation of the missing data types for this test?

there is a try push which shows how we integrate the typedURLs history here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b124e658875958003150af1ad328f000d8bd630f&filter-tier=1&filter-tier=2&filter-tier=3&group_state=expanded (chunk 1 of the Win 10 xpcshell tests is the interesting one)
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Rob Thijssen (:grenade - GMT) from comment #9)
> it looks like the expected types are: COOKIES | BOOKMARKS | HISTORY |
> PASSWORDS
> 
> do you have any ideas on how we can automate creation of the missing data
> types for this test?

Short of actually starting Edge and creating these things? Not easily / meaningfully (we'd mostly test that our scripts to generate things satisfy our code, not that the code we have actually does anything meaningful with 'real' data).

If we have no way to do that, I would r+ a patch to remove that part of the test.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(rthijssen)
removed the migrator assertion.
Flags: needinfo?(rthijssen)
Assignee: nobody → rthijssen
Status: NEW → ASSIGNED
Comment on attachment 8831099 [details]
Bug 1261188 - support test suite setup commands

https://reviewboard.mozilla.org/r/107750/#review108884

::: taskcluster/ci/test/tests.yml:1205
(Diff revision 1)
> +            windows10.*:
> +                # this powershell command ensures that the MS Edge AppX package and Edge profile settings folders are available to the task user. See bug 1326434
> +                - 'powershell -command "& {& Add-AppxPackage -DisableDevelopmentMode -Register C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppXManifest.xml -Verbose }"'
> +                # these registry entries mock some typed url history for the task user in Edge. See bug 1261188
> +                - 'reg add "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TypedURLs" /f /v url1 /t REG_SZ /d "http://mozilla.org/"'
> +                - 'reg add "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TypedURLs" /f /v url2 /t REG_SZ /d "http://firefox.com/"'

I really wish we could make these commands into a setup script vs raw commands in tests.yml- curious what dustin thinks.  Either way, it is awesome to find a solution here
Comment on attachment 8831101 [details]
Bug 1261188 - enable xpcshell tests on tc win

https://reviewboard.mozilla.org/r/107754/#review108886

excited to see this!
Attachment #8831101 - Flags: review?(jmaher) → review+
Comment on attachment 8831099 [details]
Bug 1261188 - support test suite setup commands

https://reviewboard.mozilla.org/r/107750/#review108884

> I really wish we could make these commands into a setup script vs raw commands in tests.yml- curious what dustin thinks.  Either way, it is awesome to find a solution here

yes. earlier attempts did try to make use of the test preflight scripts but for whatever reason, the python parent process was unable to launch some of the commands. in fact the specific command we had trouble with was `start microsoft-edge:`, where i believe the python parent process was choking on the trailing colon strangely required by ms' new AppX package launch mechanism. when i wasn't able to fix or work around that, i opted to put the setup commands here in the test task definition, but i'm also hoping for feedback on whether or not this is a good idea.
Comment on attachment 8831100 [details]
Bug 1261188 - remove edge data migrator assertion

https://reviewboard.mozilla.org/r/107752/#review108890

rs=me
Attachment #8831100 - Flags: review?(gijskruitbosch+bugs) → review+
Comment on attachment 8831099 [details]
Bug 1261188 - support test suite setup commands

https://reviewboard.mozilla.org/r/107750/#review109482

::: taskcluster/ci/test/tests.yml:1205
(Diff revision 1)
> +            windows10.*:
> +                # this powershell command ensures that the MS Edge AppX package and Edge profile settings folders are available to the task user. See bug 1326434
> +                - 'powershell -command "& {& Add-AppxPackage -DisableDevelopmentMode -Register C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppXManifest.xml -Verbose }"'
> +                # these registry entries mock some typed url history for the task user in Edge. See bug 1261188
> +                - 'reg add "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TypedURLs" /f /v url1 /t REG_SZ /d "http://mozilla.org/"'
> +                - 'reg add "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TypedURLs" /f /v url2 /t REG_SZ /d "http://firefox.com/"'

Joel knows me well :)

From what I understand, it's only possible to run these commands from a Go process (or presumably C#, but critically for us not from Python).  That is kind of shocking, but I have no evidence from which to argue the contrary.

This is definitely test-specific setup -- the sort of stuff that mozharness exists to do.  Installing Edge is certainly in the domain of system configuration, but creating a profile populated with a few typed URLs is quite deeply into test harness responsibility.

How about this: let's build a small Go binary that can run these three commands, upload that to tooltool, and then write some mozharness code to download that binary and run it.  I'm open to other ideas, too.
Attachment #8831099 - Flags: review?(dustin) → review-
ok. in order to be clear about what works and doesn't and what issues we currently have:

- all three commands must be run by the task user because they affect user specific profiles and registry settings. we wouldn't have these problems in buildbot because the same user, cltbld, is used for every task. so once the profile is set up, it continues to work for the life of the instance.

- regarding the first command: because the user is newly created for the task, some of its profile is missing when the task is triggered (specifically: %LOCALAPPDATA%\Packages and its skeleton contents). when the user manually logs in for the first time, the os would normally handle creation of this profile directory tree. it could be argued that this command should form part of the user creation mechanism inside the generic worker or later in the taskcluster worker. since mozharness configs to my knowledge don't have any functionality currently built into them for management and maintenance of task user accounts, i'd argue that adding that to mozharness is beyond the scope of dealing with the issue in this bug. attempts to run the command from the python preflight scripts report success in the build logs but do not result in creation of the missing profile folders so is ineffective.

- the following two commands are just setting registry keys under HKEY_CURRENT_USER. they actually will run successfully when triggered as part of the mozharness preflight scripts and i'm happy to move them there. the only niggling imperfection there is that mozharness preflight scripts have to be run for every test sharing the unittest mozharness config, whereas the implementation reviewed would have limited it to xpcshell tests only (still imperfect since its only chunk 1 of that suite which needs the keys set).

Gijs has rightly questioned the value of all of the Windows 10 Edge specific tests since they cannot mock the real world use cases they were envisaged to test.

i certainly don't have the expertise to write a go app that manages process execution. knowing how many yaks pmoore has had to shave to make generic worker do this reliably on our various operating system versions, i wouldn't touch it with a barge pole. taking into account that we are trying to fix a few tests that we don't even trust the validity of, i think it wouldn't be a brilliant use of time.

in summary, i think a pragmatic fix at this stage would be to add execution of the powershell command to the generic worker task user creation sequence and move the registry key settings to mozharness preflight scripts.

any objections?
Flags: needinfo?(pmoore)
Flags: needinfo?(jmaher)
Flags: needinfo?(dustin)
I think that is a reasonable next step.
Flags: needinfo?(jmaher)
That sounds reasonable to me
Flags: needinfo?(dustin)
Can we run the step as a separate command, from outside mozharness? That would overcome the problem that it is being called from mozharness, and also keep transparancy of the fact it is being called (rather than being hidden in generic worker internals). This has the other advantage that it doesn't bind some strange pretest requirement of some windows 10 gecko tests to the generic worker.

If that doesn't work, we can look at adding a feature to generic worker to run arbitrary code when creating tasks, but that would be a fall-back option in my opinion, if we can't execute this at task execution time. The problem is, this would be something specific to having Edge installed, running on Windows, probably Windows 10 at that, and then only for these Windows tests - whereas generic worker is something for all versions of Windows, all possible tasks (not just gecko related) and therefore it feels like the wrong place to embed this logic, even if it appears to be the simplest...

Maybe we can chat on irc / vidyo tomorrow - I only have a cursory understanding of the problem space, so maybe I'm seeing problems that don't exist. :-)
Flags: needinfo?(pmoore)
pmoore: and now we've come full circle. the patch i submitted for review, did exactly what you're suggesting. see https://bugzilla.mozilla.org/attachment.cgi?id=8831099
I'm working on a generic worker feature to be able to configure the worker to run arbitrary code at task user generation time. I'm going to finish that off, but having slept on the matter, I do feel that what grenade has done, creating a separate task step, is in fact a better solution.

First of all, anything we run inside the worker, will be opaque to all users. They won't see these steps, they won't have logs for them, and it will be very difficult for them to change them.

I agree that ideally it would be part of the test harness, but since that has turned out to be tricky, I really do think having as part of the task definition is the next best step. Hiding it in the worker only obscures the fact this code is running, and if it needs altering/iterating on, it is going to be very hard for users to see what goes on, and what output it produces. It also prevents other people from seeing the issue and also taking a stab at making it a step in the test harness, which I think is our ultimate goal.

So - I will continue to work on this feature, but I'd like you to still consider whether grenade's existing patch could be reconsidered. Thanks!
Flags: needinfo?(jmaher)
Flags: needinfo?(dustin)
My understanding is that rob is writing a script to solve the following:

> some of its profile is missing when the task is triggered (specifically: %LOCALAPPDATA%\Packages and its skeleton contents)

which seems to be roughly equivalent to copying /etc/skel into a new home directory on UNIX.  As such, it makes sense to me as a means of "doing user creation well". I think it's sensible for it to be a part of the worker configuration, just like all the dsc/occ setup.  On Linux and OS X I would expect a similar script (and as I mentioned elsewhere, I suspect bug 1314977 is a consequence of not having this script).

I agree it's a gray line, but from my perspective this functionality is on the "light gray" side :)
Flags: needinfo?(dustin)
I have no desires either way- the more we can expose things to the in-tree configs the better, but at the same time, the more hacks we do the worse.
Flags: needinfo?(jmaher)
Commit pushed to master at https://github.com/taskcluster/generic-worker

https://github.com/taskcluster/generic-worker/commit/24a98f108f40e8bbef05053ac59fc94a104999d4
Bug1261188 - allow arbitrary commands to be run after task user is created (#38)
Rob, I've added the feature in https://github.com/taskcluster/generic-worker/commit/24a98f108f40e8bbef05053ac59fc94a104999d4

You just need to create a script on the worker, and put the full path to that script in a config setting "runAfterUserCreation".

Probably best to avoid spaces in the path to that script, just to be safe.
Flags: needinfo?(rthijssen)
Something weird going on here:
https://papertrailapp.com/systems/681923702/events

I'll have a look at this tomorrow. I see in this log, four users being created in sequence, without a task ever getting claimed. Desktops are opened and not closed - so there must be some condition causing some task creation loop to occur. I'll update as soon as I have more data.
so the task user init script stuff is now working. however, the powershell command to create the profile directory structure which was working before (https://public-artifacts.taskcluster.net/X433SyLDSNa36sv4DQ1SrA/0/public/logs/live_backing.log) has stopped working (https://papertrailapp.com/groups/2488493/events?highlight=765258025316569121&focus=765258025316569121&q=i-032272b9896954054). will have to debug further to understand why.
Flags: needinfo?(rthijssen)
Hey Rob,

That looks similar to an issue I hit in the generic worker CI tests, solved in this commit:
https://github.com/taskcluster/testrepo/commit/a079453bd5eea98df5ee2f300544b9b2b937fbf9

I got the fix from:
https://blogs.technet.microsoft.com/michaelgriswold/2015/07/27/powershell-failing-in-a-task-sequence/

Hope that helps!
Pete
Flags: needinfo?(rthijssen)
pmoore: i think the problem is actually related to https://bugzilla.mozilla.org/show_bug.cgi?id=1337132#c18

the error is access denied rather than missing ps modules. if a previous task user has created an appdata folder at z:\appdata then it would explain why we get access denied when the current task user tries to create the edge profile. i think once g-w is patched to create appdata under that task folder, the problems here will fix themselves.
Flags: needinfo?(rthijssen)
the new g-w 8.0.1 creates the task user and calls LoadUserProfile which results in the creation of both
- C:\Users\task_xxx\AppData\Local
- C:\Users\task_xxx\AppData\Roaming
crucially, it does *not* result in the creation of C:\Users\task_xxx\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe. if a user logs on manually to windows 10 after creation of the account and no call to LoadUserProfile, then C:\Users\task_xxx\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe *is* created by some system process during the first logon. normally, we would be able to correct this by running the powershell command: `Add-AppxPackage -DisableDevelopmentMode -Register C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppXManifest.xml`. however, this requires the pre-existence of some other parts of the user profile. we are currently in a nasty state because the parts of the profile required exist in C:\Users\task_xxx\AppData however, subsequent to the g-w call to LoadUserProfile, we also call SHSetKnownFolderPath for both LocalAppData and RoamingAppData, changing those locations to Z:\task_xxx\AppData\Local and Z:\task_xxx\AppData\Roaming respectively. meaning we now have part of the user profile on the c: drive and new parts on the z: drive. the powershell call fails because it expects to find everything in one place. our options are not very good. either we have to find a way to move the complete user profile when changing known folder locations for local and roaming appdata (not as simple as it sounds, because the user hive stored in the profile is in use when SHSetKnownFolderPath is called, so a shadow copy is needed) or we have to not change those folder locations.
Depends on: 1361680
there are two test failures in chunk 1 of xpcshell (after disabling some of the edge import assertions):
Examples at: https://treeherder.mozilla.org/#/jobs?repo=try&revision=43ed0c81835ac82c0811dd19882c51f42321a0b5&group_state=expanded&filter-searchStr=windows10&selectedJob=96185813

- Edge should be available for migration if and only if we're on Win 10+ (bug 1361680)
- Migrated the expected number of cookies - 0 == 1 (bug 1361675)
Depends on: 1361675
the cookies issue is fixed, we still have the edge migration failure.
(In reply to Joel Maher ( :jmaher) from comment #36)
> the cookies issue is fixed, we still have the edge migration failure.

As noted in bug 1361680, I think we should just kill that test.
Note, I have rewritten the generic worker engine in the meantime, such that it actually performs a real winlogon/gina logon. As such, I suspect the Packages dir will be crated by the userinit.exe execution[1].

From generic worker version 9 onwards, we no longer create a logon session using LogonUser[2] and LoadUserProfile[3], but instead generic-worker runs as a windows service, generates a task user, then reboots (setting winlogon registry entries to enable winlogon autologon to interactive session) as the newly generated task user, thereby simulating a real user logon experience, rather than just simulating in the current desktop session.

In other words, once we've upgraded generic worker to a version > 9 (just made release 10.0.0 today[4], that I am testing) I suspect we'll get the default Edge profile for free.

If that turns out to be the case, we should be able to drop the taskinit script[5].


-----

[1] https://technet.microsoft.com/en-us/library/cc939862.aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa378184(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/bb762281(v=vs.85).aspx
[4] https://github.com/taskcluster/generic-worker/releases/tag/v10.0.0
[5] https://github.com/mozilla-releng/OpenCloudConfig/blob/759d6ac0cecea78ba02df977c09f24dae258986a/userdata/Manifest/gecko-t-win10-64.json#L536-L548
xpcshell is running green on win7/win10 in taskcluster- :grenade is there more work to do here?
Flags: needinfo?(rthijssen)
I think this got fixed in bug 1361680 and can be closed now, but I'll leave :grenade to confirm. :-)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(rthijssen)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: