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. On Sat, Apr 17, 2021 at 4:41 AM Chris G <chris.gaeb...@gmail.com> wrote: > 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. > > On Friday, April 16, 2021 at 10:48:26 PM UTC+1 Daniel LaLiberte wrote: > >> 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? >> >> >> On Fri, Apr 16, 2021 at 3:15 PM Chris G <chris....@gmail.com> wrote: >> >>> 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. >>> >>> On Friday, April 16, 2021 at 6:38:00 PM UTC+1 Daniel LaLiberte wrote: >>> >>>> 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. >>>> >>>> On Fri, Apr 16, 2021 at 12:08 PM Richard Manly <rcm...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Friday, 16 April 2021 at 16:29:44 UTC+1 Chris G wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> On Friday, April 16, 2021 at 11:26:49 AM UTC+1 rcm...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> I have also seen this bug, only resolved through forcing a load of >>>>>>> library V49. >>>>>>> >>>>>>> On Wednesday, 14 April 2021 at 11:21:27 UTC+1 pescu...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> Le mercredi 14 avril 2021 à 09:10:38 UTC+2, Chris G a écrit : >>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>> -- >>>>> 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 >>>>> <https://groups.google.com/d/msgid/google-visualization-api/9861e505-a26f-468d-8e14-1e073891ab70n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> >>>> • Daniel LaLiberte >>>> >>>> • SWE >>>> >>>> • Cambridge MA >>>> >>>> • dlalibe...@google.com >>>> >>> -- >>> 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/be77e5fd-ab08-45de-b509-b3aea8f2c62cn%40googlegroups.com >>> <https://groups.google.com/d/msgid/google-visualization-api/be77e5fd-ab08-45de-b509-b3aea8f2c62cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> • Daniel LaLiberte >> >> • SWE >> >> • Cambridge MA >> >> • dlalibe...@google.com >> > -- > 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-visualization-api+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-visualization-api/d5229602-10ca-48b6-bff0-856f267d46e3n%40googlegroups.com > <https://groups.google.com/d/msgid/google-visualization-api/d5229602-10ca-48b6-bff0-856f267d46e3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- • Daniel LaLiberte • SWE • Cambridge MA • dlalibe...@google.com <dlalibe...@google.com> -- 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-visualization-api+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/CAOtcSJPmu8b72mn6AOdzbfF8%2BiBVo%2Bs1zsc2zmUd_ohf73QXqw%40mail.gmail.com.
