This strange message does NOT appear when I try a simple “Draw -> <dflt>” (it only appears for “Draw in new tab” and reload the tab).
So, I tried your link … I clicked it, then Firefox Main Menu -> Tools -> Browser Tools -> Web Developer Tools (Ctrl+Shift+I) (the “Console” is displayed automatically) and then I clicked “Reload current page (Ctrl+R)”:
(...)
GET
https://root.cern/js/dev/modules/gpad/TCanvasPainter.mjs
[HTTP/1.1 200 OK 0ms]
Set jsroot source_dir to https://root.cern/js/dev/, dev 28/03/2023 core.mjs:34:15
Error in parsing value for ‘padding’. Declaration dropped. index.htm
XHRHEAD
https://root.cern/js/files/zdemo.root
[HTTP/1.1 200 OK 0ms]
GET
https://root.cern/js/dev/img/RootIcon.ico
[HTTP/1.1 200 OK 0ms]
(...)
Just to make it clear … the canvas itself is displayed correctly (despite the strange error message).
In all browsers I see no problem. Do you have any special plugins?
Can you try to run in private window?
Can you remove nobrowser from URL and test again?
I open a “new private window”, display the “Console” (“Ctrl_Shift+I”), and then open your link. The strange error appears right away (without reloading the page).
I then tried without “nobrowser” and there is no error (neither in a normal nor in a private window and not after reloading the page).
I am using the Firefox 112.0.2 (64-bit) on a Windows 10 machine.
I still cannot reproduce error message, but probably found a reason. Cam you test:
https://jsroot.gsi.de/dev/?nobrowser&file=…/files/zdemo.root&item=zdemo;1&opt=
Great. The strange error message is gone (in normal and private windows and also after reloading).
(I still have the “Unauthorized” access when I try “Draw in new tab”.)
1 Like
Ping … just that the “Unauthorized” access when one tries “Draw in new tab” is not forgotten.
Thanks for pinging - now in jsroot master.
But there are much more settings, which will not be exported via URL.
You always can try to store jsroot settings as cookies - via settings menu.
But of course, cookies do not work with private browser window.
Thanks, Almost perfect.
It looks like “Draw in new tab” uses now separate credentials from the original ones.
I “Load” a file (with “credentials”) and “Draw” some canvas.
I then “Draw in new tab” the same canvas but it immediately asks for “credentials” again. This happens only the first time I execute “Draw in new tab” (i.e., using it again for anything else seems to reuse one of the provided “credentials”).
Can this be fixed so that “Draw in new tab” reuses the already provided credentials?
If you working in “Private tab”, you cannot export any credentials you typed there.
In normal tabs it should work.
I was/am working in a “normal” tab.
Also, note that: This happens only the first time I execute “Draw in new tab” (i.e., using it again for anything else seems to reuse one of the provided “credentials”).
Can it be that these two “different” credentials are kept in two different variables, which are somehow “local” to different parts of the javascript code? So that “Draw” uses one variable, and “Draw in new tab” uses the other one.
Another possible reason is that, when accessing “https://b.l.a.h/blah/blah.root” in a new tab for the first time, it somehow does not recognize that it already has credentials for “https://b.l.a.h/”, so it tries to get new ones.
Can it be that I should “clean” some cache (if yes, what exactly)?
BTW. I tried to cut the “nobrowser&” string from the link, but it didn’t help (i.e., it asked for credentials again):
https://jsroot.gsi.de/dev/?nobrowser&with_credentials&file=https://b.l.a.h/blah/blah.root&item=canvas;1&opt=
ping … just that it won’t be automatically closed
Actually, I have no idea how browser shares credentials between tabs.
It is separate topic which I never touch before.
If it helps, note that it is sufficient to “Draw in new tab” once. Even when I close this new tab and then execute another “Draw in new tab” command (in the original tab), it automatically reuses one of the provided credentials (I don’t know which one, either the original one or the one I gave during the previous new tab creation).
This happens automatically and without any special settings from JSROOT.
Maybe you need to configure http server with the files like discussed here.
In general, users have no way to modify the server’s configuration.
I am using the "CORS Everywhere " plugin (for Firefox) when accessing servers (remote and the localhost).
Anyhow, it doesn’t seem to be about CORS; the error explicitly says “unauthorized access”, not “cross-origin” (which appears if I do not switch the plugin on) and it appears only the first time it creates a “new tab” (afterward is reuses credentials).
Well … on second thought … maybe it is indeed related to the CORS. I use “File Open” (i.e., “file:///C:/.../browse.html”) in Firefox (so my browser is my “server”). It then loads your javascript and accesses remote files using “https://b.l.a.h/blah/blah.root”. However, “Draw in new tab” opens something that looks like “https://jsroot.gsi.de/dev/?nobrowser&with_credentials&file=https://b.l.a.h/blah/blah.root&item=canvas;1&opt=”, which may change the server from my own “file:///” to your “https://jsroot.gsi.de” (and that’s why it asks for credentials again).
Well, if I am right about the unfortunate “change of the server”. Maybe javascript gives the possibility to “fork”/“clone” the whole process (into a new tab). Then the new tab would behave exactly as the old one (i.e., it would still use the original “file:///”).
Normally different browser tabs share user credentials and able to reuse them.
But it depends from the authentication method.
I using authentication very seldom.
And if any - simple htdigest supported by civetweb/THttpServer.
Currently I need to fix some other issues.
Later I will try to check if something can be done.
I made test with THttpServer.
It needs some modification, but I get it running ONLY when following fields where included into response header:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: __exact_server_url__
Without such configuration saved credentials where not working. Simple * as allow-origin is rejected in such case.
I will submit soon changes for THttpServer, but if you are using any other server - it should be possible to provide such headers. Without them it does not work.
Some information I found here:
You should check comment about blocking third-parties coockies: