Skip to content
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

Closed
simplysaru opened this issue Sep 6, 2017 · 14 comments
Closed

Not showing any visualisations. #6

simplysaru opened this issue Sep 6, 2017 · 14 comments

Comments

@simplysaru
Copy link

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.

@freron
Copy link
Contributor

freron commented Sep 21, 2017

I can confirm this issue on 10.13. I haven't looked into why it happens yet.

@sheriferson
Copy link
Owner

Thanks for looking into it @freron
@simplysaru Sorry for not responding earlier. I didn't get any notifications about the issue. Hopefully it's worked out soon.

@freron
Copy link
Contributor

freron commented Oct 5, 2017

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.

@svmaris
Copy link

svmaris commented Jul 4, 2018

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?

@bhyde
Copy link

bhyde commented Jul 4, 2018

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.

@sheriferson
Copy link
Owner

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 file:// without having a sever serving those files is no longer allowed. I tried changing the file's extension as @bhyde recommended, but it didn't change anything. Even including the data file in the same directory as the script makes no difference.

There might be a couple of ways to get this to work.

1. Run a local server

From 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. Templating

Another 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 byTime.js:

var data = {"emails": {{ email_json_data }}}

and when invoked, MailMate would replace {{ email_json_data }} with the actual dataframe.

3. Start a browser with the security setting turned off

I 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 --disable-web-security that would allow cross origin requests. There are many problems with this as a solution: perhaps obvious, but it's insecure, and I don't think Benny wants MailMate to be an application that can open a browser session that is insecure for the user if they forget that it's running in this compromised state. I wouldn't want that either. It also looks to be discouraged and complicated.

So, I think solution 2 might be the most promising, and if not, I'm curious if anyone has any other leads.

@freron
Copy link
Contributor

freron commented Aug 20, 2018

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.

@tophee
Copy link

tophee commented Jun 22, 2021

@freron 's workaround with disabling Local File Restrictions doesn't seem to work anymore. Does this mean that this bundle is dead?

@freron
Copy link
Contributor

freron commented Jun 23, 2021

@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.)

@tophee
Copy link

tophee commented Jun 24, 2021

@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.

@freron
Copy link
Contributor

freron commented Jul 1, 2021

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.

@sheriferson
Copy link
Owner

@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.

@freron
Copy link
Contributor

freron commented Oct 16, 2021

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

@sheriferson
Copy link
Owner

Thanks to Benny's integration the plugin displays visualization again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants