One of the results of my experiment in preventing content processes from directly deleting files: Thread 0 (crashed) 0 libc.so + 0xc9b0 1 libxul.so!nsLocalFile::Remove(bool) [nsLocalFileUnix.cpp : 1045 + 0x5] 2 libxul.so!nsDownloader::~nsDownloader [nsDownloader.cpp : 23 + 0x7] 3 libxul.so!nsDownloader::~nsDownloader [nsDownloader.cpp : 27 + 0x3] 4 libxul.so!CompositeEnumeratorImpl::Release() [nsCompositeDataSource.cpp : 162 + 0x5] 5 libxul.so!nsCOMPtr_base::assign_assuming_AddRef(nsISupports*) [nsCOMPtr.h : 457 + 0x5] 6 libxul.so!nsCOMPtr_base::assign_with_AddRef(nsISupports*) [nsCOMPtr.cpp : 49 + 0x7] 7 libxul.so!nsJARChannel::OnStopRequest(nsIRequest*, nsISupports*, unsigned int) [nsCOMPtr.h : 673 + 0x3] 8 libxul.so!nsInputStreamPump::OnStateStop() [nsInputStreamPump.cpp : 711 + 0xb] 9 libxul.so!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) [nsInputStreamPump.cpp : 440 + 0x5] 10 libxul.so!nsInputStreamReadyEvent::Run() + 0x11 11 libxul.so!nsThread::ProcessNextEvent(bool, bool*) [nsThread.cpp : 766 + 0x5] The content process shouldn't be accessing the filesystem directly. See also bug 965724, where NS_OpenAnonymousTemporaryFile was remoted. Bug 988816 might be related.

This seems to only be an issue for scheme nestings like jar:http:// (as opposed to cases of jar: that are already handled by PRemoteOpenFile), and I can't tell if there's any actual use of that kind of thing (from content) other than in mochitests.

I think the answer to both this bug and bug 1034143 is to remote the use of the downloader, as discussed in the comments of the other bug.