Closed rmichaelis closed 6 years ago
Hi @rmichaelis, the closure compiler should handle the transpilation. Are you experimenting a specific issue in production mode?
For debug mode you are right, it is not supported, one should rely on sourcemaps.
Hi @gberaudo, Yes it happens in our production environment.
If you try to print the following map : http://g-o.lu/3/NL4I you get the following error :
TypeError: Cet objet ne gère pas cette action
at yB (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2131:22)
at xB (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2124:100)
at Anonymous function (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2123:245)
at wB (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2123:216)
at vB.prototype.rh (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2122:467)
at Anonymous function (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2148:493)
at Anonymous function (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:181:450)
at m.prototype.$digest (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:192:417)
at m.prototype.$apply (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:196:111)
at l (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:148:95) Possibly unhandled rejection: {"description":"Cet objet ne gère pas cette action","number":-2146827843,"stack":"TypeError: Cet objet ne gère pas cette action\n at yB (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2131:22)\n at xB (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2124:100)\n at Anonymous function (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2123:245)\n at wB (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2123:216)\n at vB.prototype.rh (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2122:467)\n at Anonymous function (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:2148:493)\n at Anonymous function (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:181:450)\n at m.prototype.$digest (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:192:417)\n at m.prototype.$apply (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:196:111)\n at l (http://map.geoportail.lu/main/wsgi/proj/728c826edeb44bdeb1054284e4e45399/build/build.js:148:95)"}
As the debug mode does not work with IE, it's difficult to pinpoint the error : But that seems to come from here :
@rmichaelis, it looks like the URL constructor is not available in IE11 and the compiler did not polyfilled it.
I guess the reason is that URL
is not actually an official standard. See https://developer.mozilla.org/en-US/docs/Web/API/URL/URL where it is only a "living standard" .
I think we should stop using this URL constructor in ngeo.
In the meantime you might want to use a polyfill like https://www.npmjs.com/package/url-polyfill (untested).
Ok. Thanks, I'll have a try.
Since URL is used, we cannot use anymore url relative protocol for printing our WMS.
This is invalid : new URL ('//www.camptocamp.org/')
@rmichaelis, out of curiosity, is there a reason to load resources using //
instead of https://
?
For two reasons: 1) An historical reason : Before having https available for our webservices, we configured each entry with relative protocol. Thus we didn't have to check each configuration, when we switched to https. 2) Not really sure, but I think we maybe also have such configuration for external resources, that are up to now still not availlable in https (but scheduled to be available in https). These resources are only available in our http geoportal. To bypass this, we are using a kind of proxy.
@rmichaelis, see https://github.com/camptocamp/ngeo/pull/3123.
We have the same error in aeroportdelyon_sig and it is reproductable in demo 2.2 : https://geomapfish-demo.camptocamp.net/2.2 :
var d=new URL(d);
gives :
TypeError: Object doesn't support this action
at MA (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:2114:124)
at Anonymous function (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:2113:243)
at LA (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:2113:214)
at KA.prototype.Hh (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:2112:918)
at VA.prototype.print (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:2141:277)
at fn (Function code:2:173)
at e (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:292:410)
at m.prototype.$eval (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:155:503)
at m.prototype.$apply (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:156:208)
at Anonymous function (https://geomapfish-demo.camptocamp.net/2.2/wsgi/static-ngeo/605ccbf7d9244594b15bcf941e2be7ae/build/desktop.js:292:460)
fixed with #3182 (2.2)
In our projects we have to support IE11 and higher. But ngeo uses unsupported javascripts : here : https://github.com/camptocamp/ngeo/blob/master/src/services/print.js#L283
Is ngeo supposed to still support Internet Explorer ?