Some frameworks can support IE8 polyfilling the application. In my opinion the IE 8 support could be dropped.
Don't forget that the proposal (the* Object.defineProperty()*usage) is available from IE9, therefore we are not saying that we raise the GWT requirement to IE11 or Edge, but only 1 version up. Il giorno venerdì 12 giugno 2020 16:32:24 UTC+2, Vegegoku ha scritto: > > Most of our cliensts dropped support for ancient IEs, and we now only > support IE11 and edge. > > On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote: >> >> Since the existing code is very similar to J2CL's code, it seems like a >> reasonable change, provided it is indeed safe to drop support for IE8. At a >> glance, I'm having trouble finding a recent statement describing whether or >> not IE8 (and 9, 10) ought to be supported - since GWT is often used for >> large long-lived applications, it can sometimes make sense to provide >> support for browsers that might be officially unsupported, but still either >> have a wide install base or where some other "extended support" is still >> available. >> >> For example, from >> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge, >> >> it appears that while IE8 and IE10 are no longer supported, IE9 is still >> supported in some supported operating systems as the most recent browser. >> However, there is still the note "To continue receiving IE 8 updates after >> January 12, 2016, please contact your Microsoft Account Team.", suggesting >> it is still possible to get IE8 support. >> >> This is contradicted somewhat by >> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems, >> >> which says that the two OS versions (Win Server 2008 IA64 and SP2) which >> support IE9 are no longer supported, suggesting that aside from some >> specialized support contract, IE8, IE9, and IE10 should be considered dead. >> >> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote: >>> >>> Hi all, >>> >>> I was facing an annoying issue about the hashcode *$N* property, stored >>> inside the java script object. >>> >>> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects. >>> >>> I'm writing an object (JsType native) in order to configure a chart for >>> Chart.js. >>> >>> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL) >>> >>> Every property is the ID of another object. >>> >>> But unfortunately I got an error from Chart.js because it is scanning >>> all properties keys to get the objects but it does not recognize the value >>> of *$H*, being a number and not a object. >>> >>> scales: { >>> $H: 135, >>> x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, >>> …}, >>> y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} >>> } >>> >>> It's clear that a hashcode must be stored therefore there is no way to >>> remove it. >>> >>> Searching for a solution, I have found the >>> *javaemul.internal.ObjectHashing* class which is managing the H$ property, >>> I guess: >>> >>> public static native int getHashCode(Object o) /*-{ >>> return o.$H || (o.$H = @ObjectHashing::getNextHashId()()); >>> }-*/; >>> >>> I think the definition of H$ property must be changed, in order to define >>> the property "not enumerable" (currently is writable, enumerable and >>> configurable) using *Object.defineProperty()*, as it is reported >>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty. >>> >>> The *Object.defineProperty()* method is not supported into Internet >>> Explorer 8 therefore if going to manage the hascode in this way, GWT will >>> drop the support on IE8 as well. >>> >>> In the J2CL implementation, it looks like already aligned with my proposal: >>> >>> >>> /** >>> * Utility functions for setting and retrieving system level hashcodes. >>> */ >>> class Hashing { >>> /** >>> * Gets a hash code on the passed-in object. >>> * >>> * @param {*} obj >>> * @return {number} >>> * @public >>> */ >>> static $getHashCode(obj) { >>> let o = /** @type {Object} */ (obj); >>> return o.$systemHashCode || (Object.defineProperties(o, { >>> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), >>> o.$systemHashCode); >>> } >>> >>> Anyway, as workaround, I'm rewriting the hashcode property for this object, >>> maintaining the same value but setting the property as not enumerale and it >>> seems working. >>> >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/52606c59-bbda-4ea4-a7bc-c85c4c9a6777o%40googlegroups.com.
