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
>>   [email protected]
>>
>>
>>
>> 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 [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
>>  
>> <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 [email protected].
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.

Reply via email to