STEPS TO REPRODUCE: 1) Build from rev 64ce651bf43d 2) mkdir /tmp/profile 3) env MOZ_DISABLE_CONTENT_SANDBOX=t mach run -profile /tmp/profile https://perfht.ml/2uavsT8 4) Quit the browser. 5) mach run -profile /tmp/profile https://perfht.ml/2uavsT8 EXPECTED RESULTS: Everything is great, page loads ACTUAL RESULTS: Corrupted content error. The reason this fails is that step 3 saves serialized security info for the various channels involved in our cache. Then we try to deserialize it in step 4, try to createInstance the TRANSPORTSECURITYINFO_CID, try to EnsureNSSInitializedChromeOrContent(), which calls NSS_NoDB_Init(), which fails. Also happens with MOZ_DEVELOPER_REPO_DIR set appropritely, so this is not just a "mach run is not passing some random dir" problem. I have verified that this happens with packaged nightly builds too, for what it's worth. So not even a self-build problem. Worse yet, with the sandbox enabled we're creating cache entries without security info, which is also a problem.

Note that that this is effective dataloss as people update to affected nightlies, because it will break their serviceworkers.... The underlying problem here is the same as bug 1380132 and we really should have had tests that would have caught at least one of these!

I tried that patch, and it doesn't fix things for my local build, as far as I can tell.... I wonder whether the issue there is that libsoftokn3.dylib itself is a symlink for unpackaged builds. If I replace that and libfreebl3.dylib with copies instead of symlinks in $objdir/dist/Nightly.app/Contents/MacOS this problem goes way for my self-build.

(In reply to Boris Zbarsky [:bz] from comment #3) > I tried that patch, and it doesn't fix things for my local build, as far as > I can tell.... Sorry, I meant to post that patch on bug 1380132. I haven't tested the failure case reported here.

(In reply to Boris Zbarsky [:bz] from comment #0) > STEPS TO REPRODUCE: > > 1) Build from rev 64ce651bf43d > 2) mkdir /tmp/profile > 3) env MOZ_DISABLE_CONTENT_SANDBOX=t mach run -profile /tmp/profile > https://perfht.ml/2uavsT8 > 4) Quit the browser. > 5) mach run -profile /tmp/profile https://perfht.ml/2uavsT8 > > EXPECTED RESULTS: Everything is great, page loads > > ACTUAL RESULTS: Corrupted content error. This is not reproducible for me with a build from my repo stored in my home directory using mach run. It is reproducible if I do a packaged build (mach build package) and copy the resultant Nightly.app to /tmp and run it via $ env MOZ_DISABLE_CONTENT_SANDBOX=t /tmp/Nightly.app/Contents/MacOS/firefox -profile /tmp/profile https://perfht.ml/2uavsT8 $ /tmp/Nightly.app/Contents/MacOS/firefox -profile /tmp/profile https://perfht.ml/2uavsT8 It is not reproducible with a package build run out of /tmp with the fix currently posted on 1380132. Could you provide more details about how Firefox is getting run in your setup?

> Could you provide more details about how Firefox is getting run in your setup? 1) Pull revision ea84b4c23270 (but I suspect this does not matter). 2) Apply the patch from this bug. 3) Build opt. 4) mkdir /tmp/profile 5) mach run -profile /tmp/profile https://www.mozilla.org/en-US/ reproduces the problem for me: it comes up not secure.

I guess step 5 is actually: env MOZCONFIG=`pwd`/.mozconfig-fox-opt ./mach where .mozconfig-fox-opt in my srctree is the mozconfig for the build created in step 3.

This is being caused by the same problem as bug 1380132. Having an object dir outside of the repo dir exposes the bug. See https://bugzilla.mozilla.org/show_bug.cgi?id=1380132#c25 for the full explanation. Closing as a dupe.

Track 56- and mark 56 fixed as bug 1380132 was fixed in 56.

For duplicate issues like this, can you also mark them "fixed" in the status-firefox field? That way they will fall off the platform/release health triage queries. Thanks!

Thanks for the reminder.