Google AJAX API Loader 302 Redirecting Uselessly

[JavaJive]

I do not know if this is the place to report this, but it's the only reasonably likely one I could find, so here goes.  If this is not appropriate, can someone please point me to a working link to report a problem to Google.

Currently the Google AJAX API Loader is 302 (temporarily) redirecting to a useless alternative.

Since around Friday 12th or Sat 13th June 2020, the Google AJAX loader URL ...

    http(s)://www.google.com/jsapi?<parameters>

... example of working parameters ...

    http(s)://www.google.com/jsapi?callback=onGoogleAJAXLoad&key=<my Google dev key>

... is 302 (temporarily) redirecting to a Google (server, not client, based) Static Charts loader ...

    http(s)://www.gstatic.com/charts/loader.js?<presumably entirely different parameters>

As the eventual destination URL can't load the Google Search API, this has broken the two most popular pages on my site:
    www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteCalculator.shtml
    www.macfh.co.uk/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculator.shtml

As the weekend, when work might be expected most reasonably to occur, has now passed but the redirection remains, how long is this temporary redirection scheduled to remain breaking my site?

[Philipp Wollermann]

Hi,

First, I'm sorry that something broke your site. I'll figure out what happened here and will get back to you asap.

Thank you for the excellent issue report - the details and timing information helps a lot narrowing down what might have caused this.

Kind regards,

Philipp

[Philipp Wollermann]

Hi,

I discussed this with my colleagues. Apparently over the last days a change to the /jsapi loader was rolled out that is slightly incompatible with the way you're using it. People have been discussing it on the Google Visualization API group (e.g. https://groups.google.com/d/msg/google-visualization-api/hGys_iI99bE/KCY66-zyDgAJ) - I haven't looked through all the threads there, but maybe you could find some background information about the change in that group.

There's also something here about moving to the new library loader: https://developers.google.com/chart/interactive/docs/basic_load_libs#update-library-loader-code

I'm sorry for that - we really try to avoid breaking changes, but in this case, it seems like we had the choice between completely shutting the old /jsapi API down, or installing the redirect to a similar, but not identical implementation that usually works fine, but apparently in your case breaks, due to the way you use the callback feature. It is planned that the redirection eventually becomes a permanent HTTP 301.

I checked the code on your site, but unfortunately I'm not a frontend web dev myself and can't really tell you exactly how to fix it.

My colleague told me that the issue seems to be with the callback being set to __rqs[5].wrapCB. With the new loader, the callback would have to be a global function, not an expression. In addition, the callback is called as soon as the DOM is ready, independent of what is being loaded. That's the behavior of the jsapi loader, I believe, though it is not clear and timing could make a difference in actual behavior. That is, if the jsapi loader was able to return things faster, then the DOM being ready might not be enough. In case that turns out to be an issue, the callback should be moved to the google.load call.

The callback in the google.load settings can be an actual function that is available in the lexical scope of the google.load call, rather than the name of a global function.

I hope this helps. If you run into issues, please feel free to follow up.

Kind regards,

Philipp

[JavaJive]

First, thanks for coming back to me so quickly.  Please see specific points below ...

On Monday, 15 June 2020 19:04:13 UTC+1, Philipp Wollermann wrote:

Hi,

I discussed this with my colleagues. Apparently over the last days a change to the /jsapi loader was rolled out that is slightly incompatible with the way you're using it. People have been discussing it on the Google Visualization API group (e.g. https://groups.google.com/d/msg/google-visualization-api/hGys_iI99bE/KCY66-zyDgAJ) - I haven't looked through all the threads there, but maybe you could find some background information about the change in that group.

This is a deeply complex issue, well at least three issues really ...

First the Google Visualization API is not used anywhere on my site.  The Google Static Charts service is, but that is yet another issue, see below ...

Second, the original AJAX loader that has now been 302'd provided a common AJAX API to load any of several possible other Google APIs  -  search, maps, etc  -  and I was using it to load both of these I've mentioned.  Therefore to redirect it, apparently without any warning whatsoever, to a loader for a totally different service  -  apparently another URL for the Google Static Charts service but a different one to that I'm using  -  which ISN'T AND WASN'T EVER DESIGNED TO BE CAPABLE OF PROVIDING THE SAME FUNCTIONALITY as the AJAX API that has been redirected to it, is just plain daft and illogical.  If the AJAX loader has been superceded by a newer version, as your following paragraph suggests, why was it not redirected to that?

Thirdly, there's the difference, confusing to many, between the Google Visualization API which runs within the user's browser, which my site doesn't use, and the Google Static Charts service, which runs on a Google server, and which the Terrestrial TV Aerial Calculator uses to draw a signal profile, as well using as the search and maps APIs already mentioned.  The Satellite Dish Calculator doesn't use either of these image APIs, only the search and maps APIs.  After the static API was deprecated some years ago, I made the following post asking about possible replacements and received the answer advising me to sit tight that you can read there:

(Obviously, the link there to my TV Aerial Calculator doesn't work now, but you can follow the one below as an alternative demo of how the Static Charts service is used  -  note that, apparently contrary to the discussion that you linked to in your paragraph above, thankfully it still works! (To see the profile diagram drawn by the Google Static Charts service and the URL used to generate it, scroll down to the bottom)

https://groups.google.com/forum/#!topic/google-visualization-api/wDeql067o80

http://www.uktvpath.appspot.com/?x1=-6.243174&y1=57.385989&z1=64&x2=-5.739170&y2=57.273276&z2=10&pr=True&cb=CallBack&db=True

There's also something here about moving to the new library loader: https://developers.google.com/chart/interactive/docs/basic_load_libs#update-library-loader-code

Thanks, I'll take a look at that.

I'm sorry for that - we really try to avoid breaking changes, but in this case, it seems like we had the choice between completely shutting the old /jsapi API down, or installing the redirect to a similar, but not identical implementation that usually works fine, but apparently in your case breaks, due to the way you use the callback feature. It is planned that the redirection eventually becomes a permanent HTTP 301.

As stated above, that is an entirely inappropriate redirection to make.  It would be less confusing just to return a 404.

I checked the code on your site, but unfortunately I'm not a frontend web dev myself and can't really tell you exactly how to fix it.

My colleague told me that the issue seems to be with the callback being set to __rqs[5].wrapCB. With the new loader, the callback would have to be a global function, not an expression. In addition, the callback is called as soon as the DOM is ready, independent of what is being loaded. That's the behavior of the jsapi loader, I believe, though it is not clear and timing could make a difference in actual behavior. That is, if the jsapi loader was able to return things faster, then the DOM being ready might not be enough. In case that turns out to be an issue, the callback should be moved to the google.load call.

I already know exactly why the page is failing, but can't easily do anything about it, because the actual failure is of Google's making.  Both pages begin with a form to allow the user to enter data, which is quite complex and needs other components  -  a form handling script, a script to query the UK's Ordnance Survey, Google's search API for looking up the coordinates of place names, a magnetic calculator for compass use, etc  -  loaded before it can work properly, so, to prevent the user suffering the frustration of entering data before it can be processed and which may even be wiped out by the form initialisation process, the form is loaded in a locked state, only being unlocked when the needed components have loaded.  In order to improve loading times, all but the most basic of these components are loaded dynamically by a self-written script, Requests.js, designed to be cross-browser compatible, which, contrary to your theory above, still loads successfully the now wrong Google API which has been 302 redirected to  -  it's the following line in the callback for this load that asks the wrong code now supplied by Google to load the search API which, naturally enough, fails:

google.load( 'search', '1', {callback:onGoogleSearchLoad, nooldnames:true, nocss:true} );

Because of the dynamic loading, there has to be a mechanism to decide if and when all the needed components are present and the form can be unlocked for the user to begin, and this is achieved by each dynamically loaded component's callback doing whatever initialisation is needed by that particular component, setting it's own 'loaded' flag to true, and finally calling a routine which checks all the 'loaded' flags.  When the process was working properly with the correct Google URL, the callback for the last component to complete loading would find all the 'loaded' flags set true, and so call the function to intialise and unlock the form, however now that the Google search API is never loading, its 'loaded' flag is never set to true, so the form can never unlock even if the script continued running, but in fact, it bombs because the call to load the Google search API fails with an error that kills it.

[JavaJive]

See further note below ...

On Monday, 15 June 2020 19:04:13 UTC+1, Philipp Wollermann wrote:

Hi,

There's also something here about moving to the new library loader: https://developers.google.com/chart/interactive/docs/basic_load_libs#update-library-loader-code

No, that discusses changes to the Google Visualisation API that I don't use.  We're discussing the Google AJAX API loader which is now being redirected inappropriately to this Google Visualisation API despite the latter not being a replacement for the former in terms of functionality.

[JavaJive]

Please see the following Google help page which has a current date:
https://support.google.com/code/answer/74501?hl=en

[Paul Irish]

Hi,

I'm sorry this broke you. I personally agree it doesn't make sense to redirect the loader url to a new one that doesn't have backwards compatibility.

As for your particular situation... I tried to fix your webapp. Basically it involves removing the loader.

I've written up a diff that fixes things: https://gist.github.com/paulirish/a9d67166c91ab390d9585155b15be8de

a few notes:

1. The 'search' API isn't supported at all by the new loader. But also 1) i'm not sure it's supported by Google at all any longer ... and 2) I don't think your webapp uses the API anymore.  So I just removed the calls to attempt to use it. 
2. This would almost work but the callback parameter handling in the new loader doesn't work if the loader isn't the last <script> in the DOM. (And in your case, it's the first). 
3. If the callback were good, we'd be in business, but there's a console message about loading the maps API via the loader being deprecated. So I figure let's just drop the loader entirely.
4. So that's what you'll see in the diff, we dynamically load the maps API and drop loader/search entirely.

Good luck

[JavaJive]

Thanks, but actually, without wishing to cause offence, no thanks,
please see below for why ...

On Tuesday, 16 June 2020 21:47:14 UTC+1, Paul Irish wrote:

Hi,

I'm sorry this broke you. I personally agree it doesn't make sense to redirect the loader url to a new one that doesn't have backwards compatibility.

There's no question of backwards compatibility here, because the 'new loader' is not actually a 'loader' as such!   As I've now discovered, it's an entirely DIFFERENT script, it's actually the Google Visualisation API, which I don't even use!  According to Google's own documentation, the loader that's been redirected is actually CURRENT, so this change has broken compliance with Google's own documentation!  For proof, please see the following, which is a current page with a 2020 date ...
https://support.google.com/code/answer/74501?hl=en
... so this change doesn't seem to be intentional, but an error by someone or other, which needs to be rolled back asap.

 

As for your particular situation... I tried to fix your webapp. Basically it involves removing the loader.

I've written up a diff that fixes things: https://gist.github.com/paulirish/a9d67166c91ab390d9585155b15be8de

a few notes:

1. The 'search' API isn't supported at all by the new loader.

That's because the 'new loader' is not actually a 'loader' as such, it's something entirely different, see above.

1. But also 1) i'm not sure it's supported by Google at all any longer

According to Google's own documentation, it is, see above.

1. ... and 2) I don't think your webapp uses the API anymore.

