Solved: Re: posting interactive html plots on websites - Page 3

abmayfield · Jun 18, 2018 11:15 AM

Hello,

I am interested in putting interactive JMP HTML files on my personal website, which is hosted by Squarespace. It seems like the only way to do this is 1) open the interactive HTML file on Chrome, 2) copy the HTML scripts (using Mac's "Developer" option), and 3) pasting the script into either a code box or "embed" box on my website. This does work (although I always get an error message saying the code is too long). However, it always puts the interactive plot under the footer at the bottom of the page (regardless of where I have "placed" the code box). Is there a way I can modify the script to where it actually puts the interactive plot where I want it to go? Alternatively, is there a way to simply "post" an interactive plot on a website, without the need for scripting? (I know hackers can steal my data this way; this is not a concern of mine. I want people to steal my data since it is for the common good!).

Anderson B. Mayfield

AdamChoen · May 31, 2024 10:47 AM

@John_Powell_JMP

i think thats the relevent error for my issue

Uncaught (in promise) DOMException: Failed to read a named property 'document' from 'Window': Blocked a frame with origin "null" from accessing a cross-origin frame.
at window.onload (file://isshfs.xxxxx.com/......./Tool_Counters/Counters.htm:1572:1014711)

Thanks, Adam

John_Powell_JMP · May 31, 2024 12:37 PM

@AdamChoen ,

That error occurs when the web page including the iframe is on a different server than the Interactive HTML page referred to by the iframe. If you can move the Interactive HTML content to the same server/domain as the page with the iframe, this error should go away.

In JMP 18, we worked around this restriction by modifying the Interactive HTML output.

~John

AdamChoen · Jun 1, 2024 08:00 PM

there are on the same server (in the same main folder).

I also tried moving them to different server and to my desktop.

unfortunately, I'm getting the same error.

Adam.

Thanks, Adam

John_Powell_JMP · Jun 3, 2024 09:02 AM

Hi Adam,

There might be something in the way your main web page is including the Interactive HTML page that is seen as an uncaught exception.

There are many ways this can be done. Below is one of the simplest methods that usually works:

The main page would contain the following:

<!DOCTYPE html>
<html>
<head>
    <title>iFrame Example</title>
</head>
<body>
    <h1>iFrame Example</h1>
    <p>Below is an example of an embedded Interactive HTML file using and iframe.</p>
    <iframe src="./bivariate.html" height="900" width="500" title="iframe example"></iframe>
</body>
</html>

In this case, bivariate.html is an Interactive HTML file exported from JMP.

When this is done with a JMP 17 Interactive HTML file, there will be an network error displayed in the console,

"GET file:///C:/api/webjmp net::ERR_FILE_NOT_FOUND"

but it should not stop the page from loading.

If you would, please try this and let me know if it works.

If your main page uses JavaScript to load the Interactive HTML page, you may need have it use a try/catch block to handle/ignore the network failure so it can continue loading the page.

If you need help with this, please contact JMP technical support to provide more details, unless you are comfortable sharing in this forum.

~John

AdamChoen · Jun 4, 2024 02:29 AM

I don't mind shearing here.

seems like it's not working.

Thanks, Adam

John_Powell_JMP · Jun 4, 2024 01:43 PM

Thanks, Adam.

I tested the page in Chrome and Firefox and it loaded despite the error in the console. In Edge, as you found, and now I also can replicate, the iFrame does not load. I'm going to ask internally for some help. Please stay tuned.

Thanks,

~John

Michael_Goff · Jun 4, 2024 02:16 PM

Hi Adam!

This thread is originally from 2018 and since it was originally posted, some things have changed in the internet ecosystem. The reason this embedding scenario is failing is due to a change in browser's security policies. In 2020, Chrome, and other browsers, changed the default value of one of their policies called a "Referrer-Policy" to something more secure. This is in order to help protect your data. The new default policy is called strict-origin-when-cross-origin. Note, the default policy is used when no other policy is specified by the server hosting the content. This means, that when two webpages try to communicate with each other, they need to have the same origin. In this case the origin means the same protocol, hostname, and port.

The issue you're seeing is a consequence of this browser policy change. In JMP 17, our interactive HTML reports are pinging the parent page to see if extra information is available. Since this policy is in place, we hit an error because we're not allowed to access that parent anymore with the new default policy. We have addressed this situation with JMP 18. That would be the easiest path to get something working.

In your case, it looks like you might be accessing these HTML pages through the filesystem:

window.onload (file://isshfs.xxxxx.com/......./Tool_Counters/Counters.htm:1572:1014711)

It's a bit difficult to fully diagnose without looking at the full URLs, but some browsers treat the file:// protocol paths differently than pages hosted on a webserver and consider them all to be "cross-origin" from one another. One way to ensure these files are on the same origin is to host them from a web server. You'd want the parent page to be on something like https://<your_server_hostname>.com/iframe_example.html and the child page to be hosted from https://<your_server_hostname>.com/Counters.html.

Sometimes we test with a local web server is using a VS Code plugin called Live Server. It allows us to quickly spin up a webserver using contents from a folder in our filesystem. However, for any kind of production usage you would probably need to reach out to your IT department to spin up a web server to host these pages.

Again, hosting a webserver would be a workaround for embedding Interactive HTML reports from JMP 17. In JMP 18 we've added a fix to avoid running into that error, and you should be able to embed these pages from the filesystem again.

Thanks,

Michael Goff

AdamChoen · Jun 7, 2024 09:17 AM

Thank you @Michael_Goff for the detail answer.

I'll check my option with local IT to find a long-range solution that works for me.

appreciate your and everyone help!

Adam.

Thanks, Adam