Chrome doesn't work as well as Firefox when talking to station

[philip]

If I use Chrome (I'm on version 90), then I get these errors (I'm running FW 9.2 RED)

Code:

script.js?9.2:1 A parser-blocking, cross site (i.e. different eTLD+1) script, http://www.lightningmaps.org/control/?js&station=1182&fw=9.2&ext, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ script.js?9.2:1
script.js?9.2:1 A parser-blocking, cross site (i.e. different eTLD+1) script, http://www.lightningmaps.org/control/?js&station=1182&fw=9.2&ext, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ script.js?9.2:1
?js&station=1182&fw=9.2&ext:22 Uncaught ReferenceError: $ is not defined
    at ?js&station=1182&fw=9.2&ext:22
index.cgi?action=signals:20 Uncaught ReferenceError: $ is not defined
    at index.cgi?action=signals:20

It looks as though jquery doesn't get loaded early enough. $ does end up being defined. I've tried clearing the cache etc, but it doesn't seem to help.

FIrefox (87) works as expected.

[patrickrall]

If I use Chrome (I'm on version 90), then I get these errors (I'm running FW 9.2 RED)

Code:

script.js?9.2:1 A parser-blocking, cross site (i.e. different eTLD+1) script, http://www.lightningmaps.org/control/?js&station=1182&fw=9.2&ext, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ script.js?9.2:1
script.js?9.2:1 A parser-blocking, cross site (i.e. different eTLD+1) script, http://www.lightningmaps.org/control/?js&station=1182&fw=9.2&ext, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ script.js?9.2:1
?js&station=1182&fw=9.2&ext:22 Uncaught ReferenceError: $ is not defined
    at ?js&station=1182&fw=9.2&ext:22
index.cgi?action=signals:20 Uncaught ReferenceError: $ is not defined
    at index.cgi?action=signals:20

It looks as though jquery doesn't get loaded early enough. $ does end up being defined. I've tried clearing the cache etc, but it doesn't seem to help. Mesa barra para cocina

FIrefox (87) works as expected. 

It will most likely be solved when you update the browser to the latest version

[cutty]

Revert to Firmware 9.1, where Jquery is installed on controller. It was moved because memory on controller is about exhausted.
or
Tell Chrome to allow the "cross site" download, it it's blocking it, and will allow you to change it.
or
don't use Chrome.
Gui loading can be problematic at times also because of high activity.  It's the first thing sacrificed if a lot of data is being processed.

[cutty]

Revert to Firmware 9.1, where Jquery is installed on controller. It was moved because memory on controller is about exhausted.
or
Tell Chrome to allow the "cross site" download, it it's blocking it, and will allow you to change it.
or
don't use Chrome.
Gui loading can be problematic at times also because of high activity.  It's the first thing sacrificed if a lot of data is being processed.

What is your station number? There's something puzzling about that query.

[hazelnut]

Gui loading can be problematic at times also because of high activity.  It's the first thing sacrificed if a lot of data is being processed.

It could be worth adding this to the docs, I've noticed that the GUI can be a bit erratic at times with pages only partly rendering or not rendering at all.  If you enable auto refresh and wait a bit it comes back again, but it's a bit disconcerting when you first hit it.

[Eric.Lee]

I'm seeing the same problem, in all three major browsers (Chrome, Edge, Firefox).  I've seen the GUI work correctly a couple of times, once in Chrome and once in Firefox, but the vast majority of time it doesn't work.  Strangely, the difference between not working and working appears to be in the "/index.cgi?action=status" HTML file that's loaded from the device firmware.  When the GUI is broken, the HTML has this on line 9:

var load_script="http://www.lightningmaps.org/control/?js&station=1163&fw=9.2";

When the GUI works, the HTML has this on line 9:

var load_script="http://tracker.lightningmaps.org/control/?js&station=1163&fw=9.2";

What's the difference between those two URLs?  Well, the script file at www.lightningmaps.org does NOT include JQuery, which breaks the site, while the script file at tracker.lightningmaps.org DOES include JQuery, which makes the site work.  So how the heck does the device usually serve up the broken URL but very occasionally the other, working, URL?  I have no idea.  It doesn't appear to be related to cookies or anything, as totally clearing all site data doesn't appear to affect it.

You can see the difference in the content of the two URLs if you just navigate to http://www.lightningmaps.org/control/?js...fw=9.2&ext vs. http://tracker.lightningmaps.org/control...fw=9.2&ext in your browser.

[hazelnut]

Nice piece of detective work!  Yeah, I'd noticed it on multiple browsers as well, first I thought it was yet another Firefox glitch but then got the same thing in Chrome and Edge as you have.

If its script-based is it one of the scripts loaded externally (relatively easy fix) or in the firmware (less easy fix)?  If the latter it may still be possible to correct it via a firewall rule that redirects www.lightningmaps.org to tracker.lightningmaps.org, assuming there aren't other accesses to www.lightningmaps.org.