Following "How to prevent version 13.0 from following symlinks"

I was developing a test framework and there was a symlink test.html inside every folder. As long as now firefox resolves symlinks, I promised to have a look at the code. (wonderful and marvelous mozilla code and docs. Thx people.)

I found in mozilla-central/netwerk/protocol/file/nsFileChannel.cpp

The following code

nsFileChannel::nsFileChannel(nsIURI *uri) {

 // If we have a link file, we should resolve its target right away.
 // This is to protect against a same origin attack where the same link file
 // can point to different resources right after the first resource is loaded.
 nsCOMPtr<nsIFile> file;
 nsCOMPtr <nsIURI> targetURI;
 nsAutoCString fileTarget;
 nsCOMPtr<nsIFile> resolvedFile;
 bool symLink;
 nsCOMPtr<nsIFileURL> fileURL = do_QueryInterface(uri);
 if (fileURL && 
     NS_SUCCEEDED(fileURL->GetFile(getter_AddRefs(file))) &&
     NS_SUCCEEDED(file->IsSymlink(&symLink)) && 
     symLink &&
     NS_SUCCEEDED(file->GetNativeTarget(fileTarget)) &&
     NS_SUCCEEDED(NS_NewNativeLocalFile(fileTarget, PR_TRUE, 
                                        getter_AddRefs(resolvedFile))) &&
     NS_SUCCEEDED(NS_NewFileURI(getter_AddRefs(targetURI), 
                  resolvedFile, nullptr))) {
   SetURI(targetURI);
   SetOriginalURI(uri);
   nsLoadFlags loadFlags = 0;
   GetLoadFlags(&loadFlags);
   SetLoadFlags(loadFlags | nsIChannel::LOAD_REPLACE);
 } else {
   SetURI(uri);
 }

}

If you force the false branch SetURI(uri) in any case, firefox stops resolving the symlinks. This is a very local solution, but as you can see in the first comment, resolving the symlink is intentional.

So the questions are:

 Is mozilla people going to provide another solution to solve security risks without breaking backward compatibility with our code?

Who do we have to post our question to?

Thanks to all for your support.