Permaorange in test_custom_origin_uninstall_install.xul, test_hosted_uninstall.xul, test_packaged_uninstall.xul on OS X 10.10

RESOLVED WONTFIX

Status

Firefox Graveyard
Web Apps
P1
normal
RESOLVED WONTFIX
4 years ago
4 months ago

People

(Reporter: philor, Assigned: myk)

Tracking

Trunk
x86
Mac OS X

Details

(Reporter)

Description

4 years ago
See, e.g., https://treeherder.mozilla.org/logviewer.html#?job_id=92519&repo=cedar - apparently 10.10 doesn't like deleting.

20:43:20 INFO - 2890 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_custom_origin_uninstall_install.xul | Error during test: REINSTALL_FORBIDDEN - expected PASS
20:44:35 INFO - 2917 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_hosted_uninstall.xul | App moved to Trash - expected PASS
20:46:10 INFO - 2952 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_packaged_uninstall.xul | App moved to Trash - expected PASS
Marco, testing on 10.10.1 installing, deleting and re-installing worked with Nightly (38.0a1 (2015-01-23)). As the bug is a bit cryptic, you might have a better idea on why the tests fail exactly.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(mmucci)
(Reporter)

Comment 2

3 years ago
It may be cryptic, but it's not unconfirmed, since it's not about whether or not there exists a 10.10 install where they pass, it's about them not passing on releng's 10.10 install.

If you want the full chatty version, try this:

releng is getting ready to switch from running tests on OS X 10.8 to running them on OS X 10.10 on the same pool of slaves. As part of that, they have three slaves with 10.10 installed, which for a while were running on the Cedar twig, but now are available for try runs instead since that's much simpler and more sane for us as a place to green up tests. You can run them on try with trychooser syntax like "try: -b do -p macosx64 -u mochitest-o[10.10] -t all".

As always when releng rolls out a new slave platform, the reason your tests fail may be because something they do doesn't agree with the new OS, or it may be that your tests require some change in how things are installed or configured with the OS, or required something be installed or configured differently with the last version of the OS which everyone but you has now forgotten about, but because you are the only ones who know what your tests are doing and what they want and what is making them fail and how to change them to be more verbose about why they are failing, you'll have to be the ones to tell releng if they need to make changes to support your tests.

For a current example of them failing as of this morning, see https://treeherder.mozilla.org/ui/logviewer.html#?job_id=4424982&repo=try for an opt job or https://treeherder.mozilla.org/ui/logviewer.html#?job_id=4424262&repo=try for a debug job, though the failures have looked exactly the same since the very first job these slaves did.

To get the permaorange out of the way of blocking the transition, I'll probably be disabling them on 10.10 soon, but when I do I'll also put the link to a revert-the-disabling patch you can stick at the top of a try queue to turn them back on when you push diagnostic patches to try.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Harald Kirschner :digitarald from comment #1)
> Marco, testing on 10.10.1 installing, deleting and re-installing worked with
> Nightly (38.0a1 (2015-01-23)). As the bug is a bit cryptic, you might have a
> better idea on why the tests fail exactly.

Hi Harald, I think you might be looking for a different Marco.  I have no insight into this bug.
Flags: needinfo?(mmucci)
(Assignee)

Comment 4

3 years ago
Perhaps Harald was thinking of Marco Castelluccio?
Flags: needinfo?(mar.castelluccio)
(Reporter)

Comment 5

3 years ago
Disabled in https://hg.mozilla.org/integration/mozilla-inbound/rev/6bcf64c6e8f3, so just stick https://hg.mozilla.org/try/rev/f6fad6f210c9 at the top of your patch queue to reenable them and run them on try.
Keywords: leave-open
Looks like we're correctly removing the installation directory, but failing to move the files to the trash:
10:34:28 INFO - 2491 INFO TEST-PASS | toolkit/webapps/tests/test_hosted_uninstall.xul | Files correctly removed
10:34:28 INFO - 2492 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_hosted_uninstall.xul | App moved to Trash - expected PASS 

What's the name of the trash directory on these machines?
The test that is failing is this one: ok(testAppInfo.trashDir.contains(".Trash"), "App moved to Trash");
Might be related to bug 1038376.
Flags: needinfo?(mar.castelluccio)
(Reporter)

Comment 8

3 years ago
I'd think if Yosemite renamed the trash, googling would tell me so, but you never know.
Flags: needinfo?(kmoir)

Comment 9

3 years ago
The Trash directory is here
[root@t-yosemite-r5-0001.test.releng.scl3.mozilla.com /]# ls -lad /Users/cltbld/.Trash
drwx------  3 cltbld  staff  102 29 Jan 02:54 /Users/cltbld/.Trash
[root@t-yosemite-r5-0001.test.releng.scl3.mozilla.com /]# ls -la /Users/cltbld/.Trash
total 16
drwx------   3 cltbld  staff   102 29 Jan 02:54 .
drwxr-xr-x  18 cltbld  staff   612 24 Jan 01:58 ..
-rw-r--r--@  1 cltbld  staff  6148 25 Jan 05:12 .DS_Store

The same location as it was on 10.8 slaves, same permissions
Flags: needinfo?(kmoir)
Priority: -- → P1
(Reporter)

Updated

3 years ago
No longer blocks: 1121199

Updated

3 years ago
Assignee: nobody → myk
(Assignee)

Comment 10

2 years ago
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
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
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.