Of course it uses the Google Search Web API, otherwise I wouldn't be cluttering up my page by bothering to load it.  What happens is that if either a user chooses a world place name search in the form, or attempts to use an old discontinued UK postcode which isn't found by querying UK Ordnance Survey, then Google Search is queried for the co-ordinates.

1.   So I just removed the calls to attempt to use it. 

That's not going to help users of either page who live outside the UK.

1. This would almost work but the callback parameter handling in the new loader doesn't work if the loader isn't the last <script> in the DOM. (And in your case, it's the first). 
2. If the callback were good, we'd be in business, but there's a console message about loading the maps API via the loader being deprecated. So I figure let's just drop the loader entirely.
3. So that's what you'll see in the diff, we dynamically load the maps API and drop loader/search entirely.

I get the impression that you don't understand how my page loads.  See the console log below.
 

Good luck

By uncommenting some debug lines in the original source, the following console log output is obtained.  You can see from it that the *ONLY* problem is Google's inappropriate redirection of the loader script to an entirely different one that was never intended to have the same functionality.  As this goes against Google's own current documentation, and is clearly an error by someone, it needs to be rolled back asap:

Loading Google AJAX Loader ...
SatelliteCalculator.shtml:216:2
DOMRdy:false, GSrchRdy:false, WMM:false, UKOSReqRdy:false, Proj4Rdy:true, Sats:true, Rotors:true, IningCalc:false
SatelliteCalculator.shtml:346:2
DOMRdy:false, GSrchRdy:false, WMM:false, UKOSReqRdy:true, Proj4Rdy:true, Sats:true, Rotors:true, IningCalc:false
SatelliteCalculator.shtml:346:2
DOMRdy:false, GSrchRdy:false, WMM:true, UKOSReqRdy:true, Proj4Rdy:true, Sats:true, Rotors:true, IningCalc:false
SatelliteCalculator.shtml:346:2
Google AJAX Loader ready: 502ms
SatelliteCalculator.shtml:210:2
Loading Google Search ...
SatelliteCalculator.shtml:211:2
Document ready: 518ms
SatelliteCalculator.shtml:340:2
DOMRdy:true, GSrchRdy:false, WMM:true, UKOSReqRdy:true, Proj4Rdy:true, Sats:true, Rotors:true, IningCalc:false
SatelliteCalculator.shtml:346:2
Error: Module "search" is not supported.
loader.js:93:451