HTML link to open local file should be interpreted relative to HTML file location

[Elaine Meng]

Currently ChimeraX interprets the local file location relative to its current working directory, not relative to the location of the HTML file with the executable "open" command link. Probably should be the latter, analogous to file references within command files. Wasn't sure how to categorize or assign this, reassign as needed.

[Elaine Meng]

Especially if we want to promote use of the links by databases or people writing tutorials, this should be fixed before the program gets in their hands, or they will be disappointed.

[Eric Pettersen]

Can you provide an example? If I have f1.html and f2.html in the same directory and f1 references f2, I can open f1.html using File->Open and click on the "f2" link and it works...

--Eric

[Eric Pettersen]

Is it resources (like PNGs and whatnot) in the same directory as the page that's not working?

[Elaine Meng]

No, the file access by the browser itself is fine.  It is when you send an “open file” command to ChimeraX, ChimeraX should interpret that relative to the HTML location.  Otherwise it is basically impossible for databases to have ChimeraX open their data, and a huge pain for tutorials with their own data files to be opened in Chimera.  You would like the tutorial plus data to be in its own folder, and it is not known ahead of time where that folder will be relative to the ChimeraX “working directory.”  Or maybe another solution is to set the working directory to the HTML location, but then people might get confused or permission-blocked when they want to save a file.

[Greg Couch]

Appears to not be fixable due to a Qt bug/feature. The callback for the link is given a QWebEngineUrlRequestInfo object, and that object has a firstPartyUrl method that gives the originating URL. Unfortunately, for the cxcmd scheme, it is giving the same cxcmd URL for both the originating URL and the requested URL. I've checked the code in that I believe should work and this should be revisited once Qt 5.7.1 is out. A workaround might be to create a custom web page profile for every QWebEngineWebPage and and tuck the current URL away in a safe place. That affects the profile design Conrad and I have been working on. And it's a shame because the Qt API appears to be designed to do what we need. Will think some more about this.

[Greg Couch]

Worked around by having a separate profile for each widget whose interceptor is bound to the widget. That way the interceptor can use the url() method to get the referring URL.