I'm having trouble loading my updated XML for a contextual gadget in gmail. I was reading through the Google Gadgets FAQ, and it is stated that the XML files are cached for a few hours.
I've been searching for a while on how to get around this and found a few solutions such as:
Add a nocache=1 (or something close to that) to the querystring
Add anything to the querystring
Use the "My Gadget" gadget to disable caching.
None of these solutions work for me, and I'm suspecting it's because none of them are newer than 2010 and things tend to change. Has anyone else run into this issue recently?
It is not &nocache=1 but &nogadgetcache=1 that must be added;
make sure you append this before the # in the URL !
from the docs :
Changes to gadget don't show up immediately.
Gmail is probably using a cached version of the gadget. Changes to gadgets can take some time to be reflected because of caching. Solution: Make sure you include the flag &nogadgetcache=1 in the URL when you start Gmail to test your gadgets. This flag ensures that any changes you make to gadgets will show up in your Gmail account immediately. If you reference external resources in your gadget, such as JS or CSS files located on external servers, those resources are still subject to caching.
https://developers.google.com/gmail/contextual_gadgets
Related
My searches have turned up nothing concrete. My extension uses Google's file picker to allow the user to browse their sheets and choose a desired file to write some data to, which manifest v3 breaks because of some GAPI limitations. Unless I've missed something obvious, there does not seem to be a simple workaround or method for this to migrate to v3 -- it just seems to be disallowed.
I'm not asking if there's a way to do something that they intend to not be possible (even though I doubt such a thing would exist with Google) but I'm optimistically hoping that maybe there is some hacky/annoying workaround that still fits within their rules. If I absolutely have to just allow them to set a sheet URL manually I will...I'm just trying to avoid it.
Any tips or suggestions would be appreciated.
You may have to test it yourself to make sure there are no weird behaviors, but Google has some recommendations regarding this in their migration guide:
In Manifest V3, all of your extension's logic must be included in the extension. You can no longer load and execute a remotely hosted file. A number of alternative approaches are available, depending on your use case and the reason for remote hosting. Here are approaches to consider:
Configuration-driven features and logic
In this approach, your extension loads a remote configuration (for example a JSON file) at runtime and caches the configuration locally. The extension then uses this cached configuration to decide which features to enable.
Externalize logic with a remote service
Consider migrating application logic from the extension to a remote web service that your extension can call. (Essentially a form of message passing.) This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting to the Chrome Web Store.
Bundle third-party libraries
If you are using a popular framework like React or Bootstrap, you can download the minified files, add them to your project and import them locally.
For your case, option #3 seems like the easiest. Looking at the Google Picker API documentation it only uses two relatively small script files, https://apis.google.com/js/api.js and https://accounts.google.com/gsi/client. You could try to bundle these in your Chrome extension and call the methods locally.
I've built a Microsoft Teams channel tab with SSO and I'm hosting the tab application which I've built with React via create-react-app.
The auth works well, and the app loads and runs.
But when I update my app on the web site, the Teams desktop client (Mac and PC) will sometimes cache the old app and will not pick up the changes. But then sometimes it will.
If I run the web client, it usually picks up the changes.
I've verified that I'm serving up new bundles with different names each time I update. But running the Teams desktop devtools I can see that Teams is asking for the old bundle, every time, so it's definitely caching the response from my app's URL.
I've read about the problems people have with the Teams desktop client has with caching Sharepoint content and not picking up content changes. I've tried the cache clearing techniques but they don't seem to work for this issue. And I can't reasonably have users do crazy cache clearing every time I make an update to the tab app.
What should I do? Some have suggested I need to update my version in the app manifest and redeploy to Teams -- that seems really brutal. Do I need to set some cache headers in a certain way to force the Teams client to pick up the new code?
Solution
Set a Cache-Control response header to no-cache (or must-revalidate) for your build/index.html.
Explanation
We had the exact same issue. Turns out it was because we cached our build/index.html.
According to the create-react-app doc, only the content of build/static/ can safely be cached, meaning build/index.html shouldn't be cached.
Why? Because files in build/static/ have a uniquely hashed name and are therefore cache busted on deployment. index.html is not.
What's happening is since Teams uses your old index.html, it tries to load the old /static/js/main.[hash].js defined in it, instead of your new JS bundle.
It works properly in the Teams web client because most browsers send a Cache-Control: max-age=0 request header when requesting your index.html, ignoring any cache set for the file. Teams desktop doesn't as of today.
This seems like an issue with the way your app is managing the default browser caching logic. Are service workers enabled for your app? What cache control headers is your web server returning?
There are some great articles that describe all the cache controls available to you; for example:
https://medium.com/#codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c
Have you tried doing something like this to prevent caching of your page (do note that long term you might want to use something like ETags which is a more performant option):
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#preventing_caching
P.S. You can also follow the instructions here to open the dev tools in the Desktop Client to debug all this:
(How) can I open the dev tools in the Microsoft Teams desktop client?
And even force clear any cached data/resources for your app:
Problem Description: deployed a new gadget xml but gadget does not refresh although parameter nogadgetcache=1 is used.
Steps to Reproduce:
i makes changes to a gadget xml. Deploy using Eclipse, to an appspot site.
2, Deploy through code.google.com's google app console ( i think this is only for changes to manifest, but with or without this step, refresh does not happen ).
Able to see latest changes on the appspot site hosting the gadget xml
logout of gmail, login with : https://gmail.com/?nogadgetcache=1
gmail gadget behaves like the old version.
Even stopped development for more than a week, still not refreshed.
Anyone here can help or encounter similar issues?
Try renaming the gadget spec file so it uses a new URL (then update your manifest to reflect this new URL). This is from Google's documentation.
we have the same problem it take 30mins to get it work..
https://mail.google.com/mail/u/0/?shva=1#inbox?nogadgetcache=1
i found the problem in chrome take's very long.. if you do it in internet explorer prived mode it much quicker..
I'm wondering how I can find out where the culprit is, as to what is NOT being transmitted over SSL on my website. It's blowing my mind, because I use relative URLs or explicitly choose HTTPS:// for all links, images, etc...
Any ideas/tools to find out what the issue is?
Thanks.
If you mean that some resources are transferred over HTTP without encryption, you can check for this in Chrome's Developer tools in the tab Resources - that should tell you which parts come from where - look for those with address starting with http:// .
Alternately, use Fiddler: by default, it won't decrypt HTTPS connections, so you'll be seeing CONNECT requests for HTTPS, and GET/POST for HTTP - those are your culprits.
For those, like myself, who run into this issue i suggest a few tips while designing your website.
Always use relative paths when ever possible "images/someimage.png" instead of using domain paths like http://someDomainName/images/someimage.png so on. Any one of these and it will cause the browser to throw that warning at you.
When linking to external content, Google/other Ads, javascript sources(such as jquery, so on), or any other media... make sure you use a https:// link if they have one available. Myself, i had one tiny image for a link to an external site but they did not offer a https link to the image, so i simply downloaded it and put it in my images folder. Problem solved.
The Chrome resources list is a very helpful tool, not sure if Firefox has something similar in its tool box. Another method, if you have shell/command line access, is to use grep to search the files for "http:". This, most often, will show anything that is linking to non secure content.
We have an Adobe AIR application which could be possibly downloaded from multiple domains. And when it's run, it should connect back to the site it was downloaded from to get data to show to the user.
So far we have a separate application build for each domain with a site URL hardcoded into it. And I wonder is there a way for AIR application to find out at runtime the URL (or at least domain) from which it was downloaded?
What we would like to have is a single downloadable binary served from all different domains, which still can know it's origin URL.
There's no function to retrieve such information, it would just make no sense if you think about it.
The most stable way is to include an external configuration file into the package.
Note that you can use ANT to automate this process for this final deployment.
There's no direct way to do it.
Here are some options which come in mind:
Build different versions for each site (this could be automated)
Let user choose the site at first launch
Try to guess it using using whatever resources you have (timezone, language, etc)
How should this work? The only solution i see (independent from AIR) is that you deliver an extra (properties) file with the application, containing the URL downloaded from. So you dont need to build a separate app for each domain, but only package a different domain-file with it. The app then reads this file and executes some context sensitive stuff.
I am trying to address the exact same issue right now.
It looks like you can modify the install badge to pass parameters to the air app.
From what I gather the values are only passed down on install or launch-from-badge.
Something I plan on researching is that one of the parameters in "AIRBadge.as" is _appURL which is the URL of the page the badge is on. I don't yet know if that value makes it down to the installed AIR app in some way; but it could be a useful property. I'm ultimately hoping that the AIR install process injects that into the application descriptor xml, but I'm not holding my breath.
Check this page out: http://archive.davidtucker.net/2008/01/10/air-tip-5-passing-arguments-to-an-application-on-install/#
When the user downloads, you could store their IP address in your central DB. Then when the app is installed and runs the first time, the app could hit your central DB to match up their IP address with the server they downloaded from.
A cookie with a specific name being stored on a download page, and the AIR app looking for that? Though that might not work for direct downloads. It might also be hard to pull off since knowing the specific browser used to download it would be an issue.