Chrome 24 and GWT

1,588 views
Skip to first unread message

Paul

unread,
Jan 10, 2013, 6:08:25 PM1/10/13
to google-we...@googlegroups.com
This morning Google updated Chrome to version 24.  Now all my GWT (animated) dialogs "flash" when opened.  They continuously open/close and give a flashing effect.  I can't access the buttons to close them and have to kill the browser window to stop it.  Confirmed on linux mint (13) and Windoze 7 versions of Chrome.  I had another linux box that I did not allow to update, and confirmed that Chrome 23 (and previous) does not do this.  I've seen one other person complain of this on the Chrome forum.  Just thought everyone should know!

Paul

Daniel Kurka

unread,
Jan 10, 2013, 6:50:59 PM1/10/13
to google-we...@googlegroups.com
The gwt showcase seems to be fine or does this appear for you as well? -> http://gwt.googleusercontent.com/samples/Showcase/Showcase.html#!CwDialogBox

JSNI NOOB

unread,
Jan 11, 2013, 5:06:19 AM1/11/13
to google-we...@googlegroups.com
it seems that is a GWT 2.4 with chrome 24 problem with an issue dontFix i think they corrected in GWT 2.5.

Thomas Broyer

unread,
Jan 11, 2013, 5:53:51 AM1/11/13
to google-we...@googlegroups.com
See https://code.google.com/p/google-web-toolkit/source/detail?r=10989 (the review has links to issues)
Fixed in GWT 2.5.


On Friday, January 11, 2013 12:08:25 AM UTC+1, Paul wrote:

Arturs Elksnis

unread,
Jan 11, 2013, 7:19:40 AM1/11/13
to google-we...@googlegroups.com
I had the same problem. You probably have line like this in your dialog box:

setAnimationEnabled(true);

Remove it and at least your dialogs will be usable but animation unfortunately will be gone.

Paul

unread,
Jan 11, 2013, 10:52:54 AM1/11/13
to google-we...@googlegroups.com

Seems this is, as pointed out, a GWT 2.4 and previous bug, fixed in 2.5

It will break a lot of "old" GWT code, but at least I can just re-compile and re-distribute mine.

cheers,

Andy

unread,
Jan 11, 2013, 1:20:20 PM1/11/13
to google-we...@googlegroups.com
I posted the workaround that we're using to the chromium issue thread: http://code.google.com/p/chromium/issues/detail?id=158910

We have 100s of customers with servers deployed behind firewalls so this is going to be ugly.

Craig Mitchell

unread,
Jan 13, 2013, 5:12:20 PM1/13/13
to google-we...@googlegroups.com
Thanks Andy!  Your workaround works great!

+1 for not happy with Google!  GWT 2.4 is supposed to be the stable build!  We've been deferring going to GWT 2.5 because we wanted the stability.

Summary for workaround is to add the following to your .gwt.xml file:

<!-- TEMP FIX UNTIL GOING TO GWT 2.5 -->
<!-- Fallback implementation, based on a timer -->
<replace-with class="com.google.gwt.animation.client.AnimationSchedulerImplTimer">
  <when-type-is class="com.google.gwt.animation.client.AnimationScheduler"/>
  <any>
    <when-property-is name="user.agent" value="ie6"/>
    <when-property-is name="user.agent" value="ie8"/>
    <when-property-is name="user.agent" value="ie9"/>
    <when-property-is name="user.agent" value="safari"/>
    <when-property-is name="user.agent" value="opera"/>
  </any>
</replace-with>

<!-- Implementation based on mozRequestAnimationFrame -->
<replace-with class="com.google.gwt.animation.client.AnimationSchedulerImplMozilla">
  <when-type-is class="com.google.gwt.animation.client.AnimationScheduler"/>
  <when-property-is name="user.agent" value="gecko1_8"/>
</replace-with>
<!-- ************* END ************* -->

John V Denley

unread,
Jan 14, 2013, 8:53:52 AM1/14/13
to google-we...@googlegroups.com
Yup, same problem for me at www.DiaryBooker.com/demo - click any appointment location to create a new appointment and you see it right there! 

This has actually happened before and a few updates later it had gone away again!

I'm not sure what version of GWT is currently live, but my current development version is not showing this issue, trouble is I am halfway through a massive update, so cant make any changes to the current live version and Im getting complaints from my customers.... I have had to tell them to use Internet Explorer while we wait for Google to fix it!!

John V Denley

unread,
Jan 14, 2013, 8:55:55 AM1/14/13
to google-we...@googlegroups.com
Any idea how I can fix this/workaround this in a currently live product, that I am unable to recompile/redeploy? Can I set something in chrome to stop it happening or revert back to an older version?

Samyem Tuladhar

unread,
Jan 14, 2013, 9:02:25 AM1/14/13
to google-we...@googlegroups.com
Switch to Firefox!

Thomas Broyer

unread,
Jan 14, 2013, 11:26:19 AM1/14/13
to google-we...@googlegroups.com


On Monday, January 14, 2013 2:53:52 PM UTC+1, John V Denley wrote:
Yup, same problem for me at www.DiaryBooker.com/demo - click any appointment location to create a new appointment and you see it right there! 

This has actually happened before and a few updates later it had gone away again!

I'm not sure what version of GWT is currently live, but my current development version is not showing this issue, trouble is I am halfway through a massive update, so cant make any changes to the current live version

You mean that cannot even create a branch in your SCM from the commit you last deployed, apply the workaround and re-deploy? And you didn't plan for that eventuality?
 
and Im getting complaints from my customers.... I have had to tell them to use Internet Explorer while we wait for Google to fix it!!

You mean "while they wait for you to update", right?

I don't get why people get angry here: there was a bug in GWT, it was fixed 8 months ago in trunk and was released nearly 3 months ago (before users on the stable channel of Chrome could even notice). There's an easy workaround too for people not ready to update to GWT 2.5.
So what's the problem actually? You didn't test your apps with beta or dev versions of your browsers (that gives you 6 to 12 weeks to fix issues before your users can notice), you're 3 months late on updating to the latest stable release of GWT and you cannot deploy an updated version (recompiled with the workaround) quickly. You can blame GWT for using a "beta", though rather stable, API (requestAnimationFrame) to smooth the rendering of your app and having made assumptions on the value it received as argument and the exact time it'll be called back, but GWT is not the only one to blame by an order of magnitude.
The Web is a moving target: browsers update and can break your code as soon as you (or the lib you use) a) make assumptions on browsers behaviors, b) use "beta" APIs or c) use hacks or workarounds. When working with web technologies (whether it's GWT, jQuery or vanilla JS), it's very important to regularly a) test in beta or dev versions of your browsers, b) update to the latest release of the libs you use and c) be prepared to re-deploy quickly.

zarfh...@gmail.com

unread,
Jan 14, 2013, 11:43:36 AM1/14/13
to google-we...@googlegroups.com
Some of us are stuck on GWT 2.4 since the 2.5 release notes make a point of saying that they no longer support Chrome Frame for IE. Since we support hospitals and large mining corporations that still run IE6, if they don't use Chrome Frame, it's practically unusable. (Yes, I know there's half a dozen forum posts saying "oh actually 2.5 still supports it", but as long as the release notes say it "officially", management won't allow us to upgrade.)

I think the bigger point people here are making is that Google Chrome made a radically change that made the Google Web Toolkit to break. No backwards compatibility whatsoever. Even when Microsoft's Internet Explorer browser changed their rendering engines, etc, they still included the 'Compatibility Mode' so that older webpages could be rendered correctly. 

On Monday, January 14, 2013 9:26:19 AM UTC-7, Thomas Broyer wrote:

You mean "while they wait for you to update", right?

I don't get why people get angry here: there was a bug in GWT, it was fixed 8 months ago in trunk and was released nearly 3 months ago (before users on the stable channel of Chrome could even notice). There's an easy workaround too for people not ready to update to GWT 2.5. 
So what's the problem actually? You didn't test your apps with beta or dev versions of your browsers (that gives you 6 to 12 weeks to fix issues before your users can notice), you're 3 months late on updating to the latest stable release of GWT and you cannot deploy an updated version (recompiled with the workaround) quickly. You can blame GWT for using a "beta", though rather stable, API (requestAnimationFrame) to smooth the rendering of your app and having made assumptions on the value it received as argument and the exact time it'll be called back, but GWT is not the only one to blame by an order of magnitude.


Perhaps you have the resources to fully regression test all of your applications every week on all 8 or 9 different supported browsers, plus dev/beta versions, but in the real world of enterprise software, that's simply not feasible. Stable software should remain stable. If a customer upgrades his version of Windows, I shouldn't expect the new version to suddenly start working strangely because of a radical change in how animations are rendered. A similar concept should apply for web browsers.

Thomas Broyer

unread,
Jan 14, 2013, 12:11:04 PM1/14/13
to google-we...@googlegroups.com


On Monday, January 14, 2013 5:43:36 PM UTC+1, zarfh...@gmail.com wrote:
Some of us are stuck on GWT 2.4 since the 2.5 release notes make a point of saying that they no longer support Chrome Frame for IE.

And it's plain wrong. Unfortunately, it seems to fall through the cracks every time we mention it back.
Actually GWT 2.5 *fixes* things re. Chrome Frame: https://code.google.com/p/google-web-toolkit/issues/detail?id=6665
 
Since we support hospitals and large mining corporations that still run IE6, if they don't use Chrome Frame, it's practically unusable. (Yes, I know there's half a dozen forum posts saying "oh actually 2.5 still supports it", but as long as the release notes say it "officially", management won't allow us to upgrade.)

If you need an official statement: https://groups.google.com/d/topic/google-web-toolkit-contributors/wzilCaLySCU/discussion "rdayal" and "unnurg" are former GWT team members at Google.
I'll ping the GWT team to get it fixed "for real" asap.

BTW, you can maybe tell your management that ChromeFrame has never been "officially" supported by GWT either?

Finally, I'd have preferred that you kept bugging us (or Google actually, since only Google can update the GWT web site) about updating the release notes rather than come complaining about this Chrome/GWT non-issue.
 
I think the bigger point people here are making is that Google Chrome made a radically change that made the Google Web Toolkit to break.

It broke the broken GWT 2.4. 

Thomas Broyer

unread,
Jan 14, 2013, 1:52:29 PM1/14/13
to google-we...@googlegroups.com
Release notes updated to remove the bogus bullet point. You can now proceed to update to 2.5.

Craig Mitchell

unread,
Jan 14, 2013, 3:19:05 PM1/14/13
to google-we...@googlegroups.com
Re:  +1 for not happy with Google!  GWT 2.4 is supposed to be the stable build!  We've been deferring going to GWT 2.5 because we wanted the stability.

Apologise to Google for this comment.  I thought GWT 2.5 was still a "release candidate".  I normally get a notification in Eclipse telling me that a new version of GWT is available, for whatever reason, it didn't happen for this release.

We will update to GWT 2.5 ASAP!  And apologies again for not realising GWT 2.5 had been released.

Cheers.

John V Denley

unread,
Jan 14, 2013, 3:34:57 PM1/14/13
to google-we...@googlegroups.com
Yes Thomas, you are quite correct on two very good points, firstly that my customers are technically waiting for ME to upgrade to 2.5 and secondly that I SHOULD have been using an SCM and/or should have been taking regular backups... thats TOTALLY on me..

I have grown organically and was not even aware of how to use an SCM when I started development back in 2009, its been a learning experience the whole way through, and the reason I chose GWT as a development platform was so that I would not have to worry about testing against all the possible browser options. (Yes it quickly became obvious that Google do not take ALL the cross browser pain away!)

I actually dropped my pc (attached to my backup device, while backing up and managed to destroy both beyond recovery - I spend over £500 trying to recover the data) 

I am working through the process of rebuilding the product since my last cloud backup in April 2012, but that was built in GWT2.4. So yes, I cant branch my SCM (didnt have one) and I didnt plan for that eventuality. I am NOW using GIT and BitBucket and SugarSync, DropBox and Google Drive to back EVERYTHING up constantly!

I relied too heavily on Google taking care of all browser compatibility and I didn't fully comprehend the dangers of not being absolutely meticulous... totally my fault on those two issues, but still its annoying that an automatic update to Chrome has broken my application. Sure, I should be able to  fix and be agile and maneuver  but currently I'm not, so I am stuck in the short them having to ask my customers to go use firefox or safari or god forbid even IE (v8 at least!!)

