Closed Bug 1059238 Opened 10 years ago Closed 8 years ago

Intermittent test_custom_origin_uninstall_install.xul | Test timed out.

Categories

(Firefox Graveyard :: Web Apps, defect)

Product:
Firefox Graveyard
Component:
Web Apps
Platform:
x86
Windows 8
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: cbook, Assigned: myk)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on Windows]) 

WINNT 6.2 mozilla-inbound debug test mochitest-other on 2014-08-27 03:18:11 PDT for push d2f60a06625a

slave: t-w864-ix-085

https://tbpl.mozilla.org/php/getParsedLog.php?id=46849318&tree=Mozilla-Inbound



35922 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/webapps/tests/test_custom_origin_uninstall_install.xul | Test timed out.
This is happening with extremely high frequency on Windows lately. Fabrice, can you please look into this or suggest someone who might be able to? Otherwise, we'll probably need to disable in short order.
Component: General → Web Apps
Flags: needinfo?(fabrice)
Product: Toolkit → Firefox
This is a desktop runtime issue, so I'll take a look at it.
Assignee: nobody → myk
Flags: needinfo?(fabrice)
The log of a failure doesn't show anything suspicious, nor does a comparison between that log and the log of a successful test run.  And I can't reproduce locally.  So I've added some additional debugging code into this try run to get a better idea of where the failure occurs:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=42566c9462ce
Another try run with more/better logging and a possible fix:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e5961283424d
After adding a bunch more logging, https://treeherder.mozilla.org/#/jobs?repo=try&revision=954cbb148310 reveals that the second install attempt fails because WinNativeApp can't find a unique name for the Start Menu link:

>21:45:02     INFO -  OS.File.exists(C:\Documents and Settings\cltbld.T-XP32-IX-064\Start Menu\Programs\Custom Origin Test (96).lnk
>21:45:02     INFO -  OS.File.exists(C:\Documents and Settings\cltbld.T-XP32-IX-064\Start Menu\Programs\Custom Origin Test (97).lnk
>21:45:02     INFO -  OS.File.exists(C:\Documents and Settings\cltbld.T-XP32-IX-064\Start Menu\Programs\Custom Origin Test (98).lnk
>21:45:02     INFO -  OS.File.exists(C:\Documents and Settings\cltbld.T-XP32-IX-064\Start Menu\Programs\Custom Origin Test (99).lnk
>21:45:02     INFO -  WinNativeApp.install: Perform the installation in the temp directory error: No available filename for Custom Origin Test in C:\Documents and Settings\cltbld.T-XP32-IX-064\Start Menu\Programs,C:\Documents and Settings\cltbld.T-XP32-IX-064\Desktop

One possibility is that these files aren't being cleaned up from previous installations, causing the test to fail once the machine is reused enough for the test.  But there may be something else going on.

I also see this error, although I don't think it's related:

>21:34:17     INFO -  JavaScript error: http://test2.example.com/chrome/dom/tests/mochitest/webapps/head.js, line 6: TypeError: Cu is undefined
(In reply to Marco Castelluccio [:marco] from comment #309)
> Could be bug 1192825 then.

That seems likely. I see that bug locally, too, and presumably if I reran the tests enough I'd eventually run into this bug as a result.

That bug is perplexing, though, as it isn't clear why the uninstaller should fail to remove those files (nor why it should appear to succeed when it does so).  I've added a bit of logging of the result of the uninstaller process to this tryserver run:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e73e23cd59ec
(In reply to Myk Melez [:myk] [@mykmelez] from comment #346)
> (In reply to Marco Castelluccio [:marco] from comment #309)
> > Could be bug 1192825 then.
> 
> That seems likely. I see that bug locally, too, and presumably if I reran
> the tests enough I'd eventually run into this bug as a result.
> 
> That bug is perplexing, though, as it isn't clear why the uninstaller should
> fail to remove those files (nor why it should appear to succeed when it does
> so).  I've added a bit of logging of the result of the uninstaller process
> to this tryserver run:
> 
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=e73e23cd59ec

toolkit/webapps/tests/test_*_uninstall.xul is testing uninstalling an app,
it does check that the files in the installation directory are no longer
present (but it doesn't check if the shortcuts are removed). So if we fix
bug 1192825, we should add a check in test_*_uninstall.xul.

In the failing test, we're also registering a cleanup function:
SimpleTest.registerCleanupFunction(() => testAppInfo.cleanup());
But it simply removes the shortcut without checking what its actual name is, because it assumes the file is always removed (which should happen, either in |uninstall| or in the |cleanup| function):
OS.Path.join(OS.Constants.Path.desktopDir, aApp.name + ".lnk");
Testing confirms that the uninstaller no longer uninstalls the Start Menu shortcut.  And bisecting nightly builds determines that the regression happened between 20150618030206 <https://hg.mozilla.org/mozilla-central/rev/a3f280b6f8d5> and 20150619030204 <https://hg.mozilla.org/mozilla-central/rev/2694ff2ace6a>.

But I don't see any obvious culprit.  There are no web runtime changes, no NSIS changes, and no other changes that seem particularly suspicious.

There are, however, a lot of changes that landed between those two revisions, which will make bisecting individual revisions quite painful on my slow Windows VM.  Nevertheless, I don't have a better idea, so I'm going to start bisecting to track down the regressing change.
Disabled on Windows so you can hear yourselves think.
Keywords: leave-open
Whiteboard: [test disabled on Windows]
Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
Bug 1238079 removes this test, so this will stop happening once that bug is fixed.
(In reply to Myk Melez [:myk] [@mykmelez] from comment #730)
> Bug 1238079 removes this test, so this will stop happening once that bug is
> fixed.

The test should be already disabled in mozilla-central [1], but it's still intermittently failing on old Firefox versions (e.g. 38 ESR).

[1]: http://hg.mozilla.org/mozilla-central/file/be593a64d7c6/toolkit/webapps/tests/chrome.ini
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.