Open johnfrancis-hoth opened 4 years ago
@johnfrancis-hoth I just fixed this issue in an app of mine by adding this script tag before the Google one:
<script type="text/javascript" src="https://polyfill.io/v3/polyfill.min.js?version=3.52.1&features=Object.assign"></script>
@Jamesking56 thanks - that's got it working in IE.
Still broken trying to create a PDF using wkhtmltopdf ... wonder if its the same issue - though that's webkit.
Yes, it is object.assign in the loader.js that is crashing ie11. It is causing us a lot of problems. There is no notification of lack of support on ie11 that I can see, so hopefully this will be fixed rather than having to use a workaround? It is in 90,18 of the loader.js
I was wrong - the polyfill fix has got it working in wkhtmltopdf too.
It is a Internet Explorer specific issue, IE doesn't support Object.assign. https://caniuse.com/#feat=mdn-javascript_builtins_object_assign
@johnfrancis-hoth I just fixed this issue in an app of mine by adding this script tag before the Google one:
<script type="text/javascript" src="https://polyfill.io/v3/polyfill.min.js?version=3.52.1&features=Object.assign"></script>
If you don't want to use an external library, you could also use the polyfill from MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign
The loader was updated to change 'upcoming' to '49', and I also made one small change to clone the settings argument of google.charts.load(version, settings), to avoid changing the user's settings. This is done with settings = {...settings}
and I can see in the compiled binary that this is compiled into: b=Object.assign({},b)
.
So yes, that is the culprit. I have previously removed explicit use of Object.assign(), just to avoid this problem with conflicting polyfills, or the lack of a polyfill for Object.assign. I didn't expect the problem to reappear in this way. I'll investigate whether there is a reliable way to avoid this.
@dlaliberte do you think this will be a relative quick update to resolve or something that will that will take longer like days/weeks (or not all)? Thanks!
I should be able to fix this in a couple hours.
@dlaliberte do you have an update on when you might have this fix available ? We are impacted for a production application and will be able to verify the fix as soon as it has been published. thanks.
This is more difficult than I imagined for several reasons. I may have a change that works, but I haven't been able to verify it yet due to lack of tests, and other complications getting IE11 to use an updated version of the loader.
If you want to test the modified loader that I hope will work, you can change "loader.js" to "testing-loader.js".
On Thu, Jul 9, 2020 at 8:00 PM David Waters notifications@github.com wrote:
@dlaliberte https://github.com/dlaliberte do you have an update on when you might have this fix available ? We are impacted for a production application and will be able to verify the fix as soon as it has been published. thanks.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/google-visualization-issues/issues/2841#issuecomment-656407476, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELGDOTS5EEDW6O7KZMBQTR2ZKZLANCNFSM4OVOWQYA .
-- Daniel LaLiberte https://plus.google.com/100631381223468223275?prsrc=2 dlaliberte@Google.com dlaliberte@google.com Cambridge MA
Thank you for your prompt reply, Daniel.
The workaround provided by @Jamesking56 above works for us at the current time which was to add the following prior to the Google javascript tag :
Once you are comfortable with the permanent fix we can verify it for you pretty quickly if that helps any. We will go ahead and push the workaround fix above into production within the next few hours then. Good luck with it.
P.S. - We plan to remove our temporary production workaround patch after your permanent fix is available so that we do not have to have an additional dependency on pollyfill.io long-term.
We also have a production application impacted and using the polyfill works as a workaround.
If there is a way to revert back to the prior functionality to restore production operations for Internet Explorer browsers to allow more time for the code fix and testing to be completed, that would be ideal. In our particular case, we are using GWT and are not directly controlling the name of the javascript loader.js URI name.
Unfortunately, the change that breaks the loader for IE11 is also needed to avoid another problem. So, moving forward, after wrestling with the jscompiler and testing tools to make a proper fix, I'll just replace the code that is compiled into Object.assign(...) with a simple loop to clone the object. If you can clear your browser cache, you should see it now. Otherwise it will take a couple hours to expire.
Thank you for that information, Daniel. We are verifying your new fix now.
@dlaliberte I know it is getting late in your time zone this evening, Daniel, but I was curious whether you are planning to make a change on Friday July 10th as well, or if the changes you have made up to this point are the last changes you plan to make before the weekend or early next week.
I only ask because we are trying to put together plans as to exactly when (or whether) to deploy our pollyfill.io hotfix patch to our Disaster Recovery site vs. leaving out the pollyfill.io workaround patch that we have already deployed to our Primary site which resolved our production downtime issue.
I would like to pull the pollyfill.io workaround patch back out as soon as it is no longer needed.
I don't expect to make any more changes, hopefully not until July 22, when 'current' becomes '49'.
But if this last update turns out to break something (internal to Google), which I would find out about in the middle of the night, then I might be reverting this last change.
By the way, many of the loader changes over the last several months were motivated by trying to keep people still dependent on the jsapi loader happy. We have finally reached the phase of shutting down the UDS server (where the jsapi loader lived), so I expect that things should stabilize again soon.
Thanks, @dlaliberte , for that information so that we can plan for our upcoming mid-July and late-July release events.
Also, I have verified that your current version works properly with Internet Explorer now by running against our Disaster Recovery site's production-like codebase one version back that does not contain the pollyfill.io workaround patch.
Thanks for your help on this @dlaliberte, are the previous builds of the loader available for us to use? We're thinking about pointing our applications to an older build of the loader for IE11. Also, is there any release notes for the loader? I can't seem to find them.
If you want to use a previous version here is the way:
www.gstatic.com/charts/48/loader.js
Note you will need to refer to specific versions when using the loader.
google.charts.loader.VersionSpecific.load("48", { packages: $chart_types, mapsApiKey: v.map_api_key, 'language': v.language });
Previous versions are documented here:
https://developers.google.com/chart/interactive/docs/release_notes#may-2020
The top-level loader at www.gstatic.com/charts/loader.js is the same regardless which version you are loading, so there are no previous builds available for the top-level loader. The ie11 issue should be resolved now, as David Waters verified. We do try to keep the top-level loader stable and working for everyone, with high priority for fixing any problems that come up, since there are millions of requests going through it every day.
After the top-level loader is loaded, and you call google.charts.load() to load some particular version, then the corresponding version-specific loader is loaded, and it's loader is used to load the library modules. Wagner Silva is correct that you could load a specific version directly, but we don't recommend that you do this, except temporarily. The internal call of google.charts.loader.VersionSpecific.load could change in the future, and then your page will be broken by that change. The other reason to avoid loading this way is that we may need to remove previous versions, in which case the top-level loader will redirect to a newer version, but the removed version-specific loader will not be able to do that.
Hi Daniel,
Just wanted to flag that I was still having problems with the top level loader 5 hours, when I decided to hack back to the previous version.
I suspect it may not be the same issue originally raised, but nevertheless it's completely unusable on ie11 at the moment, and also crashes other JS due to the number of issues being caused.
I'm attaching some screenshots I had taken from before, hope it helps.
FYI, this was being caused on a React web app.
Thanks Wagner. I don't see anything in the screenshot you posted that is related to Google Charts, so it doesn't give me enough of a hint about what is going on. Can you point me at a website that demonstrates the problem so I can use the debugger on it (assuming I can still use IE11 somewhere)? You can email to me (dlaliberte@google) if you want to keep it private.
Hi Daniel,
We no longer have a broken production link, as I applied the hard linking to the previous version above.
I can put something on an environment for you, I'll drop you an email with details.
Hi @dlaliberte,
We are using google Charts in an application which is already in PROD. The charts do not get rendered in IE and I have tried all the solutions or workarounds I could ever find anywhere and none of them fixed it including all the work arounds here .... Please see below my code and JS error that I get in console. I would appreciate if you can help me as I have been working on it for 2 days already with no lucks.
Thanks, Taby
<script type="text/javascript" src="https://polyfill.io/v3/polyfill.min.js?version=3.52.1&features=Object.assign"></script>
<script type="text/javascript" src="https://www.gstatic.com/charts/48/loader.js"></script>
<script type="text/javascript">
//google.load("visualization", "45.2", {packages:["corechart"]});
google.charts.loader.VersionSpecific.load("48", {packages: ['corechart']});
google.setOnLoadCallback(drawChart);
function drawChart() {
var data = google.visualization.arrayToDataTable([
['Task', 'Hours per Day'],
['WAO', ${waoWALAppli}],
['Hard copy form', ${walTransactionsAppli}]
]);
var options = {
title: 'WAL Transactions Statistics',
titleTextStyle: {
fontName: "Arial",
fontSize: 16,
bold: false
},
tooltipTextStyle: {
fontName: "Arial",
fontSize: 14,
bold: false
},
slices: {
0: { color: '#cc66ff' },
1: { color: '#3366CC' }
}
};
var chart = new google.visualization.PieChart(document.getElementById('piechart'));
chart.draw(data, options);
}
</script>
@dlaliberte O BTW, I have tried many different versions with no lucks including :
Taby
Hi Taby,
First, don't load a particular loader version as you are doing. Instead, load the top-level loader (without version number) and then specify the version to load in your google.load() call.
<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js">
Sorry I cannot give the link to the project as it needs credentials to see the reports & charts. I am new to the project & it's an existing defect assigned to me.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/google-visualization-issues/issues/2841#issuecomment-742212492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELGDO7HSTR2447JMU7PE3SUA5SNANCNFSM4OVOWQYA .
-- Daniel LaLiberte https://plus.google.com/100631381223468223275?prsrc=2 dlaliberte@Google.com dlaliberte@google.com Cambridge MA
I am using IE11, but when I open JS console (as shown in above posted screen shots) there's a msg saying : "Internet Explorer is running in Enterprise Mode emulating IE8."
This is what I get when I open jsfiddle in IE :
Oh right. Well, maybe one of the other js sandboxes will work. jsbin, codepen, and several others.
Also, what do you see when you visit the Google Charts documentation pages? https://developers.google.com/chart/interactive/docs/gallery
On Wed, Dec 9, 2020 at 11:22 PM tsarhadi notifications@github.com wrote:
This is what I get when I open jsfiddle in IE :
[image: image] https://user-images.githubusercontent.com/12895043/101721145-645dc000-3afb-11eb-9c20-bd041e2dcf1e.png
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/google-visualization-issues/issues/2841#issuecomment-742229583, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELGDLGWFXN4UT3T6MV5KLSUBEHBANCNFSM4OVOWQYA .
-- Daniel LaLiberte https://plus.google.com/100631381223468223275?prsrc=2 dlaliberte@Google.com dlaliberte@google.com Cambridge MA
They show like this : (not fully rendered or they might need scroll pane?? )
and this is the PieChart that we have used :
@dlaliberte Fyi that the California smog inspection system software which is using Internet Explorer 11 in IE9 compatibility mode with Google Web Toolkit for the UI is working properly with Google Charts using the recommended way to specify loader.js without specifying a particular version. And, our periodic monitoring of the contents of loader.js do not show any recent changes to it, either. So, this is not likely to be a widespread issue like the July 9th event that started this thread. -David Waters
Thanks for the confirmation, David.
Regarding the documentation pages, if the charts show at all, that means the library is loaded and running at least. The problem with those gallery charts being cut off is due to a conflict with the documentation page layout and is otherwise independent of charts. So this proves the charts should work in general on IE.
There might be issues regarding use of some features of charts, however. Try to simplify the chart options and data as much as possible to see if you can get it working, and if so, gradually add things back in until you find a failure.
On Thu, Dec 10, 2020 at 3:19 AM David Waters notifications@github.com wrote:
@dlaliberte https://github.com/dlaliberte Fyi that the California smog inspection system software which is using Internet Explorer 11 in IE9 compatibility mode with Google Web Toolkit for the UI is working properly with Google Charts using the recommended way to specify loader.js without specifying a particular version. And, our periodic monitoring of the contents of loader.js do not show any recent changes to it, either. So, this is not likely to be a widespread issue like the July 9th event that started this thread. -David Waters
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/google-visualization-issues/issues/2841#issuecomment-742361156, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELGDLJKRI74HTOK4CPNLLSUCAA7ANCNFSM4OVOWQYA .
-- Daniel LaLiberte https://plus.google.com/100631381223468223275?prsrc=2 dlaliberte@Google.com dlaliberte@google.com Cambridge MA
This seems to have started today (9th July 2020).
90 function Ic(a,b){b=Object.assign({},b);b.domain=yc;b.callback=Z(b.callback);a=Gc(a);var c=b.language;c=Hc(Fc(c));b.language=c;if(!wc){if(b.enableUrlSettings&&window.URLSearchParams)try{a=(new URLSearchParams Object doesn't support property or method 'assign'
Reproduced using simple HTML below