Hi Nuria,

ESASky 7.2 has now been released with a fix for this issue. Let us know if you still experience the issue.

Cheers,

Henrik

Hi Bruno,

I'm glad you found a workaround. It seems strange that you would need to do something like this. I'm able to send 10 commands at the same time, and they all execute correctly. 

That said, if you would like to improve your workaround, I have a suggestion. 

1. Create a queue of commands you would like to send
2. Send the first command
3. Wait for the command to finish
4. Send the next command

You can keep track of when a command has finished by doing something like this:

window.addEventListener("message",function(e){
        console.log("The command has finished - " + e.data);
        // Send the next command, if there are any
 });

Good luck, and let me know if you find the reason you cannot send multiple commands at the same time.

Cheers,

Henrik

Hi Bruno,

It is concerning that your API commands don't affect ESASky. I have not been able to reproduce any of the issues on my machine. All my commands work fine. To quickly test whether the issue originates from your code or not, go to https://sky.esa.int -> Press F11 -> paste

postMessage({event:'changeHipsWithParams',  content:{'hips': {'name': 'Gaia DR3 G flux', 'id': 'GaiaGFlux', 'url': 'https://alasky.cds.unistra.fr/ancillary/GaiaDR3/G-flux-map/'}}});

in the console -> press enter. If this works, there is likely some issue on your end.

You can also test all API commands on the ESASky API page by pressing the 'send' button on any of the command descriptions:

https://www.cosmos.esa.int/web/esdc/esasky-javascript-api

Regarding your errors, you can safely ignore the ones related to document.write() and Moc.fits. The errors you got for https://sky.esa.int/esasky-tap/ext-taps?ACTION=REQUEST&ADQL=SELECT%20*%20FROM%20ivoa.ObsCore&MAX_REC=1&TAP_URL=https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/argus/sync seem to be related to some temporary downtime of CADC. It seems to be working now.

Hi Bruno,

I just pasted all the following commands into the browser console simultaneously, and they all seem to have executed properly.

postMessage({event:'setFov', content:{fov:'3.2'}});
postMessage({event:'setCooFrame', content:{cooFrame: "galactic"}});
postMessage({event:'goToRaDec', content:{ra:'10.68470',dec:'41.26875'}});
postMessage({event:'changeHipsWithParams',  content:{'hips': {'name': 'Gaia DR3 G flux', 'id': 'GaiaGFlux', 'url': 'https://alasky.cds.unistra.fr/ancillary/GaiaDR3/G-flux-map/', 'cooframe': 'J2000', 'maxnorder': '7', 'imgformat': 'jpeg'}}});

Could you test this and see if it works for you? We had a release on 7 February, so you may have encountered a new bug. If so, could you send me an example of some commands that fail for you, and I can help you troubleshoot?

Regarding the addHipsWithParams and changeHipsWithParams, you can safely ignore and omit cooframe, maxnorder, and imgfomat, since these are read from the HiPS properties file. The API documentation is out of date regarding these parameters, so I have to fix that. Thanks for pointing this out!

The following is sufficient:

postMessage({event:'changeHipsWithParams',  content:{'hips': {'name': 'Gaia DR3 G flux', 'id': 'GaiaGFlux', 'url': 'https://alasky.cds.unistra.fr/ancillary/GaiaDR3/G-flux-map/'}}});

Cheers,

Henrik

Hi Bruno,

I can make some educated guesses on what is going wrong. That error about DSSColor is most likely unrelated to the issue you are experiencing. 

For reference, here is a call that should change the HIPS you are viewing to one from Gaia. Please try it, and see if it works. for you.

postMessage({event:'changeHipsWithParams',  content:{'hips': {'name': 'Gaia DR3 G flux', 'id': 'GaiaGFlux', 'url': 'https://alasky.cds.unistra.fr/ancillary/GaiaDR3/G-flux-map/', 'cooframe': 'J2000', 'maxnorder': '7', 'imgformat': 'jpeg'}}})

I don't see anything wrong with the command you used, except for the URL ('url': 'http://foo-bar-baz/plugins/esaSky/dr3_RGBHiPS), which I guess you deliberately censored for this post. The most likely issue is that the URL of the HiPS needs to be accessible through HTTPS. HTTP is not enough. This is due to security concerns (CORS) by the browser providers like Chrome, Firefox, etc, so there is not much we can do about that. The best solution is to upgrade the server to support HTTPS, so please do that if you can.

If you cannot do that, but you have all the HiPS files on your file system, then you can display the HiPS in ESASky through the UI. Inside the "Select Sky" menu, there is a plus button, where you can select to add "HiPS from your computer". This means the HiPS is only accessible to you, though, so maybe it is not the solution you are after. 

If you still have issues after upgrading the HiPS server to HTTPS (or if the HiPS server already supports HTTPS), please let me know, and we can troubleshoot this further. 

Good luck,

Henrik Norman

ESASky

Hi Nuria,

Many thanks for letting us know about the issue. We were finally able to reproduce the issue using a borrowed iPhone. We'll continue investigating the issue and have a fix ready for the next release.

For now, you may want to try a different browser.

Cheers,

Henrik Norman

ESASky

Hi Casey,

Yes, you can change projections with the dropdown menu in the header. 

See: "SIN" in the image below

Cheers,

Henrik Norman

It is already possible, but it seems that we have forgotten to update the API documentation properly to include these commands. Thanks for helping us find this issue with the documentation!

The API command is called restoreState and can be used like this: {'event':'restoreState', 'content': {'state': sessionJson}}, where you can replace 'sessionJson' with the content of your json file. 

FYI, there is also the sister command 'saveState' ({'event':'saveState'), which can be used to extract the json programmatically. As with all commands that extract information from ESASky, you would also need an event listener to be able to see the json produced by saveState, as described on the API page. This command should produce the same json as when you save the session using the UI.

Cheers,
Henrik

Hi Casey,

If you update the http links in the iframe to https, the example should work again. Here is a cross-domain example (https://winterway.eu/esasky/iframetest-https.html) where I changed all the "http://sky.esa.int" to “https://sky.esa.int.”

I also see that Jareel was asking about hiding UI components, which has been possible for a long time but may not yet properly documented. For example, changing the iframe url to https://sky.esa.int?hide_welcome=true&hide_banner_info=true will hide the welcome dialog and banner. There are also a bunch of other parameters like target, hips, fov, cooframe, layout, and more which can be set to specify the initial view of ESASky. If these are not already documented somewhere, we’ll make sure to expose that information shortly.

Cheers,

Henrik Norman

Hi Casey,

Many thanks for letting us know about the issue. There is a missing HTTP header (CORS) in the responses we are getting from the Hubble and Webb servers, which causes this issue. We'll contact the Hubble and Webb team so they can address the problem and let you know as soon as it is working again.