Fwiw: IE11 will be EOL for mainstream in October this year: https://www.swyx.io/writing/ie11-eol/ (of course, for enterprise customers this will be longer; my opinion is that those companies that have enough money to pay for special Microsoft support contract could also pay a company to fork and maintain GWT for those usecases; or they can just stay on an old version of GWT like they're staying on an old version of IE; those companies are not my customers though so my opinion probably doesn't weight much)
Also, jQuery dropped support for IE8 while back and is now IE9+ https://jquery.com/browser-support/. That supports the option for GWT to do the same, at a minimum. Finally, several "modularized gwt-user" modules already dropped support for IE8 and IE9 AFAICT, possibly even IE10. On Friday, June 12, 2020 at 5:53:56 PM UTC+2, stockiNail wrote: > > I fully agree. Based on my experience, I'd suggest, for IE, to set the > minimum supported version at IE11. > > Il giorno venerdì 12 giugno 2020 17:48:48 UTC+2, Colin Alworth ha scritto: >> >> Agreed that this fix only requires dropping IE8, but I'm suggesting that >> we go a bit further and either a) also drop other dead browsers, or b) have >> a plan/timeline for when we can drop those browsers - at least officially. >> We might still leave in support for them (as we did for IE6 for some >> years), but require that projects go out of their way to enable that >> support. >> >> -- >> Colin Alworth >> co...@colinalworth.com >> >> >> >> On Fri, Jun 12, 2020, at 9:49 AM, stockiNail wrote: >> >> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> 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 >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/52606c59-bbda-4ea4-a7bc-c85c4c9a6777o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d45dcf84-1a67-4fe8-bdc1-157387cc81fao%40googlegroups.com.
