The "go" button doesnt do anything/Stuck on "enter location" screen

[netbymatt]

The "go" button doesnt do anything/Stuck on "enter location" screen

[netbymatt]

@yllekz Thank you for this capture. I now know where the problem is and was able to recreate it. It has to do with running on a server locally that isn't localhost.

I'm deliberately matching the protocol with this line, which causes a downgrade of the call to https://geocode.arcgis.com/...

ws4kp/server/scripts/modules/utils/fetch.mjs

Line 24 in 20b4d22

url.protocol = window.location.hostname === 'localhost' ? url.protocol : window.location.protocol;

I need to dig into the git history and see why this line exists before I can come up with a solution.

The custom.js error is expected. It's a feature that I put in so (in my case) I can inject the github links on https://weatherstar.netbymatt.com It always looks for the file, and if it's there it'll get run. Otherwise all it does is produce a 404 error in the network log.

[Node815]

Mine doesn't work if I run it locally from my ip:port and hit the "Go" button after entering my location- but if I reverse proxy it - it works.

[yllekz]

I turned off all my adblockers/etc and had the network inspector open both when loading the page and doing "nothing"

I noted two errors, the first appears to have to do with "custom.js" and "NS_ERROR_CORRUPTED_CONTENT" when simply loading the page:

Request:
GET /scripts/custom.js HTTP/1.1
Host: myservernamehere:8047
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://myservernamehere:8047/
Cookie: _pk_id.1.db42=3c0056927a74cd18.1691768775.; remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IithV01Xa3h6Qm9zWVU0V0JBR3l2WGc9PSIsInZhbHVlIjoiNVZtVUthVkhmd3hhRDR0V1RMZW5TOHY5NGF5eXdoa0NlTjVuMVJ4anNjdCtDQ21BU2hnSlpyeGlGa05qc0FjWmVoRnN1Q2ozTm1ZYjFPUDduVk5XMzQ5eXRpQmpXVXpMRkNKV1kxWGdkc2llL296Y1grTi9Ibk1zWTFRMUIwcVFmVUtKRUEzalVwQ0hNVGNBR1FEL0pweFhXL2dFZkpXbVd5bU9FQjVrdEZLVWlMeHNoZjFJcEtCVlJLSkJ4blZzTVY4ODVVZnRKbXBNcVVwUkpGaDRwQmhDL1VIV014clF1MXZ2UG1sSUVmZz0iLCJtYWMiOiJjMzRiNjQyZDcxZDM3MWZmMmUxYWNkODgzOWUyM2NmOGUyYWQ3ZmRkYzM4MDY2MTY5ZmUxZmQwYTYzMDY3NWM0IiwidGFnIjoiIn0%3D; XSRF-TOKEN=eyJpdiI6IlhtM2o5dUJJdFZlM052SC8zcjFSSmc9PSIsInZhbHVlIjoiVldhejYyWWpjNjhFY3lPczdYZlYrZG50VFJJWnJ5VlJJbVI1ZlprYzJwSzJKaFVWUHdpemxtdUhEVzRTL0MvS2pzdzJEcG9XZ09FL2lFWFk5VklGczU4L2VqcFovdjRRVXV5SkRnMlpUckNKaDFKWEpJK0hJS0dVamVqRTZvZ3ciLCJtYWMiOiI5YzM0MDk2OTQ2NTEwZTQxZTlmNDU1NmQxOTYzNGUxNGU5YWI4M2MwZTRjMmY1ZGJhNTc4OGExMmE2NDY2NzI1IiwidGFnIjoiIn0%3D; heimdall_session=eyJpdiI6ImgvM3I5NzhMQkh5bXdMRlpUNXo1dXc9PSIsInZhbHVlIjoiT0xLUkpIc2RFUld5MW0xNkpVMU9CSEVlR3I3ckM4K0RRYWJ4aTJNaGNubzIvSmFhbzRycHZ1VUNNQlNuVGF0SmR4VWpWZXphSFdtS2hRRDBzOGFZKzUrU2VlUjJCSnduQlB5ZWxtWGFHZkRkV3VWS0NZbjFWOGlXd25nZnNjRlEiLCJtYWMiOiJiNzY3MTQ0NDY1ZWJjYWRhMTFhNzA4MWY0OGNhODhkNTlmMTRiZDZmZDQwNjA2NGE3OWFhNjJjMWYwMmYwZTE4IiwidGFnIjoiIn0%3D

Response:
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 156
Date: Wed, 08 May 2024 20:28:22 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Then, I get this when entering a sample location ("CORS Missing Allow Origin"):

Request:
GET /arcgis/rest/services/World/GeocodeServer/find?text=Boston+College-Main+Campus%2C+140+Commonwealth+Ave%2C+Chestnut+Hill%2C+MA%2C+02467%2C+USA&magicKey=dHA9MCN0dj02NjIyYjk2NiNsb2M9NzM5NzE2MCNsbmc9NDEjcGw9NTc1MTEwMyNsYnM9MTQ6MTI4OTUwMjc7MTA5OjcyMTY5NjE4Ozk6MTU5MzE5MTc7MjozNjQ2MjQwODswOjU5OTE5MzI1OzEwOjI0NzkxNyNsbj1Xb3JsZA%3D%3D&f=json HTTP/1.1
Host: geocode.arcgis.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://myservernamehere:8047/
Origin: http://myservernamehere:8047
Connection: keep-alive

Response:
HTTP/1.1 400 Bad Request
Date: Wed, 08 May 2024 20:31:00 GMT
Content-Type: application/octet-stream
Content-Length: 66
Connection: keep-alive
Server: nginx

These seem to be the only clues in an otherwise quiet/errorless network log.

