The inlined script is running, but it's failing because it needs its own source attribute, which is removed during inlining.
I just noticed you're using a different linker than me, so that may be why the baseUrl property isn't working. If your linker doesn't have a way to override the base url for the scripts, you'll have to modify the nocache script in some way or switch linkers. Maybe you could write a simple script that loads the nocache script?
You could also contact Sprint and have them whitelist your site.
On Jul 29, 2013, at 2:51 PM, Paul Mazzuca wrote:
I actually haven't used the web inspector. This is a huge help. So by using the web inspector, it turns out that my nocache.js is completely inlined into the html head section when using 3G via Virgin Mobile USA (Sprint), while when connecting via wifi, the nocache.js is downloaded separate, though referenced in the html head section -- and it does not work on 3G. The question is why doesn't the inline js run, or if it is running, where is it failing?… inlined js on 3G connection<script type="text/javascript" language="javascript" style="display:none"><!--function myprojname(){…;//--></script>Just a few observations for others:- The inline javascript is surrounded by html comment tags, which I believe enables old browser compatibility- The HTML is rendered (which makes sense since I can use the Web Inspector)- I still do see the reference to the cache.js script which is not inline.Also, I am still playing with the gwt:property workaround that you mentioned. no luck with it yet.On Jul 29, 2013, at 11:56 AM, David Feshbach <djfeshbach@gmail.com> wrote:Have you tried using the web inspector? It's really useful for debugging web apps on iOS devices. There's also a way to do it with android/Chrome using adb but I don't know it off the top of my head.Things I noticed when debugging our app that indicated the network: it worked over https but not http, the host page received was different from what the server sent. You may also be able to replicate the problem in a desktop browser by enabling tethering on your phone.That tag looks right. I think if it's wrong it would stop working over wifi too. It's used for the script element that gets added to the DOM so it should be easy to check.On Jul 28, 2013, at 10:51 AM, Paul Mazzuca wrote:Well, the test iPhone is using Virgin Mobile USA which I believe piggybacks on Sprint's network so that would make sense. The onModuleLoad method is not even being called, so I suspect the js files are no where to be found. Just to confirm, I edited my html file to include the meta tag <meta name="gwt:property" content="baseUrl=myprojectname"> given that my project js file is typically located at<script type="text/javascript" language="javascript" src="myprojectname/myprojectname.nocache.js">?
On Friday, July 26, 2013 2:14:04 PM UTC-7, David wrote:We had an issue with Sprint "optimizing" the page by inlining scripts. As a result, there was no source attribute for the nocache script which prevented it from loading the other scripts (which are on a different server from the host page). We got around this by adding a "gwt:property" meta element that set the "baseUrl" property.On Jul 26, 2013, at 1:53 PM, Paul Mazzuca wrote:I have an IPhone 4 which I am testing my GWT app on. In Chrome or Mobile Safari, my application will only load when connected to WIFI. This behavior seems to be consistent, but I wanted to get a sanity check from the community to see if anyone else has experienced this? I am using code splitting and the xsiframe linker. My initial download size is around 100k, even with code splitting... ya I know still pretty hefty.My thoughts are that the cause may be related to the initial download size being too large, something weird with the xsilinker, or just something bogus that only happens with 3G. Of note, this does not seem to occur with 4G connections.Any thoughts?--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com .
To post to this group, send email to google-we...@googlegroups.com .
Visit this group at http://groups.google.com/group/google-web-toolkit .
For more options, visit https://groups.google.com/groups/opt_out .
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/RU2WC0R9I3g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment