I've just filed https://github.com/gwtproject/gwt/issues/9739, where a
workaround exists in java.util.Date that nearly doubles the time it takes
to parse date strings and build date objects. This workaround exists for
IE8 and IE9, as all more recent browsers implement the same behavior as we
I vote to even drop support for IE11.
On Thursday, September 30, 2021 at 7:49:56 PM UTC+3 nilo...@gmail.com wrote:
> I've just filed https://github.com/gwtproject/gwt/issues/9739, where a
> workaround exists in java.util.Date that nearly doubles the time it takes
> to parse date strings and
Note that it appears I'm mistaken, Runtime.java polyfilled Date.now()
(though code in JsDate and others still believed that this method might not
exist), so GWT 2.8.2 and 2.9.0 likely function properly in IE8.
On Thursday, September 30, 2021 at 11:49:56 AM UTC-5 Colin Alworth wrote:
> I've
+1 drop IE 11 increases the effort to include new stuff. IE +11 can still
use GWT 2.9.0
On Thu, 30 Sept 2021 at 16:55, Vegegoku wrote:
> I vote to even drop support for IE11.
>
> On Thursday, September 30, 2021 at 7:49:56 PM UTC+3 nilo...@gmail.com
> wrote:
>
>> I've just filed
We've got a few changes that have been brewing or waiting to be made
available, and it sounds like it is about time to collectively push to make
these things happen. Given the nature of some of these, I am suggesting
that they not be folded into a bugfix release, but instead that the next
+1 drop all i.e.
On Thu, Sep 30, 2021, 4:13 PM Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:
> +1 drop IE 11 increases the effort to include new stuff. IE +11 can still
> use GWT 2.9.0
>
> On Thu, 30 Sept 2021 at 16:55, Vegegoku wrote:
>
>> I vote to even drop support for IE11.
>>
+1 for dropping support for ie8-10.
We still need to support IE11 in our app right now. But not for much longer. We
are currently still compiling with 2.8.2 due to compilation issues with the 2.9
release (issues with generics) so dropping IE11 is not a big issue as well.
On 30 Sep 2021, 18:49