[bgutman]

It is working for me now in firefox windows10. I run ws4kp on a different computer on the local lan.

[netbymatt]

This is an unfortunate issue with the upstream data from the national weather service. I checked "Dayton Ohio" myself as well as my location and it gets about 3 steps into getting forecast data and dies when it requests the "gridpoints" api:
https://api.weather.gov/gridpoints/ILN/44,69/stations
If you go to that page there's you'll get a message stating it is offline until 1/1/2024.

There's an ongoing discussion about why this happened and the overall reliability of the NWS API on their github repo weather-gov/api#688

I do acknowledge that Weatherstar doesn't do a good job of annunciating errors that are this early in the process. The "gridpoints" api is kind of the lynchpin to getting all of the other data provided. Had something more specific such as radar, hourly forecast or current conditions failed it's handled much more gracefully and will show an error on the table of contents screen and skip that display when cycling through all the displays.

[mattatobin]

A simple precheck for a known good response should at least let you catch it.

AS FOR HANDLING IT VISUALLY.. WELL, heh, could go for an amiga error or could feed the error into the special weather statement scroller all red and the like and follow up with the NWS announcement if any. Of course one could just print a plain old try again later error on the page too.

[mattatobin]

BTW for me, it is working again now that the end point seems to be back up. Figured I'd report.

[netbymatt]

Great! I'm seeing it work now too.

[August988]

thanks!

[yllekz]

This is still happening for me.
Update: got it working in Chromium but it's still broken in Firefox. Might be a browser compatibility issue....

[mattatobin]

I had a period of a few hours the other day when it wasn't Go-ing but it resolved it self. This was with a blink-based engine. I will check Gecko and forks as well and report back on browser capability for you.

[mattatobin]

Everything seems to be functional on Gecko, Blink, Goanna/UXP (represented by my retired Navigator), and SeaMonkey. Though, seems to be a touch of styling issue for them on the text for the options.

[yllekz]

Interesting, I can't get it to work in Firefox or Librewolf, oddly enough (even with new profiles). I'll keep plunking away at it to see what makes it not function.

[netbymatt]

Hi guys. This is still an ongoing, intermittent problem with api.weather.gov. I'm fighting with it at my other weather app as well Temperature.Express.

One thing that would be very helpful in confirming this and helping me to get started on visualizing the proper error messages is to note any errors in the Network tab of Dev Tools in any browser. Any request to api.weather.gov that's red, pass along the requested URL and the status code, all available from the Network tab.

[mattatobin]

Could client rate limiting be a factor? Like some users who always have it up are being cut off from the api while others who run it occasionally aren't?

[netbymatt]

I don't believe this is rate limiting. Currently there are no API keys in use per the weather.gov documentation. That means that everyone who has a copy of this open is likely unique and not counted against other weatherstar users. My analytics data for this also says there just aren't enough users to hit any kind of rate limit.

[mattatobin]

Any luck finding a place where you can insert an early check to gracefully error out?

[bgutman]

Un-publish the rates for api.weather.gov for the average user is able to:
Hit the API 30 times/sec without issue in 2 minute period
Hit the API 75 times/sec in any 5 second period and not be blocked.
If you are blocked, the service will return a Reference id like #18

In firefox the go button does not work for me either, looking at the network tab in developer tools. I get a blocked 400 error for: geocode.arcgis.com
Type:octet stream
Transferred: CORS Missing allowed Origin

I can open it chrome at same time and have no issue.

[netbymatt]

In firefox the go button does not work for me either, looking at the network tab in developer tools. I get a blocked 400 error for: geocode.arcgis.com
Type:octet stream
Transferred: CORS Missing allowed Origin

Thanks for capturing the info surrounding this problem! What version of Firefox and what OS?

[bgutman]

Windows 11 firefox 125.0.2 64 bit

[scroguard]

i can confirm this is a firefox only issue. i'm experiencing it as well. i'm running arch linux with the latest (as of 05/08/24) updates applied, firefox version 125.0.3 64 bit and i am unable to get past entering the zip code. however, if i open it in chromium everything works as expected.

[netbymatt]

I'm still struggling to reproduce this one. I'm running 125.0.3 on Windows 11. I've been watching the CORS headers as @bgutman noted in his report and didn't see anything out of the ordinary there.

I'm starting to think it's related to either a privacy setting, or an extension like an ad-blocker. I did turn set Enhanced Tracking Protection to Strict and did not cause this issue.

Is anyone running a privacy, ad-blocking, vpn or custom dns server who's seeing these errors? I'd like to get the same one going to further track this down.

[scroguard]

i do have various extensions enabled, and i figured those might be the cause of the issue. so i shut everything down. i even went as far as to open a private mode window which disabled all extensions on my system and still encountered the issue.

[scroguard]

here is a screenshot of an error i finally found in my network log in firefox:

i also received the cors error mentioned by yllekz

on top of that i found the other items listed in this screenshot:

the first line for custom.js shows a 404 error, the rest are all 304 not modified errors.

i am running the app via docker in unraid 6.12.10.

[TVsIan]

I'm experiencing this issue if I access the page via my ddns address, port forwarded by the router. But if I'm accessing it via LAN, everything seems to work except for the Copy Permalink function, which does nothing when clicked. I'm not sure if that's related or a different issue.

Also running the latest version in Docker on an Unraid server.

[netbymatt]

Sorry I forgot to post here. I addressed this last week in v5.11.3 7be2049. Does anyone have feedback as to whether this is still happening with the new version?

[scroguard]

i can confirm it is now working for me as well, firefox in arch linux.

[yllekz]

Works for me now! Thanks! We fixed it!