"b.split is not a function" since version 50

[Chris Gaebler]

I have a product that enables sites to use Google Charts in the Joomla CMS. Since version 50, a small number of users have reported the chart error "b.split is not a function". This is a small error on a red background that appears in the chart element instead of the chart itself, so a Javascript error caught by the Charts API itself.

By debugging, we know that the error occurs deep within the Google code, but since we don't have the source, it's difficult to follow, and impossible to figure out the cause.

Since only a small number of sites are affected, we assume that the problem is provoked by another plugin, and we have confirmation from one user that that was the case for him. But we have other users unable to identify the provoking plugin.

By Googling "b.split is not a function", I can find more sites affected by the error. Neither of these examples uses our software, and in the first case, it's not a Joomla site. Quite possibly the owners of these sites are not aware of the problem yet:

http://gestiondepymes.es/features/google-charts/area-chart

https://www.kankakeehealth.org/infectious-disease/covid-19-response-and-recovery/ (open the sliders to see the errors)

These are just examples. There are more.

For our own users we have "solved" the problem by enabling them to load API version 49, but obviously we would like to get to the bottom of this.

Can anyone shed any light that would help us to track down the problem?

[pierre escudie]

Hello, 

I had the same problem since yesterday using the latest version of the library.

Like you in the meantime I blocked the loading of the library on version 49 while waiting to find a cause and a solution at the root of the problem.

If anyone has the reason for the problem and a way to fix it I'm also interested.

[Richard Manly]

I have also seen this bug, only resolved through forcing a load of library V49.

[Chris G]

I have now identified the problem for several sites, including the two examples in my original post. Where sites are using the old (jsapi) method of loading the Google Charts code, and the site also loads MooTools (tested with v1.4.5), the "b.split is not a function" error always occurs. The mere presence of MooTools is enough to trigger the error. For these sites, the problem can be fixed either by switching to the new (loader.js) method of loading the Google Charts code, or by removing MooTools from the page. I would still like to know why this is the case,  but at least we know how to fix it.

We understand that other cases exist that trigger the error when using the new (loader.js) method of loading the Google Charts code, however I don't currently have a case I can work on.

[Richard Manly]

Hi Chris,

If it's any help:-

On my page mootools is definitely loaded.

I'm adding the script using the following:-

$document->addScript('https://www.gstatic.com/charts/loader.js');

google.load("visualization", "1", {packages:["corechart"]});

The above triggers the error.

Changing the corechart load to;-

google.charts.load('49', {packages: ['corechart']});

...works

[Daniel LaLiberte]

I am a bit surprised that loading the old jsapi, which now redirects to the new loader, causes this indirect problem resulting in the "b.split" error, and only (?) when MooTools is also loaded.  But I suspect this is due to some variation in load order (since the redirect imposes a delay until after the new loader is loaded), combined with how and when polyfills are applied.

Sorry for the confusion this is causing, but I am glad people are finding workarounds.  Freezing on version 49 is not desirable, however, so I am curious to learn what the underlying cause is.

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/9861e505-a26f-468d-8e14-1e073891ab70n%40googlegroups.com.

--

• Daniel LaLiberte  • SWE  • Cambridge MA  • dlaliberte@Google.com

[Chris G]

Thanks for the timing hint. That fits with some of the information we are getting from users, that the problem is inconsistent.

I got a little further with debugging. When MooTools is loaded, the error is triggered from the b.split(",") in this code in the jsapi (around line 10849 in the version formatted by Chrome dev tools):

function gvjs_cn(a) {

    return Array.from(a.jk).map(function(b) {

        b = b.split(",");

        return {

            row: parseInt(b[0], 10),

            column: parseInt(b[1], 10)

        }

    })

}

Setting a break point on the b.split(","), I can see that b is an object, not a string, which is why b.split is not a function.

When MooTools is not loaded, the b.split(",") line is not executed at all. It sounds bizarre but it's true. With a breakpoint on that line, the chart is drawn without hitting the breakpoint. In both cases, the value of b is the same, it's an object of type 'Set' with value 0.

MooTools contains an implementation of Array.from() which presumably works differently from the standard one.

I'm tempted to say that any usage of MooTools with API v50 should be avoided.

[Daniel LaLiberte]

I bet it is the MooTools polyfill that implements Array.from() differently, by not supporting the Set object, or by returning something it probably should not.

Here is the source of the function with the b.split call:

  getCells() {
    const cells = Array.from(this.selectedCells_);
    const selection = cells.map((ind) => {
      const indexes = ind.split(CELL_INDEXES_SEPARATOR);
      return {
        'row': parseInt(indexes[0], 10),
        'column': parseInt(indexes[1], 10)
      };
    });
    return selection;
  }

I see on https://mootools.net/blog that:

Array.from deprecated, now called Array.convert: Following the conclusion of the ES6 specs we know now that Array.from will have a different implementation than the one MooTools uses.
Because of this we renamed Array.from to Array.convert to not overwrite the Native implementation.
We kept it as it was though in the compat layer for compatibility reasons if you really to use it still.

So, what do you think we should do about this?

To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/be77e5fd-ab08-45de-b509-b3aea8f2c62cn%40googlegroups.com.

[Chris G]

I think we can safely say that MooTools < 1.6.0 is the cause of the problem. The old or new methods of loading the Charts API is probably just one of several factors that can affect the order that the scripts initialise. If MooTools initialises first, it takes over the Array.from() method, resulting in the b.split error. 

I can confirm that the problem does not occur with MooTools 1.6.

I suppose one could ask if the change in v50 that provoked this problem was really necessary? Although it's not strictly Google's responsibility to fix this, if it's an easy change, it would save a lot of people a lot of hassle.

[Daniel LaLiberte]

Thanks for verifying that this issue is specific to MooTools < 1.6.0.

This particular change that uses Array.from (which I made, actually) is part of a large migration of old code to use ES6, and from there, to use TypeScript, and along the way, avoid using some parts of the internal Google Closure code which has long been deprecated.  In this case, it was the Closure Set class.  This particular error might very well be the first of many other bugs that would show up if not for the first one, and there will likely be more going forward, as the migration continues.

I see there might be a simple workaround for this particular issue, however, which I can implement for the few uses of Array.from(set).  See the answer from Bharata in  https://stackoverflow.com/questions/36810940/alternative-or-polyfill-for-array-from-on-the-internet-explorer

I'm making that change now, but it won't be released until v51, unless more serious problems surface with v50.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/d5229602-10ca-48b6-bff0-856f267d46e3n%40googlegroups.com.

[Ralf Meyer]

Many thanks for this hint.

[Chris G]

Yes, thanks for all your help with this Daniel. 

I suspect a lot of people will stay with v49 until that somehow comes back to bite them. The long-term solution for Joomla sites is to eliminate MooTools. For others, try to get to MooTools 1.6.