Closed Bug 872935 Opened 7 years ago Closed 4 years ago

Mozmill update tests on Nightly cannot remove update folder since bug 572162 landed

Categories

(Mozilla QA Graveyard :: Mozmill Automation, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: whimboo, Assigned: whimboo)

References

Details

(Keywords: regression, Whiteboard: [mozmill-test-failure])

Attachments

(1 file)

Since the patches on bug 572162 have been landed on mozilla-central, our mozmill-tests can no longer remove any content inside the folder with the downloaded update data. I haven't checked yet if that's happening because we now automatically clean-up this folder. Brian or Rob, would you have an idea? Otherwise I will have to dig into the problem in a bit.

*** Removing updates staging folder 'C:\Users\mozauto\AppData\Local\Mozilla\Firefox\firefox\updates\0'
Failed to remove the update staging folder: [Error 3] The system cannot find the path specified: u'C:\\Users\\mozauto\\AppData\\Local\\Mozilla\\Firefox\\firefox\\updates\\0\\*.*'
Attached patch Patch v1Splinter Review
Given that we now re-throw the exception if we cannot delete the folder, we should make sure that the folder really exists before trying to delete it.

The patch might hide a Firefox issue but for now we could make our testruns passing again. Waiting for Rob and Brian to comment on it.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Attachment #750364 - Flags: review?(andreea.matei)
Attachment 744270 [details] [diff] is doing some magic now by removing the update folder. So it sounds like it is expected.
Flags: needinfo?(robert.bugzilla)
Flags: needinfo?(netzen)
The new folder that is used for updates looks like this:
C:\Users\Brian\AppData\Local\Mozilla\updates\EEFEA8717BC47F65
Where Brian is your username and EEFEA8717BC47F65 is the value of your TaskbarID for your installation path stored at HKEY_CURRENT_USER\Software\Mozilla\Firefox\TaskBarIDs or in HKLM first.  If no taskbar ID is found in HKLM and HKCU then it falls back to the old update directory.

See here:
https://bugzilla.mozilla.org/show_bug.cgi?id=572162#c43
Flags: needinfo?(robert.bugzilla)
Flags: needinfo?(netzen)
Summary: Update tests on Nightly cannot remove update folder since bug 572162 landed → Mozmill update tests on Nightly cannot remove update folder since bug 572162 landed
I think that change should be backed out by the way and a new patch should be landed that checks the correct dir. It should fail if the new updatedir files are missing.
(In reply to Brian R. Bondy [:bbondy] from comment #6)
> I think that change should be backed out by the way and a new patch should
> be landed that checks the correct dir. It should fail if the new updatedir
> files are missing.

Well, we get the staging path for updates from aus.getUpdatesDirectory(). Does this method no longer returns the correct path?
(In reply to Brian R. Bondy [:bbondy] from comment #5)
> HKEY_CURRENT_USER\Software\Mozilla\Firefox\TaskBarIDs or in HKLM first.  If
> no taskbar ID is found in HKLM and HKCU then it falls back to the old update
> directory.

Under which conditions could it be that no taskbar ID exists? We install Firefox silently into the temp folder. Could this be the cause why update are still stored at the old location?
Do you mean in the xpcshell tests? It does not return the hashed update dir. 
We use MOZ_UPDATE_NO_HASH_DIR to bypass that functionality.

But if in mozmilla we are using a normal install path we should use the taskbar id path.
(In reply to Brian R. Bondy [:bbondy] from comment #9)
> Do you mean in the xpcshell tests? It does not return the hashed update dir. 
> We use MOZ_UPDATE_NO_HASH_DIR to bypass that functionality.
> 
> But if in mozmilla we are using a normal install path we should use the
> taskbar id path.

No, this is for Mozmill tests. Also I'm not sure if we really want to bypass that feature. It adds another level of tests, so that we can proof it works. So why does getUpdatesDirectory() not return the hashed dir? Is there a way inside of Firefox to find out which folder is used here?
(In reply to Henrik Skupin (:whimboo) from comment #10)
> (In reply to Brian R. Bondy [:bbondy] from comment #9)

> No, this is for Mozmill tests. Also I'm not sure if we really want to bypass
> that feature. 
> It adds another level of tests, so that we can proof it works.
> So why does getUpdatesDirectory() not return the hashed dir? 

Unless you have a specific reason I'd suggest not to, with the way the xpcshell tests, we bypass it because we get a dynamic callback application and the hash of the path depends on the location of the callback application / the application being updated.

> Is there a way
> inside of Firefox to find out which folder is used here?

Yes of course you can use the directory service or you can compute it yourself like the code in test_0300_update_root_dir_migration.js does.
Product: Mozilla QA → Mozilla QA Graveyard
Mozmill is dead, but we had the same issue with our firefox-ui tests. For those I got this fixed via bug 1233679.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.