A few days ago Google Chrome on my Android phone suggested to enable Data Saver to improve web browsing performances.
This feature is also available as an extension on Google Chrome for desktop.
Since then, all Xojo WebApps weren’t running correctly on my Android device and it took some time to discover what was happening.
Basically the application just wouldn’t load and display the message “The application has gone off-line. Please try again later.”
for some other apps, it would display the login page, but pressing the Connect button wouldn’t do anything.
All these apps were deployed with Xojo 2015 and aren’t updated yet to Xojo 2016r1
The solution I found is to add the header Cache-Control: no-transform
Edit: it seems that WebApps that are accessed using https aren’t affected by this option.
Ugh. I remember this from about 15 years ago when the Internet was young. These types of proxy servers were all the rage when the web developers weren’t smart enough to compress their images and size them properly.
I suggest filing a feature request for us to support this… Even if what we do is just turn it off. We do a lot of work to compress the data streams to your app already and I’m guessing that it’s causing issues with that system.
This one’s probably the problem. We already use gzip if the browser supports it, but that whitespace reduction thing is probably causing issues. We’ve experimented with this in the past and there are quite a few places in the framework where removing whitespace actually changes how the code executes.
Here’s a good example that I’ve seen in the past (although our code doesn’t use this specific example:
var i = x + ++y;
What that code does is increment y and then add x and y and put the result in i.
Unfortunately, these whitespace removal algorithms typically change this code to:
var i=x+++y;
Which when it’s executed is seen like this to the JavaScript parser:
var i = x++ +y;
This version adds X and y and puts the result into I and then increments X.
While it’s a subtle difference, it makes all the difference in the world. Like I said, we don’t have any of these, but we do have some areas where code execution changes with whitespace removal.
I know Google’s trying to help, but this technology was a disaster when it was attempted 20 years ago (because everyone had dial-up modems and compression made things load faster) and I suspect that it’ll be short-lived again because most sites just haven’t been audited for this type of problem. Now I’m sure that Google’s sites have been, but offering the users a way to globally turn this “feature” on without having a clue as to the potential side-effects is likely to cause more headaches than anything else. Imagine if a customer calls you and you hadn’t heard of this plugin and the end user forgot that they’d installed it. Then what? You test it on your end using the same browser and platform and everything is fine. Another troubleshooting nightmare that’ll consume tens if not hundreds of hours tracking down because Google “decided” it was a good idea.
I am the tech lead on the Chrome Data Saver proxy. If you could share details with us or a repro case we’d be happy to look into this. In the past whenever this happens we see it’s because a site is assuming that a proxy won’t be applying compression to the assets when served over HTTP (never a safe assumption). It might be that we have a bug on our side, or perhaps there’s a bug in Xojo. Adding Cache-Control: no-transform will also work around it, but that’s just masking whatever the underlying problem is.
Feel free to reach out to me directly: mdw at google dot com. Thanks.
I am the tech lead on the Chrome Data Saver proxy. If you could share details with us or a repro case we’d be happy to look into this. In the past whenever this happens we see it’s because a site is assuming that a proxy won’t be applying compression to the assets when served over HTTP (never a safe assumption). It might be that we have a bug on our side, or perhaps there’s a bug in Xojo. Adding Cache-Control: no-transform will also work around it, but that’s just masking whatever the underlying problem is.
Feel free to reach out to me directly: mdw at google dot com. Thanks.[/quote]
As I mentioned, the problem is probably in our javascript framework. We’ve tried whitespace removal algorithms in the past and we end up with something that’s buggered.
We’re looking into setting up a test system here so we can try it out and see what’s actually being delivered to the browsers when going through Google.
They already harvest all images for Google Images. AFAIK they have never tried to insert any adds there.
I don’t think we have much choice in the matter anyway : Android represents already more than half web browsing traffic. That said, I do appreciate Matt Welsh taking the time to interact in our forum. I am confident Xojo will find a way to have web apps work with Data Saver.
[quote=262742:@Michel Bujardet]They already harvest all images for Google Images. AFAIK they have never tried to insert any adds there.
I don’t think we have much choice in the matter anyway : Android represents already more than half web browsing traffic. That said, I do appreciate Matt Welsh taking the time to interact in our forum. I am confident Xojo will find a way to have web apps work with Data Saver.[/quote]
Even if we do, The biggest problem is that we can’t go back and fix old versions of Xojo. So all you guys that like to switch back to older versions are out of luck.
[quote=262784:@Michel Bujardet]I really don’t mind using the latest Xojo, but I know some do like their old stuff.
Is it possible to apply the workaround described by Matt Welsh with Cache-Control: no-transform ?[/quote]
You probably could if you are using a reverse proxy, but there’s currently no way for you to add your own headers to framework responses directly in Xojo.
Well, since my first site back in the mid nineties I never ceased to learn new ways in order to adapt to web technology.
Now that we have that huge shift from desktop to mobile, it may be time to shed the old ways. After all, it will not be worse than having minimum requirements for Xojo Desktop.
