HashCode H$ property should be not enumerable

105 views
Skip to first unread message

stockiNail

unread,
Jun 11, 2020, 2:08:48 PM6/11/20
to GWT Contributors
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.



Colin Alworth

unread,
Jun 11, 2020, 3:18:18 PM6/11/20
to GWT Contributors
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.

Vegegoku

unread,
Jun 12, 2020, 10:32:24 AM6/12/20
to GWT Contributors
Most of our cliensts dropped support for ancient IEs, and we now only support IE11 and edge.

stockiNail

unread,
Jun 12, 2020, 10:49:20 AM6/12/20
to GWT Contributors
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.

Colin Alworth

unread,
Jun 12, 2020, 11:48:48 AM6/12/20
to 'Goktug Gokdogan' via GWT Contributors
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

--
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-co...@googlegroups.com.

stockiNail

unread,
Jun 12, 2020, 11:53:56 AM6/12/20
to GWT Contributors
I fully agree. Based on my experience, I'd suggest, for IE, to set the minimum supported version at IE11. 
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

Thomas Broyer

unread,
Jun 12, 2020, 2:45:10 PM6/12/20
to GWT Contributors
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.

Rocco De Angelis

unread,
Jun 12, 2020, 2:45:32 PM6/12/20
to GWT Contributors
Regarding the ie support: We have really a lot of large customers (https://resources.softwareag.com/customers) in all business sectors and also a lot of customers in the financial sector which are normally very slow updating software. Last year we removed the support for ie8, ie9 and ie10 for all our up coming web based product releases. But ie11 is still present in some companies ...
The customers mentioned on the page are really a very small set of all customer that we have. So I personally think that is absolute okay removing all ie<11 browsers from the GWT support list.

Matt Davis

unread,
Jun 12, 2020, 7:24:31 PM6/12/20
to GWT Contributors
I would love to see just ie11 supported.

Slava Pankov

unread,
Jun 12, 2020, 9:08:16 PM6/12/20
to GWT Contributors
Even IE11 is not needed anymore for my projects, there is Edge for Windows 7+, so all my customers are already upgraded.

Frank Hossfeld

unread,
Jun 13, 2020, 9:32:35 AM6/13/20
to GWT Contributors
Remove support for IE8, IE9 & IE10, keep IE11 supported. Think, most of business users have updated to IE11 or Edge. 

Thomas Broyer

unread,
Jun 13, 2020, 10:16:43 AM6/13/20
to GWT Contributors
It looks like even Microsoft removed support for IE<11 in their web properties: https://support.office.com/en-us/article/which-browsers-work-with-office-for-the-web-ad1303e0-a318-47aa-b409-d3a5eb44e452

Salesforce is going to remove IE11 and non-Chromium-based MS Edge support at the end of this year for their Lightning Experience (https://help.salesforce.com/articleView?id=getstart_browsers_sfx.htm&type=5) but keep IE11 longer for Salesforce Classic (https://help.salesforce.com/articleView?id=getstart_browser_aloha.htm&type=5, which doesn't support the Chromium-based MS Edge though). Note that IE11 support in Lightning is an option since December 2017, and it isn't supported in all Salesforce features (https://help.salesforce.com/articleView?id=getstart_browser_considerations_ie.htm&type=5)

Google G Suite doesn't support IE<11: https://support.google.com/a/answer/33864?hl=en
Google Maps JavaScript API still supports IE10 but it's going to be removed really soon (if not already): https://developers.google.com/maps/documentation/javascript/browsersupport
It's not clear what versions of IE are supported for Google Maps (https://support.google.com/maps/answer/3118069?hl=en, https://support.google.com/maps/answer/3096703?hl=en, which says that Windows XP is supported but also says to update to the latest IE version; it's likely that only Firefox is supported on Windows XP)



That was off the top of my head of Enterprise products used by big companies that are likely to lag behind due to a huge number of IT assets.


Looking at other Web "development kits", Angular requires IE9+ (https://angular.io/guide/browser-support), and React too (https://reactjs.org/docs/react-dom.html#browser-support, and even requires additional polyfills for IE9 and IE10)

My opinion, if it wasn't clear in my previous message: we could drop support for IE<11.
That's going to require some work though, so let's begin with removing IE 8 support with this change to ObjectHashing, without necessarily removing the ie8 permutation for now. An alternative would be to reintroduce EmulationWithUserAgent to use Object.defineProperty wherever it's supported and keep the current behavior in the ie8 permutation.
Message has been deleted

Freddy Boucher

unread,
Jun 13, 2020, 11:30:34 PM6/13/20
to GWT Contributors
Hi,
On our side, an enterprise GWT webapp, 14% of our Users still use IE11 (we already dropped prior IE versions).
And unfortunately we still have to support IE11 for some time.
Regards

Alberto Mancini

unread,
Jun 14, 2020, 1:38:03 AM6/14/20
to google-web-tool...@googlegroups.com
Hi,
I think that keeping just IE11 is ok. 

Thanks,
   Alberto 

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8bb390c7-855e-455e-bb34-16b6d18f6452o%40googlegroups.com.

David Nouls

unread,
Jun 14, 2020, 3:44:15 AM6/14/20
to google-web-tool...@googlegroups.com
Working in the bankings sector. We support all IE versions that are still available with a (payable) supported version of Windows.

So for us it is IE11 and Edge.


Bernhard Schulz

unread,
Jun 14, 2020, 5:37:06 AM6/14/20
to GWT Contributors
Hi!

I think old browsers shouldn't be supported any more. If somebody needs them, they should use GWT 2.9.0, which is perfectly fine and works well now and in the future. 
But for future versions of GWT, drop support for old browsers so development can be focused on modern generations of browsers!

Thank you!

Evan Ruff

unread,
Jun 14, 2020, 8:14:31 AM6/14/20
to GWT Contributors
We don't have any need to support any IE at this point.

Manfred Tremmel

unread,
Jun 14, 2020, 11:18:54 AM6/14/20
to google-web-tool...@googlegroups.com
In the company I work for, IE11 is still the default browser (in a stupid IE7
compatibility mode by default, so I never have to forget X-UA-Compatible meta
tag).
AFAIK gwt uses gecko1_8 permutation for IE11 and not the ie10 permutation, so
I don't think there's some IE specific in the build. In my projects I've
stopped building browser depending permutations three years ago (must be the
end of the mainstream support of IE 9 and 10). The "safari" permutation works
for me in all cases.


Jens

unread,
Jun 15, 2020, 3:33:32 AM6/15/20
to GWT Contributors

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.

Yeah there wasn't a clear guideline I think. At least when I started gwt-dom and gwt-widgets I killed IE8-10 and used IE 11 as baseline for both. And since Edge is now based on Chrome, technically every OS that supports IE 11 also supports Edge now, so I would be fine dropping IE 11 as well in a not so distant future.

-- J.
Reply all
Reply to author
Forward
0 new messages