@receptim : I’m not sure I understand your point and I would like very much to understand. You’re saying it could be network related ? in terms of permissions not given to connect ?
There’s another path we’re going to investigate. We’ve been focusing a lot on the ES2020 thing in Google’s release notes but what if it’s related to Array.from (the 3rd in the list).
Actually, what I said is a high probability assumption. The thing is that I have already seen that the device I used in my tests uses the latest webview version. I interpreted this problem as not related to the webview version, but that the google js api cannot access a data that the google js api needs to access when working with cordova and the variable that should be an array remains null or undefined. The two images I threw above actually show this. In one, I logged in from localhost:12976 and there is an error. In the other one I logged in from e.recepozen.com and there is no error and maps loaded.
Of course, I cannot say that the problem is exactly because we do not know where the js api accesses.
A workaround can be done like this. With the cordova-plugin-inappbrowser package, the page with the map is loaded from the main domain.
Unless their API runs another version of Array.from that would come from another library and that would not support iterables, well…the test seems to show the native Array.from() does support iterables.
So to come back to your point:
-In the network tab of the inspector, I do not see any problem with any network connection being blocked.
How can we find what’s blocking or missing. That’s what we’re going to be sleeping on tonight
I was able to reproduce the same behavior as you had :
1-locahost:12491: does not work.
2-https connection to the server: works
Our main hypothesis so far is that localhost works using cordova’s bundle while the network one is the “modern-browser” bundle. The first gives Meteor.isModern === false while the second one gives true.
Cordova bundle would not support loading ES2020 while modern bundle would.
I don’t know how to force the modern bundle to all Cordova’s bundle to try it.
1-We’ve overridden Object.prototype.entries which fixed this specific error message but then it failed on Object.prototype.keys . So far, we’ve stopped working on that.
2-Based on @matheusccastro 's recommendation, we’ve downloaded Maps’s JS API 3.56 as a local npm and made it ‘compile’ by Babel.
This works but it has a serious issue, it could stop working anytime because Google says it’s not supported and they don’t allow caching for more than 30 minutes. So when it stops working, we’ve got to run to build a new version. So it’s probably not ‘stable’ enough to go for prod.
So we’ve ended up opening an issue with Meteor :
which seems to be related to another one that was open in January and got no answer at all:
so unless Meteor teams “fixes” that bug in Cordova’s bundle, we find another solution, we’ll probably have to switch to Leaflet in prod until Meteor supports Google Maps under Cordova again.
Just posting here to confirm that Google Maps is not loading successfully in the legacy bundle of Meteor. Our solution is not to load Google Maps when Meteor.isModern is false and show a message instead. This works for us (on web) as legacy is a small percentage of our users and the use of the maps is not central to the app.
I can see how this is a big issue with cordova given that it loads the legacy bundle. I am not sure if anybody is still around to know why this is the case.
The best route here is to fork Meteor, force modern bundle to cordova and test. That can help give more data for consideration to the Meteor team (who are focused in delivering 3.0)
I haven’t develop for cordova for quite a while now but checking the supported android devices, seems like the reason of supporting very old android devices is now moot with the restrictions set for the android api level. I am not sure how it looks like at iOS.
But that might be enough to start supporting the modern bundle for cordova (or at the very least, make it a config).
Thanks a lot for your interest and help! We’ve just tested that and what it does is only set the variable Meteor.isModern = true in the client. So it says it’s “modern” but the bundle is still based on legacy.
We’re still searching in the code where the build of the bundle is done.
We’re not sure it’s going to be easy as all packages in /Users/fafafa/.meteor/packages do have different sources for :
web.cordova
web.browser
web.browser-legacy
web.cordova-legacy (yeah, that exists!)
which probably means the required change to build a modern-like bundle for cordova is deeper/wider than just changing one value somewhere.
we’ll get back as soon as we find something useful!
Confirm the disabling overrides in ecma_runtime_client makes maps work. Thank you @burni13 for sharing it.
I did face some compilation challenge, but eventually got it sorted.
Can you show me the directory containing the data of ecmascript-runtime-client? is it in C:\Users\Admin\AppData\Local\.meteor\packages\ecmascript-runtime-client ?