John V Denley

unread,
Jan 14, 2013, 3:36:41 PM1/14/13
to google-we...@googlegroups.com
Yes I have had to send an email to all my customers telling them to temporarily switch to firefox, safari or IEv8+

Thomas Broyer

unread,
Jan 14, 2013, 8:22:38 PM1/14/13
to google-we...@googlegroups.com
Sorry, didn't see that part of your mail:


On Monday, January 14, 2013 5:43:36 PM UTC+1, zarfh...@gmail.com wrote:

Perhaps you have the resources to fully regression test all of your applications every week on all 8 or 9 different supported browsers, plus dev/beta versions, but in the real world of enterprise software, that's simply not feasible.

I don't have those resources, but I'm aware that it's what I should do.
It's actually even worse: I'm paid to build webapps, not maintaining them. We're not proactive on browser changes because that's not part of the deal with our customers, but we're generally in the situation of shipping a fixed version (provided there's an easy fix or workaround) in a matter of hours. Once the warranty period is over however, I bet nobody does testing either and fixes can take ages.
BTW, I also know there *are* people in the "real world of enterprise software" who *do* end-to-end testing, either using Selenium/WebDriver on a cluster of servers, or using SaaS such as Sauce Labs, driven by a CI server (Jenkins/Hudson, TeamCity, Bamboo, etc.) to be run on each commit and/or nightly.

The root of the issue is that most people (IT deps mostly) ask for webapps rather than native apps (generally to replace native apps) for bad reasons and/or without understanding the consequences.
 
Stable software should remain stable. If a customer upgrades his version of Windows, I shouldn't expect the new version to suddenly start working strangely because of a radical change in how animations are rendered. A similar concept should apply for web browsers.

ROTFL!
Are you talking about that Windows OS that breaks its WebDAV support in almost every new version or service pack, and even sometimes hotfixes? http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html (I had to do an emergency patch in a server after the SP1 was deployed on Win7 this fall; BTW the webapp is 4 years old 'cause nobody allocated the budget to maintain and update it, not even with security fixes: “if it ain't broke, don't fix it”, BS; this is the state of software in the "real world of enterprise software": zombie servers on a drip of emergency fixes to keep them alive)
The one OS for which every IT department delays hotfix/SP deployment by fear of breaking their payroll or LoB apps? (which is probably the main reason there's still so many IE7 and IE8 out there –last year I would even have added IE6 to the list–).

But again, we're talking here about a bug in GWT, in the use of a "beta" API. And that bug was fixed long before the change in Chrome reached end users.
Also note that in a closed environment (intranet) running Windows, you can disable Chrome and/or ChromeFrame auto-updates using a group policy.

darkflame

unread,
Jan 20, 2013, 5:04:32 PM1/20/13
to Google Web Toolkit
Just to confirm/clarify this problem as I found it today.


PopupPanel test = new PopupPanel();

test.add(new Label("test"));

test.setAnimationEnabled(true);

test.center();

Is all it takes to reproduce it for me.
Animation seems to have to be true, it seems to work fine without, so
that could be a workaround for some people needing 2.4.
> almost every new version or service pack, and even sometimes hotfixes?http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html(I had to

John V Denley

unread,
Jan 24, 2013, 7:45:46 PM1/24/13
to google-we...@googlegroups.com
Looks to me like the latest release (Version 24.0.1312.56 m) fixes this issue...

Alex-Dan Luca

unread,
Jan 25, 2013, 2:36:54 PM1/25/13
to google-we...@googlegroups.com

Google fixed it and pushed an update to all Chrome users.

See here for more info:

http://code.google.com/p/chromium/issues/detail?id=158910

On Jan 25, 2013 8:51 PM, "Simon K" <feene...@gmail.com> wrote:
I can't reproduce it on Chrome 24.0.1312.56 m either.

Is there a particular commit in this patch that might fixed the animation problem inadvertently? How likely is it for the issue to come back in the near future?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply all
Reply to author
Forward
0 new messages