This seems to be a limitation of the GTK+. You can't force its file selector to do something it just can't currently do. Any applications that use the GTK+ file selector widget are going to have the same problems.
However applications that use the Qt equivalent (and therefore all KDE applications and many others), can open directly from HTTP links. I have tested this in Kate.
I'm not sure what solution you want here. You could probably spend some time hacking this into the relevant GTK library so that it functions like this in the future. You could then submit that upstream and it'd eventually be the default (if accepted).
But the quicker route for this is either:
- Using an application that uses QT (or another framework that does this)
- Find another workflow.
In the context a browser, no browsers that I have tested (including GTK and Qt widget based ones) were capable of opening a remote URI for a file selection.
As mentioned earlier, Qt is technically capable of this but in Rekonq (the Qt browser I tested) it seemed limited to local files only. This may be something that could be worked on. For the GTK+ browsers (most of them) work needs to be done at on GTK before they'll work.
In short, fixing this in the browser isn't going to be practical for anybody.
That said you might be able to create a FUSE-based filesystem that read from the clipboard and provided a fake filesystem that contained one file (which then streamed data from the URL using something like the
You could then just select that file in the browser and it'd work like any other file.
This isn't a small project (hence the lack of code) but it would be quite achievable to somebody with a little bit of Python experience.