Mark Smith:
On 5/27/14 10:47 PM, Matt Pagan wrote:
...
- Replace the help desk email label in tor-launcher with a button,
which, when clicked, tells the user's system to open a local pdf file with the system's default pdf viewer.
A con to this approach is that I don't know if it is even possible at all; that is, I'm not sure if JS is capable of detecting what the default application for a filetype is or, if it's not, I'm not sure it's capable of just "opening a file" that needs to be opened with a specific, local application.
There are APIs inside Firefox for opening local files and "revealing" directories/folders. It should be fairly easy to implement this option.
- Replace the help desk email label in tor-launcher with a button,
which, when clicked, opens a XUL window (like window.open) that contains nothing but an iFrame which loads the the local index.html file (from which the user can then navigate to all the other html pages because of the manual's design)
con: ??.
This seems like a pretty possible thing to do right now. Is it? I could not actually get my implementation of this idea even close to working, but I also introduced a lot of new moving parts at once, and I'm still getting the hang of debugging. This seems like it would be the most user-friendly workflow of these various approaches.
I agree this would be the most user friendly option. It will also require the most implementation effort. Basically, we need to build a XUL+HTML (or XUL+PDF) help viewer that does not allow users to "escape" and start accessing the network.
How salient are the risks of accessing the network if there are no external links in the manual and the window is opened with arguments similar to:
window.open("file://" + dir + "index.html", "_blank", "status=0,toolbar=0,location=0,menubar=0"),
?
That is, why would escaping and accessing the network be a consideration if the address bar, menubar, and toolbar aren't loaded?