How to prevent version 13.0 from following symlinks
We are developing a test framework in the the test directory.
Some other folders contain a soft link (ln -s) to file test.html inside the test directory.
In previous versions when dragging the link to the browser ,it wasn't resolved. In that way we could scope test.html to the files in that module.
Now, the file protocol always points to the test dir.
Is there any way to prevent firefox from following the symlinks any longer?
Ændret af txema.gonz den
Alle svar (12)
A possible workaround is to install an apache server and create a symbolic link inside the root dir (/var/www in my case) to the project dir.
Then you can switch to the http protocol.
This solutiion works partially but enforces to all the developers to install apache.
Ændret af txema.gonz den
The worst thing about this is the fact that any query string appended to the original url is obliterated when the symlink is followed, which even further renders testing scenarios unusable.
Running apache and addressing the test page does workaround the issue, but this is unnecessary for other browsers.
I am running FF 13 on OSX.
Possibly related (unsolved) thread: cannot open local shtml file -- symlink resolves to page and display open/save/cancel dialog.
Do you think we should open a ticket somewhere?
(I guess there is one)
I often miss bugs in the bug tracking system Buzilla but you could take a look and see whether you find it. If you file a new bug and it is recognized as a duplicated, someone will add a note to your bug so you can find the earlier one.
Seems that nobody has posted something similar there.
I've been taking a look at this page: Document Loading - From Load Start to Finding a Handler amongst others.
I think the error might be in the necko package (on netwerk/protocol/file directory). Before disturbing the developers I want to:
- Write a page with a file protocol link and check out whether this keeps failing. If it doesn't fail here, then the problem should be in the address bar.
- Debug nsFileProtocolHandler.cpp
When I get done with all of these I'll create the ticket and put here the link to it.
Thanks to all.
Tested => Firefox has the same behaviour with the the links, so:
- it's not a problem with the address bar.
- Our next stop is in the file handler protocol.
Same behaviour on Linux as on OSX. Even the old links pulled from history are replaced with link targets. And, this behaviour has been carried over to 14.0.
Ændret af selkovjr den
Continues in 15.0.
And in 16.0 beta.
Now in 16.0 beta 6
Same in 17.0 and in today's Nightly.
Is there a plan for fixing it? It is a major regression -- I cannot open a file in Firefox.