Re: Blank page in Safari, flaky in Firefox, works fine in IE
Yes, thanks for the pointer. Changed to PRETTY, and it works fine now :) Only Firefox still flaky... will continue hunting ... On Aug 13, 5:21 pm, Thomas Broyer wrote: > On 13 août, 19:05, andrew_lau wrote: > > > > > I have a GWT application, that uses GWT Maps API, and it works fine in > > IE. > > > In Firefox, it is flaky, sometimes it loads, sometimes it does not. > > If I take out the portion of GWT Maps that pulls the API from Google > > site, it loaded fine 100% each time. > > > It is not loading at all in Safari, just blank page. Even after I > > took out the GWT Maps portion like the Firefox. I even disable all > > the Ajax call in OnModuleLoad() method, still nothing. Not even a > > simple RootPanel.get().setWidget() is able to set the widget on the > > page. > > > It works fine in IE6 and IE7. > > > Anyone has a clue? > > As for the app not working at all in Safari, it could be issue 3455, > which applies to Safari > 4.http://code.google.com/p/google-web-toolkit/issues/detail?id=3455 > > If I were you I'd ask on the "Google API Libraries for GWT" group and/ > or "Google Maps API" group for your issue with Firefox. --~--~-~--~~~---~--~~ 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: Blank page in Safari, flaky in Firefox, works fine in IE
Oh, by the way, I am still using GWT 1.53. I have not got a chance to upgrade to 1.7. On Aug 13, 11:05 am, andrew_lau wrote: > I have a GWT application, that uses GWT Maps API, and it works fine in > IE. > > In Firefox, it is flaky, sometimes it loads, sometimes it does not. > If I take out the portion of GWT Maps that pulls the API from Google > site, it loaded fine 100% each time. > > It is not loading at all in Safari, just blank page. Even after I > took out the GWT Maps portion like the Firefox. I even disable all > the Ajax call in OnModuleLoad() method, still nothing. Not even a > simple RootPanel.get().setWidget() is able to set the widget on the > page. > > It works fine in IE6 and IE7. > > Anyone has a clue? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Blank page in Safari, flaky in Firefox, works fine in IE
I have a GWT application, that uses GWT Maps API, and it works fine in IE. In Firefox, it is flaky, sometimes it loads, sometimes it does not. If I take out the portion of GWT Maps that pulls the API from Google site, it loaded fine 100% each time. It is not loading at all in Safari, just blank page. Even after I took out the GWT Maps portion like the Firefox. I even disable all the Ajax call in OnModuleLoad() method, still nothing. Not even a simple RootPanel.get().setWidget() is able to set the widget on the page. It works fine in IE6 and IE7. Anyone has a clue? --~--~-~--~~~---~--~~ 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: same-origin security restriction
I got this worked out using apache's reverse proxy module. Workstation --> apache proxy ---> (rpc call?) (192.168.2.2) |-- yes --> ejb server |-- no --> workstation port Basically, you just need to set up mod_proxy like this: === httpd.conf == ProxyRequests Off Order deny,allow Deny from all allow from 192.168 ProxyPass /mywebmodule/gwt-rpc-service http://ejbserver.com/mywebmodule/gwt-rpc-service ProxyPassReverse /mywebmodule/gwt-rpc-service http://ejbserver.com/mywebmodule/gwt-rpc-service ProxyPass /com.mygwtapp.UIModule http://192.168.2.2:/com.mygwtapp.UIModule ProxyPassReverse /com.mygwtapp.UIModule http://192.168.2.2:/com.mygwtapp.UIModule Please note that 192.168.2.2 is my workstation where I develop the code. Thus, when I start hosted mode in that box, the tomcat instance will listen to port of my workstation. Thus, this proxy server will contact the tomcat in my workstation for any queries that has /com.mygwtapp.UIModule in its path, and will contact my real EJB server, when the hosted mode browser does rpc call. This way, it is "clean", the proxy server separate the calls for you. Here is my hosted mode batch file: @java -Xmx512M -cp "%~dp0\src;%~dp0\bin;C:/javadev/lib/gwt-windows/gwt-user.jar;N:/ javadev/lib/gwt-maps.jar;C:/javadev/lib/gwt-windows/gwt-dev- windows.jar" com.google.gwt.dev.GWTShell -out "%~dp0\www" %* http://theproxyserver/com.mygwtapp.UIModule/UIModule.html -whitelist "^http[:][/][/]theproxyserver" On Nov 25, 4:12 pm, Brian wrote: > Created issue 3131: (and 13's my lucky number... so close sorta..) > > http://code.google.com/p/google-web-toolkit/issues/detail?id=3131 > > Please star it :-) > > On Nov 24, 11:13 am, Brian wrote: > > > How did I miss this thread? Is there an issue open already for this, > > as per the Nov 21st post? I'll star it. > > > I'm still using 1.5.2 for dev, as it's the fastest way to iterate on a > > non-jsonp app. Basically you guys spoiled me with this bug/feature in > > prior releases and using 1.5.3 and its slowdown to iterations just > > sucks. No offense :) > > > Anyway, no, it doesn't cause more problems when deploying. You find > > out right away when you're running in webmode if you're violating SOP > > as the browser complains or ignores the request (depends on the > > browser). Violating SOP in hosted mode was a fantastic feature. > > Having a console warning in hosted mode that a request is violating > > sop should be enough. > > > On Nov 24, 11:02 am, Jason Essington > > wrote: > > > > Actually, allowing Hosted mode to violate SOP would lead to even more > > > problems come deployment time... > > > > The idea with hosted mode is that it mirrors an actual browser as > > > nearly as possible, so by breaking (not fixing) the SOP behavior, > > > developers are likely to run into issues where something works in > > > Hosted mode, but doesn't in Web mode. Definitely not desired behavior. > > > > If you have a situation were you need to connect to a serve that is > > > not well represented by the embedded tomcat server, then simply use - > > > noserver and be done with it. > > > > I have a JEE backend, and even I have to use -noserver. In fact, I > > > would be willing to bet anyone that has an application that has > > > progressed beyond trivial (trial) client/server communication is using > > > Hosted mode with the -noserver switch. It is not a matter of the GWT > > > developers trying to screw non-JEE developers, but rather a matter of > > > not being able to provide an embedded server that is all things to all > > > people. > > > > -jason > > > > On Nov 21, 2008, at 2:23 PM, jpnet wrote: > > > > > This is not a feature! Please fix this. Allow us developers to > > > > violate the SOP via the Hosted-Mode browsers. You are screwing your > > > > developers that don't use J2EE on the backend. > > > > > -JP > > > > > On Nov 19, 7:33 pm, Sumit Chandel wrote: > > > >> Hi Danny, > > > > >> The issue you ran into is not actually a bug but an improvement in > > > >> 1.5.3 in > > > >> terms of browser security compliance. > > > > >> Basically, the remote data you are fetching is indeed violating the > > > >> single > > > >> origin policy, which is why you are seeing the error message come > > > >> up in the > > > >> hosted mode console. > > > > >> The two ways to enable cross-site communication would be to use - > > > >> noserver > > > >> with a proxy that could delegate the calls or using the JSONP > > > >> technique. > > > >> Both are described in a bit more detail on the Groups post linked > > > >> below: > > > > >>http://groups.google.com/group/Google-Web-Toolkit/browse_thread/ > > > >> threa... > > > > >> Hope that helps, > > > >> -Sumit Chandel > > > > >> On Thu, Nov 13, 2008 at 5:05 PM, Danny wrote: > > > > >>> Just thought I'd post an update... > > > > >>> I downgraded from 1.
Re: Announcing GWT 1.5.3
I got this worked out using apache's reverse proxy module.
Workstation --> apache proxy ---> (rpc call?)
(192.168.2.2) |-- yes --> ejb server
|-- no --> workstation port
Basically, you just need to set up mod_proxy like this:
===
httpd.conf
==
ProxyRequests Off
Order deny,allow
Deny from all
allow from 192.168
ProxyPass /mywebmodule/gwt-rpc-service
http://ejbserver.com/mywebmodule/gwt-rpc-service
ProxyPassReverse /mywebmodule/gwt-rpc-service
http://ejbserver.com/mywebmodule/gwt-rpc-service
ProxyPass /com.mygwtapp.UIModule http://192.168.2.2:/com.mygwtapp.UIModule
ProxyPassReverse /com.mygwtapp.UIModule
http://192.168.2.2:/com.mygwtapp.UIModule
Please note that 192.168.2.2 is my workstation where I develop the
code. Thus, when I
start hosted mode in that box, the tomcat instance will listen to port
of my
workstation. Thus, this proxy server will contact the tomcat in my
workstation for
any queries that has /com.mygwtapp.UIModule in its path, and will
contact my real EJB
server, when the hosted mode browser does rpc call.
This way, it is "clean", the proxy server separate the calls for you.
Here is my hosted mode batch file:
@java -Xmx512M -cp
"%~dp0\src;%~dp0\bin;C:/javadev/lib/gwt-windows/gwt-user.jar;N:/
javadev/lib/gwt-maps.jar;C:/javadev/lib/gwt-windows/gwt-dev-
windows.jar"
com.google.gwt.dev.GWTShell -out "%~dp0\www" %*
http://theproxyserver/com.mygwtapp.UIModule/UIModule.html -whitelist
"^http[:][/][/]theproxyserver"
On Dec 12, 5:36 pm, Brad LaRonde wrote:
> r3731 (merge of r3728) is the culprit:
>
> --- user/src/com/google/gwt/user/client/impl/HTTPRequestImplIE6.java
> +++ user/src/com/google/gwt/user/client/impl/HTTPRequestImplIE6.java
> @@ -24,6 +24,14 @@
>
> �...@override
> protected native JavaScriptObject doCreateXmlHTTPRequest() /*-{
> - return new ActiveXObject("Microsoft.XMLHTTP");
> + if ($wnd.XMLHttpRequest) {
> + return new XMLHttpRequest();
> + } else {
> + try {
> + return new ActiveXObject('MSXML2.XMLHTTP.3.0');
> + } catch (e) {
> + return new ActiveXObject("Microsoft.XMLHTTP");
> + }
> + }
> }-*/;
> }
>
> Revert and rebuild gwt-user.jar. Would be cool if there was a way to
> do it only for hosted mode.
>
> On Oct 20, 9:15 am, Brian wrote:
>
> > I'm seeing a same-origin security restriction exception in 1.5.3 where
> > I didn't see it in 1.5.2. That is, I can switch my project back and
> > forth between using 1.5.2 (no exception) and 1.5.3 (exception), with
> > the same source code.
>
> > I'm doing a RequestBuilder to "locahost:8080/url" in order to hit my
> > server to POST some data.
>
> > Means I'll be using 1.5.2 until I can figure out how to hit my local
> > server from 1.5.3.
>
> > Brian
>
> > On Oct 20, 11:17 am, "nicolas.deloof"
> > wrote:
>
> > > Hi,
>
> > > for maven users, this release will be available via maven central
> > > repository in few hours (after rsync does its job).
>
> > > Nicolas
>
> > > On 18 oct, 00:22, Ray Ryan wrote:
>
> > > > Hi, all.
>
> > > > We have just deprecated GWT 1.5.2, and replaced it with GWT 1.5.3.
> > > > This new release has a small handful of patches, mainly aimed at
> > > > fixing RPC problems with Android. You can download the update from the
> > > > usual location:
>
> > > > http://code.google.com/webtoolkit/download.html
>
> > > > You may find that this pretty page hasn't updated yet in your neck of
> > > > the woods. If so, try going straight to the download
> > > > server:http://code.google.com/p/google-web-toolkit/downloads/list.
>
> > > > Enjoy,
> > > > rjrjr
>
> > > > Release Notes for 1.5.3
>
> > > > Fixed Issues
>
> > > > - RPC requests no longer fail on the embedded Android web browser
>
> > > > - Leaf TreeItems now line up with their non-leaf siblings
>
> > > > - Removing the last child node from a TreeItem no longer creates
> > > > extra margins on the left
>
> > > > - HTTPRequest no longer uses POST instead of GET on some IE installs
> > > > because of incorrect XHR selection
>
> > > > - Compiler now uses a more reliable check to prevent methods with
> > > > local variables from being inlined
> > > > getAbsoluteTop()/Left() can no longer return non-integral values
>
> > > > - Time.valueOf() no longer fails to parse "08:00:00" or incorrectly
> > > > accepts "0xC:0xB:0xA".- Hide quoted text -
>
> > - Show quoted text -
--~--~-~--~~~---~--~~
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: same-origin security restriction
I got this worked out using apache's reverse proxy module. Workstation --> apache proxy ---> (rpc call?) (192.168.2.2) |-- yes --> ejb server |-- no --> workstation port Basically, you just need to set up mod_proxy like this: === httpd.conf == ProxyRequests Off Order deny,allow Deny from all allow from 192.168 ProxyPass /mywebmodule/gwt-rpc-service http://ejbserver.com/mywebmodule/gwt-rpc-service ProxyPassReverse /mywebmodule/gwt-rpc-service http://ejbserver.com/mywebmodule/gwt-rpc-service ProxyPass /com.mygwtapp.UIModule http://192.168.2.2:/com.mygwtapp.UIModule ProxyPassReverse /com.mygwtapp.UIModule http://192.168.2.2:/com.mygwtapp.UIModule Please note that 192.168.2.2 is my workstation where I develop the code. Thus, when I start hosted mode in that box, the tomcat instance will listen to port of my workstation. Thus, this proxy server will contact the tomcat in my workstation for any queries that has / com.mygwtapp.UIModule in its path, and will contact my real EJB server, when the hosted mode browser does rpc call. This way, it is "clean", the proxy server separate the calls for you. Here is my hosted mode batch file: @java -Xmx512M -cp "%~dp0\src;%~dp0\bin;C:/javadev/lib/gwt-windows/gwt- user.jar;N:/javadev/lib/gwt-maps.jar;C:/javadev/lib/gwt-windows/gwt- dev-windows.jar" com.google.gwt.dev.GWTShell -out "%~dp0\www" %* http://theproxyserver/com.mygwtapp.UIModule/UIModule.html -whitelist "^http[:][/][/]theproxyserver" On Nov 25, 4:12 pm, Brian wrote: > Created issue 3131: (and 13's my lucky number... so close sorta..) > > http://code.google.com/p/google-web-toolkit/issues/detail?id=3131 > > Please star it :-) > > On Nov 24, 11:13 am, Brian wrote: > > > How did I miss this thread? Is there an issue open already for this, > > as per the Nov 21st post? I'll star it. > > > I'm still using 1.5.2 for dev, as it's the fastest way to iterate on a > > non-jsonp app. Basically you guys spoiled me with this bug/feature in > > prior releases and using 1.5.3 and its slowdown to iterations just > > sucks. No offense :) > > > Anyway, no, it doesn't cause more problems when deploying. You find > > out right away when you're running in webmode if you're violating SOP > > as the browser complains or ignores the request (depends on the > > browser). Violating SOP in hosted mode was a fantastic feature. > > Having a console warning in hosted mode that a request is violating > > sop should be enough. > > > On Nov 24, 11:02 am, Jason Essington > > wrote: > > > > Actually, allowing Hosted mode to violate SOP would lead to even more > > > problems come deployment time... > > > > The idea with hosted mode is that it mirrors an actual browser as > > > nearly as possible, so by breaking (not fixing) the SOP behavior, > > > developers are likely to run into issues where something works in > > > Hosted mode, but doesn't in Web mode. Definitely not desired behavior. > > > > If you have a situation were you need to connect to a serve that is > > > not well represented by the embedded tomcat server, then simply use - > > > noserver and be done with it. > > > > I have a JEE backend, and even I have to use -noserver. In fact, I > > > would be willing to bet anyone that has an application that has > > > progressed beyond trivial (trial) client/server communication is using > > > Hosted mode with the -noserver switch. It is not a matter of the GWT > > > developers trying to screw non-JEE developers, but rather a matter of > > > not being able to provide an embedded server that is all things to all > > > people. > > > > -jason > > > > On Nov 21, 2008, at 2:23 PM, jpnet wrote: > > > > > This is not a feature! Please fix this. Allow us developers to > > > > violate the SOP via the Hosted-Mode browsers. You are screwing your > > > > developers that don't use J2EE on the backend. > > > > > -JP > > > > > On Nov 19, 7:33 pm, Sumit Chandel wrote: > > > >> Hi Danny, > > > > >> The issue you ran into is not actually a bug but an improvement in > > > >> 1.5.3 in > > > >> terms of browser security compliance. > > > > >> Basically, the remote data you are fetching is indeed violating the > > > >> single > > > >> origin policy, which is why you are seeing the error message come > > > >> up in the > > > >> hosted mode console. > > > > >> The two ways to enable cross-site communication would be to use - > > > >> noserver > > > >> with a proxy that could delegate the calls or using the JSONP > > > >> technique. > > > >> Both are described in a bit more detail on the Groups post linked > > > >> below: > > > > >>http://groups.google.com/group/Google-Web-Toolkit/browse_thread/ > > > >> threa... > > > > >> Hope that helps, > > > >> -Sumit Chandel > > > > >> On Thu, Nov 13, 2008 at 5:05 PM, Danny wrote: > > > > >>> Just thought I'd post an update... > > > > >>> I downgraded from
