I was able to replicate the issue described by Nowlan Freese, both in bioviz connect and genome dashboard when testing on the live sites. When running locally genome dashboard locally, however, I had no errors. After doing some research, this appears to be a CORS issue - safari is complaining that IGB doesn't explicitly allow cross origin requests. To solve this, I have modified the IGB API endpoint, 'http://127.0.0.1:7085/igbStatusCheck', to respond with an additional header that should prevent this error.

Please see the change at my branch below:
https://bitbucket.org/pbadzuh/igb_pbdev/branch/IGBF-2420#diff

Thank you. I think this fix is a good one. Please proceed with a PR when convenient.

Sure, thanks. Please see the PR below:
https://bitbucket.org/lorainelab/integrated-genome-browser/pull-requests/810/igbf-2420-allow-javascript-running-on-non/diff

Merged and ready for testing.

cc: Nowlan Freese

Recommend reverting changes as they do not appear to fix the issue.

Tested on Safari (13.1.2) on Mac (10.14.6). Tested [BioViz Connect|connect.bioviz.org\ and Genome Dashboard.

Receiving the error:
[Warning] [blocked] The page at https://connect.bioviz.org/base/#/iplant/home/nowlanf/SmokeTesting/H_sapiens_Dec_2013 was not allowed to display insecure content from http://127.0.0.1:7085/igbStatusCheck. (cyverse.js, line 708)

After talking with Philip, the issue seems to be that a secure page (https://www.bioviz.org/genome-dashboard) is attempting to reach an insecure page (http://127.0.0.1:7085/igbStatusCheck). It seems that Google/Firefox recognize that the page is attempting to reach localhost, but Safari still considers it a security risk. There does not appear to be any way to change Safari security settings to enable it to work.

It seems like the best way to fix this issue would be if the IGB endpoint was https (https://127.0.0.1:7085/igbStatusCheck). If Chrome/Firefox were to adopt the same level of security as Safari this would break a lot of IGB functionality.

Could you clarify something for me? (I am not sure I understand the problem.)

The AppStore and bar.js javascript running in safari seem to be able to hit localhost endpoints. I'm wondering if maybe the code is structured in a different way?

cc: Nowlan Freese and Philip Badzuh

Example links to run the above-mentioned javascript in your browser are below.

To confirm the above statement, I will try them with and without IGB running:

• https://www.bioviz.org/bar.html
• https://apps.bioviz.org/apps/org.lorainelab.igb.protannot

When I try to run BAR I receive the error:

[Warning] [blocked] The page at https://bioviz.org/bar.html?version=A_thaliana_Jun_2009&gene_id=AT2G24270&feature_url_0=https://s3.amazonaws.com/iplant-cdn/iplant/home/araport/rnaseq_bam/aerial/SRR847505/accepted_hits.bam&genome=A_thaliana_Jun_2009&annotation_set=Araport11&query_url=https://s3.amazonaws.com/iplant-cdn/iplant/home/araport/rnaseq_bam/aerial/SRR847505/accepted_hits.bam&server_url=bar was not allowed to display insecure content from http://127.0.0.1:7085/igbStatusCheck. (bar.js, line 63)

I confirm that as noted by Nowlan Freese and Philip Badzuh, Safari does not allow contacting the insecure (http) localhost links.

The app store also does not recognize that IGB is running for me in Safari.

Stackoverflow issue "HTTPS Server on Android Device Using NanoHttpd"

• https://stackoverflow.com/questions/31270613/https-server-on-android-device-using-nanohttpd/35765334

IGB uses NanoHttpd to implement its endpoints.

We almost caught this back in May - https://jira.transvar.org/browse/IGBF-2353
(Search Jira for "Safari")

Note added later:

• Maybe we did not catch it because there was nothing to catch – it worked fine in Genome Dashboard?

Next steps:

• Investigate Microsoft Edge. Does it have the same problem?
• Review Web logs to determine browsers used by people

Tested on Mac 10.14.6 with Microsoft Edge 4.0.522.44

Tested BioViz Connect and IGB App Store. Both worked correctly, did not see the issue occurring on Safari.

In working with the genome dashboard code, I noticed that requests made to the https IGB API endpoints do not fail when done so by changing the browser's window location using javascript. This makes sense, since the Mixed Content errors that occur in safari and potentially other browsers result because unsecured requests are being made from within a secured connection, however, to my understanding, changing the window location initializes a new connection.

An example of a successful request

window.location = 'http://localhost:7085/bringIGBToFront';

Good news! Maybe we can try it with App Store or bar.js next?

attn: Nowlan Freese and Philip Badzuh

Sure, that sounds good. I'll make a new ticket to see if this can be implemented in the app store.