"Unload event listeners are deprecated" browser error
Hello.
Browsers running our GWT application (version 2.11) have recently (this
week) started reporting errors like this one:
[{"age":41550,"body":{"columnNumber":192,"id":"UnloadHandler
","lineNumber":3210,"message":"Unload event listeners are deprecated and
will be removed.","sourceFile":"ourmodule-0.js"},"type":"deprecation","
url":"oururl","user_agent":"Mozilla/5.0 (Linux; Android 10; K)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Mobile
Safari/537.36"}]
Any idea about why is this happening? Is GWT using a deprecated browser
feature?
Thanks!
Oscar
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit/12f7d833-f7ef-44aa-a58b-01806f4c1b88n%40googlegroups.com.
Re: SerializationException when application is modified
Hi.
Thanks a lot for you all your replies. We have just noticed that the
behavior of the RPC calls is different depending on whether the beans
travelling through the wire implement Serializable or IsSerializable.
When they implement IsSerializable the onFailure(Throwable) method of the
AsyncCallback contains a IncompatibleRemoteServiceException. According to
its Javadoc "The correct response to receiving an instance of this
exception in the AsyncCallback.onFailure(Throwable) method is to get the
application into a state where a browser refresh can be done."
On the other side, when they implement the generic Serializable method, the
exception is the more generic StatusCodeException with a message "500 The
call failed on the server; see server log for details". This is too
generic, it could be caused by any problems on the server, not just code
changes requiring a reload.
So it looks like its better to implement IsSerializable rather than
Serializable.
What do you think? Am I missing something?
On Wed, Jul 19, 2017 at 12:22 PM, Thomas Broyer wrote:
>
>
> On Tuesday, July 18, 2017 at 6:15:23 PM UTC+2, Óscar Frías Barranco wrote:
>>
>> Hi.
>>
>> When we modify the code of our GWT application, in particular the classes
>> that travel through GWT calls, these exceptions are generated for many
>> users for a few hours:
>>
>> com.google.gwt.user.client.rpc.SerializationException: Type '.' was
>> not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and
>> did not have a custom field serializer.For security purposes, this type
>> will not be serialized.: instance = .
>>
>> We think that this is due to browsers caching the previous (old) code
>> which is no longer aligned with the server code. We have reviewed all HTTP
>> headers related to caching and all of the are, we think, correctly
>> configured.
>>
>> So our plan is to force a reload of the browser page with a
>> location.reload(true) when we detect that the SerializationException is
>> being thrown at the server.
>>
>
> From a UX point of view, it's probably better to show an error (possibly
> with a button to reload the app) than forcibly reload, as that could
> possibly lead to losing data the user has entered.
> This is what Google Groups is doing, and it allows users to copy their
> message before reloading, pasting and re-sending it.
>
>
>> Any ideas about how to implement this easily? Our code if full of
>> AsyncCallback calls and we would like to avoid editing each one of them.
>> Is there a place where we could insert a client code that would be executed
>> for every RPC call and that will call location.reload(true) if a
>> SerializationException is thrown ?
>>
>
> If your GWT.create() for the services are relatively centralized, you
> could implement wrappers that wrap the AsyncCallback before delegating to
> the real service.
>
> I.e. from
>
> FooServiceAsync fooService = GWT.create(FooService.class);
>
> to
>
> FooServiceAsync fooService = new FooServiceAsyncWrapper();
>
> with
>
> class FooServiceAsyncWrapper implements FooServiceAsync {
> private final FooServiceAsync delegate = GWT.create(FooService.class);
>
> @Override
> public void doFoo(int param1, String param2, AsyncCallback
> callback) {
> delegate.doFoo(param1, param2, new AsyncCallbackWrapper(
> callback));
> }
> }
>
> class AsyncCallbackWrapper implements AsyncCallback {
> private final AsyncCallback delegate;
>
> public AsyncCallbackWrapper(AsyncCallback delegate) {
> this.delegate = delegate;
> }
>
> @Override
> public void onSuccess(T result) {
> delegate.onSuccess(result);
> }
>
> @Override
> public void onFailure(Throwable caught) {
> if (caught instanceof Xxx) {
> // handle failure
> } else {
> delegate.onFailure(caught);
> }
> }
> }
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/google-web-toolkit/Kt9DygTyQ-U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Re: SerializationException when application is modified
We are following the recommendations on http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#perfect_caching But I am afraid that whatever the headers some browsers will cache some files anyway so we really need a way to force a reload of the web application when RPC calls return an exception. Any ideas on how to implement this? On Tue, Jul 18, 2017 at 7:34 PM, Michael Joyner wrote: > We use https://github.com/realityforge/gwt-cache-filter to help deal with > caching issues. > > On 07/18/2017 12:15 PM, Óscar Frías Barranco wrote: > > Hi. > > When we modify the code of our GWT application, in particular the classes > that travel through GWT calls, these exceptions are generated for many > users for a few hours: > > com.google.gwt.user.client.rpc.SerializationException: Type '.' was > not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did > not have a custom field serializer.For security purposes, this type will > not be serialized.: instance = . > > We think that this is due to browsers caching the previous (old) code > which is no longer aligned with the server code. We have reviewed all HTTP > headers related to caching and all of the are, we think, correctly > configured. > > So our plan is to force a reload of the browser page with a > location.reload(true) when we detect that the SerializationException is > being thrown at the server. Any ideas about how to implement this easily? > Our code if full of AsyncCallback calls and we would like to avoid editing > each one of them. Is there a place where we could insert a client code > that would be executed for every RPC call and that will call > location.reload(true) if a SerializationException is thrown ? > > Thanks! > > -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at https://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "GWT Users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/google-web-toolkit/Kt9DygTyQ-U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at https://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
SerializationException when application is modified
Hi. When we modify the code of our GWT application, in particular the classes that travel through GWT calls, these exceptions are generated for many users for a few hours: com.google.gwt.user.client.rpc.SerializationException: Type '.' was not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.For security purposes, this type will not be serialized.: instance = . We think that this is due to browsers caching the previous (old) code which is no longer aligned with the server code. We have reviewed all HTTP headers related to caching and all of the are, we think, correctly configured. So our plan is to force a reload of the browser page with a location.reload(true) when we detect that the SerializationException is being thrown at the server. Any ideas about how to implement this easily? Our code if full of AsyncCallback calls and we would like to avoid editing each one of them. Is there a place where we could insert a client code that would be executed for every RPC call and that will call location.reload(true) if a SerializationException is thrown ? Thanks! -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT 2.8 generates code 14% bigger than GWT 2.7
> Do you have a step by step guide to run the closure compiler externally ? >> > > Basically you would need to replicate what has been done programmatically > in the removed ClosureJsRunner class. See commit > > https://github.com/gwtproject/gwt/commit/162ccc9c9112a09bf9e > a046da95760f5f1886b72 > > Looks like you have to > - define your own gwt_externs file to tell Closure Compiler which special > GWT variables not to rename > - maybe create a hack.js file that exports gwtOnLoad function so it does > not get removed by Closure Compiler. Maybe its not needed if also passing > in the .nocache.js file to Closure compiler. no idea. > - Give Closure Compiler the GWT output (your *.cache.js files including > split points) in the correct ordering as split point files have > dependencies (initial fragment, leftover, split points) > Thanks for your help, but unfortunately this does not look like a simple process to implement for GWT users like us. For the moment we will remain in GWT 2.7 which generates a smaller code for our website, and hoping that future GWT versions will be able to reduce or at least maintain the same code size as version 2.7 -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT 2.8 generates code 14% bigger than GWT 2.7
> > And why don't keep it experimental too in 2.8 instead of removing it? >> > > Why keeping it if it's only half baked into GWT and you can run it > externally as well? > Do you have a step by step guide to run the closure compiler externally ? -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT 2.8 generates code 14% bigger than GWT 2.7
> Do you plan to bring Closure Compiler (-XenableClosureCompiler option) >> back to GWT? It was very useful for us. >> > > No. It was experimental and had some rough edges that haven't been fully > implemented. > And why don't keep it experimental too in 2.8 instead of removing it? -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GWT 2.8 generates code 14% bigger than GWT 2.7
Hi. We are trying to move our website from GWT 2.7 to 2.8 but we have found that GWT 2.8 generates code which is significantly heavier. For example, these are the sizes for one of the permutations: GWT 2.7 + Closure Compiler: 590 KB GWT 2.7 without Closure Compiler: 664 KB GWT 2.8 (no Closure Compiler available): 674 KB So the difference between 2.7 and 2.8 is +14% code size. We would like to keep our site up to date with the last version of GWT but we don't like increasing our website code in this manner because it means higher downloads, higher waiting times, worse user experience, etc. Do you plan to bring Closure Compiler (-XenableClosureCompiler option) back to GWT? It was very useful for us. Kind regards, Oscar -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT app crashing on iOS 6
We haven't done anything else for the moment. We hope iOS 6.1 or the next version of GWT fixes it. By the way, probably related bug: http://code.google.com/p/google-web-toolkit/issues/detail?id=7831 Maybe if you (and more people) star it the GWT team will prioritize it (and will either fix it or chase Apple team to fix it). Óscar On Wednesday, January 16, 2013 1:42:30 PM UTC+1, mkn wrote: > > So how do you handle the situation? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/s_145d-u-l4J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT app crashing on iOS 6
No. It still persists. Are you facing a similar problem ? Oscar El lunes, 14 de enero de 2013 20:54:41 UTC+1, mkn escribió: > > Hi > > Could you solve your problem in the meantime? > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Wo5dI1R6ANwJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: es_AR locale is not using es_419 properties
OK, thanks, I have reported the issue here: http://code.google.com/p/google-web-toolkit/issues/detail?id=7808 El domingo, 25 de noviembre de 2012 03:26:22 UTC+1, Thomas Broyer escribió: > > > On Monday, November 19, 2012 7:45:16 PM UTC+1, Óscar Frías Barranco wrote: >> >> Hello. >> >> We are trying to implement Runtime Locales as explained in: >> >> >> https://developers.google.com/web-toolkit/doc/latest/DevGuideI18nLocale#RuntimeLocales >> >> We are using a gwt.xml like this one: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> >> >> But the problem is that when we in runtime select locale=es_AR, the >> localized strings that are displayed are those from Messages_es.properties >> instead of those from Messages_es_419.properties as we would expect. >> >> Why is this happening? In theory es_AR locale should "extend" es_419 >> locale (Latin American Spanish), so the compiler should look for the >> substitution strings following this priority: >> 1) Messages_es_AR.properties >> 2) Messages_es_419.properties >> 3) Messages_es.properties >> 4) Messages.properties >> >> But apparently the step 2 is not performed. Do you know how to fix this? >> >> When we use locale=es_419 the strings are OK but this not a solution >> because we also need currency information which is in the es_AR locale and >> not in the es_419 locale. >> > > The "region inheritance" (where AR is a child of 005 which is in turn a > child of 419) is only used for CLDR data (date/time and number formatting), > not for resolving messages. The documentation is wrong here, in that it > doesn't match what the code does. I can't comment on what it should/could > do here as I don't know much about I18N. I'd suggest you file an issue so > that someone could either fix the code or the documentation. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AjytFQrAmOoJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
es_AR locale is not using es_419 properties
Hello. We are trying to implement Runtime Locales as explained in: https://developers.google.com/web-toolkit/doc/latest/DevGuideI18nLocale#RuntimeLocales We are using a gwt.xml like this one: > But the problem is that when we in runtime select locale=es_AR, the localized strings that are displayed are those from Messages_es.properties instead of those from Messages_es_419.properties as we would expect. Why is this happening? In theory es_AR locale should "extend" es_419 locale (Latin American Spanish), so the compiler should look for the substitution strings following this priority: 1) Messages_es_AR.properties 2) Messages_es_419.properties 3) Messages_es.properties 4) Messages.properties But apparently the step 2 is not performed. Do you know how to fix this? When we use locale=es_419 the strings are OK but this not a solution because we also need currency information which is in the es_AR locale and not in the es_419 locale. Thanks! Oscar -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/4RwXi_1euWEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT app crashing on iOS 6
Hi.
Unfortunately I don't have a Mac. But I compiled in PRETTY mode without
ClosureCompiler and I have isolated one of the points where iOS 6 crashes.
In this case there is no exception thrown. Javascript just halts.
In the following code, the first alert ('before PriceEvol') is displayed,
but not the second one. The original Java code for this fragment is:
Window.alert("before PriceEvol");
sidePriceEvolutionBox = RootPanel.get("PriceEvolutionLink");
Window.alert("after PriceEvol");
And the compiled code is:
alert_0('before PriceEvol');
sidePriceEvolutionBox = get_1('PriceEvolutionLink');
alert_0('after PriceEvol');
With the function defined as:
function get_1(id){
$clinit_RootPanel();
var elem, rp;
rp = dynamicCast(rootPanels.get(id), Q$RootPanel);
elem = null;
if (id != null) {
if (!(elem = $getElementById($doc, id))) {
return null;
}
}
if (rp) {
if (!elem || rp.element == elem) {
return rp;
}
}
if (rootPanels.size_1() == 0) {
addCloseHandler(new RootPanel$2_0);
($clinit_LocaleInfo() , false) && setDirectionOnElement($doc,
($clinit_HasDirection$Direction() , RTL));
}
!elem?(rp = new RootPanel$DefaultRootPanel_0):(rp = new
RootPanel_0(elem));
rootPanels.put(id, rp);
$add_15(widgetsToDetach, rp);
return rp;
}
Óscar
On Wed, Nov 7, 2012 at 5:24 PM, Jens wrote:
> Can you:
>
> 1.) compile your app in PRETTY mode so you can read JS source code easily
> 2.) enable iOS inspector and use Safari 6 on Mac OS to connect to your
> iphone/ipad for remote debugging (
> http://moduscreate.com/enable-remote-web-inspector-in-ios-6/)
> 3.) In Safari 6 web inspector go to "breakpoints" and activate "all
> exceptions" or "uncaught exceptions" and then check the call stack once the
> exception occurs.
>
> Maybe that gives you some hints which generated JS code exactly causes the
> unexpected exception.
>
>
> -- J.
>
>
>
> Am Mittwoch, 7. November 2012 17:01:46 UTC+1 schrieb Óscar Frías Barranco:
>
>> Yes, the error that we are gettting is a ClassCastException.
>>
>> Oscar
>>
>>
>> El miércoles, 7 de noviembre de 2012 14:39:15 UTC+1, Daniel Kurka
>> escribió:
>>>
>>> Do you have a uncaught exception handler in place so that we could maybe
>>> get at least a JavaScript error?
>>>
>>> -Daniel
>>>
>>>
>>> On Wednesday, November 7, 2012 11:54:57 AM UTC+1, Óscar Frías Barranco
>>> wrote:
>>>>
>>>> Just let me clarify that the ClosureCompiler does not fix the issue, it
>>>> just makes it less frequent.
>>>>
>>>> The issue is so weird that you can load a GWT page without any error
>>>> and then just reload the same page to find that now GWT javascript
>>>> crashes. And then reload again and its OK. It's completely random.
>>>>
>>>>
>>>> El martes, 6 de noviembre de 2012 19:51:51 UTC+1, Óscar Frías Barranco
>>>> escribió:
>>>>>
>>>>> Hi again.
>>>>>
>>>>> We have found that compiling with -XenableClosureCompiler hides the
>>>>> problem or at least mitigates it.
>>>>>
>>>>> I have no idea about what Closure Compiler does to GWT generated
>>>>> javascript but apparently it is hiding iOS6 browser issues.
>>>>>
>>>>> Oscar
>>>>>
>>>>>
>>>>> El martes, 6 de noviembre de 2012 11:15:10 UTC+1, Óscar Frías Barranco
>>>>> escribió:
>>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> Our GWT application crashes when running on an iPad with iOS 6.0.1.
>>>>>>
>>>>>> This is not related to the POST caching issue because we already
>>>>>> added Cache-Control and Expires headers to GWT RPC replies and now they
>>>>>> are
>>>>>> not cached.
>>>>>>
>>>>>> We have "debugged" the app by adding Window.alert() calls and we have
>>>>>> found that it crashes (randomly, not always) in places like:
>>>>>>
>>>>>> HashSet.add() method
>>>>>> RootPanel.add() method (which includes a HashSet.add() call)
>>>>>> ConstantsWithLookup.getString(**)
>>>>>>
>>>>>>
>>>>>> It looks like iOS 6 Javascript engine has some issues, so maybe GWT
>>>>>> is being bitten by these errors too:
>>>&g
Re: GWT app crashing on iOS 6
Yes, the error that we are gettting is a ClassCastException. Oscar El miércoles, 7 de noviembre de 2012 14:39:15 UTC+1, Daniel Kurka escribió: > > Do you have a uncaught exception handler in place so that we could maybe > get at least a JavaScript error? > > -Daniel > > > On Wednesday, November 7, 2012 11:54:57 AM UTC+1, Óscar Frías Barranco > wrote: >> >> Just let me clarify that the ClosureCompiler does not fix the issue, it >> just makes it less frequent. >> >> The issue is so weird that you can load a GWT page without any error and >> then just reload the same page to find that now GWT javascript crashes. >> And then reload again and its OK. It's completely random. >> >> >> El martes, 6 de noviembre de 2012 19:51:51 UTC+1, Óscar Frías Barranco >> escribió: >>> >>> Hi again. >>> >>> We have found that compiling with -XenableClosureCompiler hides the >>> problem or at least mitigates it. >>> >>> I have no idea about what Closure Compiler does to GWT generated >>> javascript but apparently it is hiding iOS6 browser issues. >>> >>> Oscar >>> >>> >>> El martes, 6 de noviembre de 2012 11:15:10 UTC+1, Óscar Frías Barranco >>> escribió: >>>> >>>> Hello. >>>> >>>> Our GWT application crashes when running on an iPad with iOS 6.0.1. >>>> >>>> This is not related to the POST caching issue because we already added >>>> Cache-Control and Expires headers to GWT RPC replies and now they are not >>>> cached. >>>> >>>> We have "debugged" the app by adding Window.alert() calls and we have >>>> found that it crashes (randomly, not always) in places like: >>>> >>>> HashSet.add() method >>>> RootPanel.add() method (which includes a HashSet.add() call) >>>> ConstantsWithLookup.getString() >>>> >>>> >>>> It looks like iOS 6 Javascript engine has some issues, so maybe GWT is >>>> being bitten by these errors too: >>>> >>>> >>>> http://stackoverflow.com/questions/12534409/ios-6-javascipt-intermittent-issues-with-object-defineproperty >>>> >>>> >>>> Any ideas? >>>> >>>> Thanks, >>>> Oscar >>>> >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/PYxHaKSTp98J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT app crashing on iOS 6
Just let me clarify that the ClosureCompiler does not fix the issue, it just makes it less frequent. The issue is so weird that you can load a GWT page without any error and then just reload the same page to find that now GWT javascript crashes. And then reload again and its OK. It's completely random. El martes, 6 de noviembre de 2012 19:51:51 UTC+1, Óscar Frías Barranco escribió: > > Hi again. > > We have found that compiling with -XenableClosureCompiler hides the > problem or at least mitigates it. > > I have no idea about what Closure Compiler does to GWT generated > javascript but apparently it is hiding iOS6 browser issues. > > Oscar > > > El martes, 6 de noviembre de 2012 11:15:10 UTC+1, Óscar Frías Barranco > escribió: >> >> Hello. >> >> Our GWT application crashes when running on an iPad with iOS 6.0.1. >> >> This is not related to the POST caching issue because we already added >> Cache-Control and Expires headers to GWT RPC replies and now they are not >> cached. >> >> We have "debugged" the app by adding Window.alert() calls and we have >> found that it crashes (randomly, not always) in places like: >> >> HashSet.add() method >> RootPanel.add() method (which includes a HashSet.add() call) >> ConstantsWithLookup.getString() >> >> >> It looks like iOS 6 Javascript engine has some issues, so maybe GWT is >> being bitten by these errors too: >> >> >> http://stackoverflow.com/questions/12534409/ios-6-javascipt-intermittent-issues-with-object-defineproperty >> >> >> Any ideas? >> >> Thanks, >> Oscar >> >> >> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/rBbwWMr2GEMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT app crashing on iOS 6
Hi again. We have found that compiling with -XenableClosureCompiler hides the problem or at least mitigates it. I have no idea about what Closure Compiler does to GWT generated javascript but apparently it is hiding iOS6 browser issues. Oscar El martes, 6 de noviembre de 2012 11:15:10 UTC+1, Óscar Frías Barranco escribió: > > Hello. > > Our GWT application crashes when running on an iPad with iOS 6.0.1. > > This is not related to the POST caching issue because we already added > Cache-Control and Expires headers to GWT RPC replies and now they are not > cached. > > We have "debugged" the app by adding Window.alert() calls and we have > found that it crashes (randomly, not always) in places like: > > HashSet.add() method > RootPanel.add() method (which includes a HashSet.add() call) > ConstantsWithLookup.getString() > > > It looks like iOS 6 Javascript engine has some issues, so maybe GWT is > being bitten by these errors too: > > > http://stackoverflow.com/questions/12534409/ios-6-javascipt-intermittent-issues-with-object-defineproperty > > > Any ideas? > > Thanks, > Oscar > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/TJmqenJ1bKMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: iOS 6 Bug: Safari caches POST requests
Hello.
We just override the method onAfterResponseSerialized from
RemoteServiceServlet in the RPC services implementation and this fixes this
issue:
@Override
protected void onAfterResponseSerialized(String serializedResponse) {
HttpServletResponse response = getThreadLocalResponse();
response.setDateHeader("Expires", 0L); // always expired
response.setHeader("Cache-Control", "no-cache");
}
Regards,
Oscar
El domingo, 23 de septiembre de 2012 10:10:35 UTC+2, Rui Oliveira escribió:
>
> Hi,
>
> Whats the best away to solve this issue? I have hundreds of RPC and I'm
> looking for a global way to change the header to no-cache.
>
> Sincerely
>
> Rui
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/fpOWNVQ0q3YJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
GWT app crashing on iOS 6
Hello. Our GWT application crashes when running on an iPad with iOS 6.0.1. This is not related to the POST caching issue because we already added Cache-Control and Expires headers to GWT RPC replies and now they are not cached. We have "debugged" the app by adding Window.alert() calls and we have found that it crashes (randomly, not always) in places like: HashSet.add() method RootPanel.add() method (which includes a HashSet.add() call) ConstantsWithLookup.getString() It looks like iOS 6 Javascript engine has some issues, so maybe GWT is being bitten by these errors too: http://stackoverflow.com/questions/12534409/ios-6-javascipt-intermittent-issues-with-object-defineproperty Any ideas? Thanks, Oscar -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/XudQPnVNZhgJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Best (faster) place to include gwt script in html ?
But this document suggests putting scripts at the bottom of the HTML
to improve page download speed:
http://developer.yahoo.com/performance/rules.html#js_bottom
Is this true also for GWT script ?
Thanks,
Oscar
On Apr 13, 3:34 pm, redlaber wrote:
> It makes no difference. The html-code generate the page almost
> instantly. GWT metod RootPanel.get("id") also work very quickly.
> Almost all time of page generation will take the loading of gwt-
> module. So place your gwt-application where it is more convenient to
> you.
>
> On 13 апр, 13:51, Óscar Frías wrote:
>
> > Which is the best place to put the gwt script in the HTML page from a
> > performance point of view (page speed) ?
> > I mean to minimize the load time of a page that contains some HTML
> > code in addition to the GWT module.
>
> > Is it better to put it at the end of the head section (immediately
> > before the tag, or immediately before the analytics code) ?
> > Or would it be faster to put it at the end of the html (immediately
> > before the tag) ?
>
> > Thanks!
> > Oscar
--
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Best (faster) place to include gwt script in html ?
Which is the best place to put the gwt script in the HTML page from a performance point of view (page speed) ? I mean to minimize the load time of a page that contains some HTML code in addition to the GWT module. Is it better to put it at the end of the head section (immediately before the tag, or immediately before the analytics code) ? Or would it be faster to put it at the end of the html (immediately before the tag) ? Thanks! Oscar -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: DOM.getAbsoluteLeft() returns a wrong value in IE6 and GWT 1.6.4
Update: I found that adding a DOCTYPE to the HTML page fixes the problem. I used this one: Anyway, this confirms that there is a bug in 1.6.4 because I was successfully using 1.5.3 without any DOCTYPE (for IE8 compatibility). On Apr 16, 7:00 pm, Óscar Frías wrote: > I am migrating a GWT application from GWT 1.5 to GWT 1.6.4 > The application uses the SliderBar widget (with some changes). > > SliderBar calls DOM.getAbsoluteLeft() to obtain the position of the > knob. > The problem is that this code was working OK in all the browsers when > we were using GWT 1.5.3. > Now, after migrating to 1.6.4, is does not work on IE6. The rest of > the browsers are OK. > > I have found that in IE6 the call to DOM.getAbsoluteLeft() returns > 2147483647 instead of the right value. > > Just in case this is relevant, the element has the style "position: > absolute" and its parent has "position: relative". > > Could you please help me with this problem ? --~--~-~--~~~---~--~~ 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-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
DOM.getAbsoluteLeft() returns a wrong value in IE6 and GWT 1.6.4
I am migrating a GWT application from GWT 1.5 to GWT 1.6.4 The application uses the SliderBar widget (with some changes). SliderBar calls DOM.getAbsoluteLeft() to obtain the position of the knob. The problem is that this code was working OK in all the browsers when we were using GWT 1.5.3. Now, after migrating to 1.6.4, is does not work on IE6. The rest of the browsers are OK. I have found that in IE6 the call to DOM.getAbsoluteLeft() returns 2147483647 instead of the right value. Just in case this is relevant, the element has the style "position: absolute" and its parent has "position: relative". Could you please help me with this problem ? --~--~-~--~~~---~--~~ 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-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: IllegalStateException (onDetach) in Internet Explorer 6 and 7
We have found a fix to this problem.
We were doing an RPC call before building all the UI. And just moving
the RPC call to the end of the initialization routine has fixed the
problem.
Anyway, could there be a bug in the GWT code? I am asking because it
is not clear to me if calling a RPC method before constructing some
widgets should leave them in an illegal state.
On Dec 24 2008, 4:58 pm, Óscar Frías wrote:
> Hello.
>
> We have detected that our web application throws this Exception
> sometimes:
>
> java.lang.IllegalStateException: Should only call onDetach when the
> widget is attached to the browser's document
>
> We detect these exceptions because we have implemented a custom
> exception handler that reports exceptions from the browser to our
> server (code at the end).
> The problem is that although this happens quite frequently (we see
> this in our logs), we do not know how to reproduce it. According to
> the logs timing it seems to happen (at least some of the times) when
> leaving the page that contains the GWT app. But we are not completely
> sure about this.
>
> Any idea about what could be happening, about the possible root cause,
> or how to try to debug/fix it, etc. ?
> Any help is appreciated.
>
> More information:
> - Exception is only thrown from IE6 and IE7 browsers
> - This did not happen with GWT version 1.4.62. It started happening
> the same day we migrated to 1.5.3
> - The widget that throws the exception is an HTMLPanel. Its parent is
> a Composite.
>
> In case you are interested, this is the site with the error (the GWT
> app is the flight results page):http://www.trabber.com
>
> /* Code to report exceptions to the server */
> if (GWT.isScript()) {
> GWT.setUncaughtExceptionHandler(new
> GWT.UncaughtExceptionHandler() {
> public void onUncaughtException(Throwable th) {
> CommonService.App.getInstance().reportException
> (th, myCallback);
> }
> });
> }
--~--~-~--~~~---~--~~
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-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
IllegalStateException (onDetach) in Internet Explorer 6 and 7
Hello.
We have detected that our web application throws this Exception
sometimes:
java.lang.IllegalStateException: Should only call onDetach when the
widget is attached to the browser's document
We detect these exceptions because we have implemented a custom
exception handler that reports exceptions from the browser to our
server (code at the end).
The problem is that although this happens quite frequently (we see
this in our logs), we do not know how to reproduce it. According to
the logs timing it seems to happen (at least some of the times) when
leaving the page that contains the GWT app. But we are not completely
sure about this.
Any idea about what could be happening, about the possible root cause,
or how to try to debug/fix it, etc. ?
Any help is appreciated.
More information:
- Exception is only thrown from IE6 and IE7 browsers
- This did not happen with GWT version 1.4.62. It started happening
the same day we migrated to 1.5.3
- The widget that throws the exception is an HTMLPanel. Its parent is
a Composite.
In case you are interested, this is the site with the error (the GWT
app is the flight results page):
http://www.trabber.com
/* Code to report exceptions to the server */
if (GWT.isScript()) {
GWT.setUncaughtExceptionHandler(new
GWT.UncaughtExceptionHandler() {
public void onUncaughtException(Throwable th) {
CommonService.App.getInstance().reportException
(th, myCallback);
}
});
}
--~--~-~--~~~---~--~~
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-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
