New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not showing any visualisations. #6
Comments
I can confirm this issue on 10.13. I haven't looked into why it happens yet. |
Thanks for looking into it @freron |
I took a quick look at this. The problem is that MailMate generates a temporary local file and Safari no longer allows reading that file (for security reasons). A temporary workaround is to enable the developer menu (in the Advanced panel of the Safari preferences) and then enable the menu: “Develop > Disable Local File Restrictions”. The proper fix is more tricky. It appears one has to run a local http server to provide the file. I'm not sure if there is a better fix. |
Cross-posting from the mailinglist: Starting a local webserver just to serve a CSV file for a bundle seems a bit like overkill to me. Wouldn’t it be easier to just generate a Javascript file with the data instead of a CSV and include it in the page using a <script> tag? |
To expand on svmaris's comment ... Currently it opens a URL that roughly looks like: file:///Users...index.html?csv_file:/var/.../com.freron.MailMate.Visualize.csv The security is cranky because java script shouldn't open arbitrary files on the user's computer. It looks like it wouldn't be difficult to change that to be: file:///var/.../com.freron.MailMate.Visualize.html I.e. a copy of existing index.html with the data from the old csv inlined into it. Of course that would require a bit of tinkering to byTime.js. |
It took me a while but I've been looking into this recently. As I understand it, the security is cranky because loading external files using There might be a couple of ways to get this to work. 1. Run a local serverFrom what I've tried, one way to get this to work is, as @freron mentioned, to have a local server running that serves both the html and data file, which would mean that the data file would have to be in the plugin's directory, and that MailMate would have to spin up the local server and shut it down when it exits. 2. TemplatingAnother way that's a bit of a hack but I think would work is to implement some templating where MailMate replaces some placeholder inside the js file with the data itself. That way the script wouldn't have to read any external files, and that would work without the need to run a local server. For example, somewhere in var data = {"emails": {{ email_json_data }}} and when invoked, MailMate would replace 3. Start a browser with the security setting turned offI don't think this is a good option, but I'm mentioning it here for completeness. At some point at least Chrome allowed a user to start it with a flag So, I think solution 2 might be the most promising, and if not, I'm curious if anyone has any other leads. |
The second solution is probably the easiest and we probably (currently) gain too little by going for the first solution (although I like seperation of code and data in general). I can look into how to do this and then I'll get back to you. |
@freron 's workaround with disabling Local File Restrictions doesn't seem to work anymore. Does this mean that this bundle is dead? |
@tophee: Sorry, you'll have to wait for me to either implement a workaround or support for showing the resulting HTML within MailMate itself. (I haven't verified myself that local file restrictions can no longer be relaxed, but I wouldn't be surprised.) |
@freron please do not apologise. Thanks for all the work you have put into MailMate! It would obviously be great if those stats could be displayed within MailMate, but maybe that shouldn't be the highest priority... For me, it would have been helpful to somehow be able to see which plugin actually (still) works. |
I haven't released a new revision of MailMate including this change yet, but I've implemented a showHTML action for bundle commands which allows a command to ask MailMate to open a window and display some HTML. This HTML has access to load files from a specific temporary folder exclusive for the given command. It can also load the HTML files within the support folder of the bundle. This solves the basic problem, but it does open a new one: The simplistic window shown doesn't really support anything but displaying the HTML (no printing comes to mind). It does support multiple windows and it does remember window frames and it reuses a window if the same bundle command is run again. The changes needed for the Visualize bundle (and some simplifications) have been pushed to github (on my fork), but they are not part of the default bundles of MailMate yet. Since the bundle is currently broken for most users anyway then I'll probably do that soon. |
@freron Just checking on what the status of that showHTML bundle command is. If there is work I can do on my end to update Visualize to work with that I'd be happy to do it. |
The official bundle has been updated and it should work with recent test releases of MailMate. The latest one: https://updates.mailmate-app.com/archives/MailMate_r5839.tbz |
Thanks to Benny's integration the plugin displays visualization again. |
Hi.
I am unable to see any visualisations on Safari, Chrome, Firefox. Just a blank screen like this.
http://d.pr/i/zKponC, http://d.pr/i/z2S3jw, http://d.pr/i/z2S3jw. the CSV file generated does have the data though. Not sure where the issue.
The text was updated successfully, but these errors were encountered: