On Apr 19, 2005, at 9:45, Florian G. Pflug wrote:
This happens on my system too - I believe the 10.3.9 update broke it (It contained a new Safari Version, and thus probably a new WebKit too, which I suppose the HTML-View is based on ;-) ).
Yes, I saw your msg on IRC (after you left) :)
Might this be a "security feature"? After all, it might not be unreasonable not to allow a web-page to redirect to a page on the client computer...
I think it is meant as a security feature, maybe one can e.g. redirect an iframe to a local file and use Javascript/DOM to read the contents and post it to a server -- however, when the original file is also loaded from file:// (and in this case, even programmatically set) then I think it should be allowed.
Maybe it's just a matter of telling the Webkit-View that the page it is displaying is to be trusted or something like that?
There's no such API that I know of, but there is the ability to overload various steps of the page-loading process, so it might be possible for me to allow some way of redirection to local files.
I'll try to put the html the pdf-preview-command is generating onto some webserver, and check if safari follows the redirect... I'll report back when I tried that out..
I tested this, it works in OmniWeb but not Safari nor Firefox when I redirect to file://, if however I redirect to a custom URL scheme then it works for Safari. Also, Safari/webview refuses to follow any <a href="file://..."> or <form action="file://..."> (i.e. also when this is the output from a TextMate command).