CORS

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

Thanks, Henrik, for the fast answer!

Just one more doubt:
I'm doing successive calls to 'setCooFrame', 'goToRaDec', 'setFov', and finally 'changeHipsWithParams'
These calls were working fine previously, but now it seems just the first one of them is being executed...

I tried adding a small interval between the calls, using promises, making sure the frame was fully loaded before firing these commands and nothing worked.

Was there any change in ESASky that could be the cause of this and I need to adapt my code accordingly?

I thought if this was so because I did my tests without loading (but It functioned offline before) or because I did not use HTTPS in my server (but I'm using it now).

Another thing: the properties file of a HiPS includes info like frame, initial ra, dec and fov. When I load a HiPS file in ESASky do I need to always set those via calls to ESASky or is there any way for ESASky to pick them from the HiPS parameters? I suspect the best would be to read them in the properties myself and fire the related events.

Sorry for these newbie questionings.

Best regards,
Bruno

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

Hello Henrik,

I'm still having problems. I ran out of ideas for now.

Seems ESA Sky is ignoring my calls:

I tested with the calls you passed. Seems none were executed.

I just saw the random image ESASky always show when started.

I then thought about the possibility of any error when doing more than one call (i.e. an error occurred as result of one of them and subsequent ones failed too as consequence) and tried with just one simple call, say goToRaDec (with valid RA and Dec, of course). No results too.

I did my tests locally. I switched to http again (https seems to have nothing to do with the problem anyway)

I'm using Chrome Version 133.0.6943.53 (Official Build) (64-bit)

My OS is a 64-bit Ubuntu 22.04.5 LTS

It functioned fine in the past, with multiple commands and all that.

To reduce the possibility of missing a bug on my side, I tested with the code as it were (for I did many changes trying to figure the problem out).

I also tried keeping the code at minimum to see if I could isolate any bug I was not seeing.

Here's the possible relevant errors and warnings I picked with Chrome:

esasky_cl_7_1_2025_0…07_38Z.nocache.js:4

[Violation] Avoid using document.write(). https://developers.google.com/web/updates/2016/08/removing-document-write

esasky/:1

[GroupMarkerNotSet(crbug.com/242999)!:A0E03801BC360000]Automatic fallback to software WebGL has been deprecated. Please use the --enable-unsafe-swiftshader flag to opt in to lower security guarantees for trusted content.

sky.esa.int/esasky/?target=190.91669999999993%2011.552611111111112&hips=DSS2+color&fov=0.3&projection=SIN&cooframe=J2000&sci=true&lang=en:1

[GroupMarkerNotSet(crbug.com/242999)!:A0E03801BC360000]Automatic fallback to software WebGL has been deprecated. Please use the --enable-unsafe-swiftshader flag to opt in to lower security guarantees for trusted content

aladin.min.js:20

GET https://cdn.skies.esac.esa.int/DSSColor//Moc.fits" class="redactor-autoparser-object">https://cdn.skies.esac.esa.int/DSSColor//Moc.fits net::ERR_FAILED 404 (Not Found)

esasky_cl_7_1_2025_02_07T10_07_38Z-0.js:7148

GET 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 500 (Internal Server Error)

esasky_cl_7_1_2025_0…10_07_38Z-0.js:7148

GET https://sky.esa.int/esasky-tap/ext-taps?ACTION=REQUEST&ADQL=SELECT%20*%20FR…e&MAX_REC=1&TAP_URL=https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/argus/sync 500 (Internal Server Error)

Regarding the 404 error: the link Associated coverage map: MOC is broken in https://cdn.skies.esac.esa.int/DSSColor/

Could you confirm if there's anything on your side?

Cheers,

Bruno

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, Henrik

Seems I found the cause.

I have the snippet below in my (pre-ES6) code.

$interval is an Angular.js service and what the snippet pattern does is just

running only once after it's first execution (granting the iframe is loaded)

var stop = $interval(function() {
    postMessage(...);
    ... snip ...
    postMessage(...);
    $interval.cancel(stop);
}, 1500);

I used before a time of only 250 ms. It's not enough anymore - need to investigate why,
as just increasing a delay is not satisfactory.

After increasing it to 1.5 s, all commands completed successfully.

Thanks very much for your support and valuable suggestions!

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