After publishing a new version of our extension to production, we sometimes see a weird behavior:
The extension on the browsers seems to be only partly updated (after given some time).
Our internal version number (part of our code) shows in such cases a previous version number, although some features and resources from the newer version already exist.
We have seen this occasionally in all browsers and on different operating systems.
Any idea why is that and what can be done?
Note: our extention.js and popup.html files are about 380kb (I don't know if that makes any difference).
Whilst I don't know the specifics of your scenario, in general, updates are automatically checked for and pulled if required by the extension several times a day. If there is anything that interrupts the process such as connectivity problems, then a partial update may occur though there are mechanisms in place to try and protect against this. Also, note that resources update if there are changes to one of the core files (extension.js or background.js).
[Disclosure: I am a Crossrider employee]
Related
We run a fairly popular chrome extension with 200K+ installs and 70-90K active users (according to chrome webstore reports)
We have noticed that our numbers have started dipping in the past two months, despite a steady stream of hundreds of new daily installs. These numbers are different but broadly correlate with our Google Analytics numbers.
We suspect that some fraction of our installs are not being working, either because of some browser version-specific bugs or because it is being blocked by an anti-virus.
How do we know for sure? There doesn't seem to be some easy error reporting that we can rely on and the only other option seems to involve trying different versions and anti-viruses to see if this is true. Is there a better method?
Provide an after-uninstall form (using chrome.runtime.setUninstallURL - since Chrome 41) where a user can select the reason for uninstalling. Some extensions (ZenMate, for example) do it.
I've been playing with IBM Bluemix (liking it a lot so far) and we are considering to use it for production. What I'm not totally clear on is what happens when runtime environments or services get updated. I assume this happens quite frequently.
Will the new version be always backward compatible? If so, is this guaranteed somewhere in the terms of service?
What I am trying to avoid is to put production code on the platform and then having to update it constantly (or having it break) due to runtime or service updates.
Does anyone have any experience? Have past updates always been backward compatible?
Mark
While I don't believe there is a guarantee that the buildpacks will always be backwards compatible, you will always be able to select the previous buildpack version.
Try running a 'cf buildpacks' command and have a look at the buildpack names and version info encoded therein and think you'll see what I mean.
When buildpacks are updated they won't be used for your application until you restage it, so you have some control over when to pick up the updates as well. This gives you a chance to test it on non-production versions of the app.
I'm developing a Chrome App (as a packaged app/extension) which purpose is to act as the base platform for several fullscreen apps to be build on top of. Chrome will be running on Ubuntu Linux.
And no trouble so far. But then I was told, that an intended app it is to be the platform for requires the source code to be updated with very short notice, as it probably is to be deployed for large scale use before the system has been tested through (even though it's a bad idea to deploy software that's not completely stable, but we're on a tight schedule). The problem is, that the "a few hours" interval for the autoupdating mechanism just isn't good enough.
So I somehow need to have the updating interval changed. I know this can be done with the --extensions-update-frequency command line switch, but as apps cannot access the command line (for obvious security reasons), and I'd prefer that the intended background page was to handle all the "administration", I don't think that switch is possible to use.
Is it somehow possible to update at a higher frequency? Or at times when it's ordered to?
There is now a method chrome.runtime.requestUpdateCheck():
Requests an update check for this app/extension.
It will return a status, which can be either "no_update", "update_available" or "throttled".
Unfortunately, the docs do not specify the limits for frequency that will trigger "throttled".
Your best option will be to have the extension manually check with your servers for an updated version. If there is an updated version show the user a desktop notification to manually update.
Potentially you could write a NPAPI plugin to modify the update frequency.
This may cause issues with CSP but you can try to live load JavaScript from your server that executes in the extension. In this case to "update" your extension you would simply update the JS hosted on your servers and the extension would automatically start using it on next load.
Wanting to take advantage (for the first time) of the open-source nature of open-source software, I want to edit part of Google Chrome. I know exactly which source file to edit, and it's a very small change. However, the entire compressed source distribution tarball is about a gigabyte, and I can't even imagine how painful the recompiling process would be, not to mention how much disk space it would use.
So, the question is: Is there any better way to modify the program than to recompile the entire thing? It seems to be quite a painful thing to do for small changes.
No, there is no other way recompiling Chromium. I recommend you to use the Google Chrome Extensions API if you can. If you want to recompile Google Chrome, the steps are pretty easy, everything is explained in http://dev.chromium.org/developers Some tips (since I am a Chromium contributor)
For a quick start guide: https://docs.google.com/present/view?id=dd9mrt45_0dmtd49c6
Read documentation: http://dev.chromium.org/developers
Make sure you have 10GB of space.
Make sure you have a fast computer (64bit), the more cores/mem the better.
The source code is "not" just 1GB, it is more, after you checkout the sources, you would need to sync your DEPS (thirdparty) via gclient sync That will add another couple of GB.
It will take a lot of time to compile (~1 hour) on modern PCs. If you have a very fast computer, the time of compilation would decrease exponentially.
According to you comments above, you would need to checkout the source at least once, we use Git or SVN for that (read the documentations, we have explained as much as we can on the site). Once you finished compilation, you can always update your source (the same way you update your repository (git pull, gclient sync) Then incremental buildings will be around 5-10 minutes depending what you have changed.
Please follow the documentation (http://dev.chromium.org), I am saying that again because the Chromium community worked hard to make these documentations up-to date, they help new comers get familiar with the project.
Chromium is big, but fun to work with, have fun hacking :)
The open sourced Chromium is not the same thing as Google Chrome. Some specific features (like H264 support) are available in Chrome, but not Chromium. You cannot "build" Chrome; you can build Chromium.
A more feasible approach to make your modification might be to write it as an Extension.
Google has open-sourced the auto update mechanism used in Google Chrome as Omaha.
It seems quite complicated and difficult to configure for anybody who isn't Google. What is the experience using Omaha in projects? Can it be recommended?
We use Omaha for our products. Initially there was quite a bit of work to change hardcoded URLs and strings. We also had to implement the server ourselves, because there was not yet an open source implementation. Today, I would use omaha-server.
There are no regrets with ditching our old client update solution and going with Omaha.
Perhaps, you can leverage the courgette algorithm, which is the update mechanism that is used in Google Chrome. It is really easy to use and apply to your infrastructure. Currently, it just works for Windows operating systems. Windows users of Chrome receive updates in small chunks, unlike Mac and Linux users who still receive the chunks in total size.
You can find the source code here in the Chromium SVN repository. It is a compression algorithm to apply small updates to Google Chrome instead of sending the whole distribution all the time. Rather than push the whole 10 MB to the user, you can push just the diff of the changes.
More information on how Courgette works can be found here and the official blog post about it here.
It works like this:
server:
hint = make_hint(original, update)
guess = make_guess(original, hint)
diff = bsdiff(concat(original, guess), update)
transmit hint, diff
client
receive hint, diff
guess = make_guess(original, hint)
update = bspatch(concat(original, guess), diff)
When you check out the source, you can compile it as an executable (right click compile in Visual Studio) and you can use the application in that form for testing:
Usage:
courgette -dis <executable_file> <binary_assembly_file>
courgette -asm <binary_assembly_file> <executable_file>
courgette -disadj <executable_file> <reference> <binary_assembly_file>
courgette -gen <v1> <v2> <patch>
courgette -apply <v1> <patch> <v2>
Or, you can include that within your application and do the updates from there. You can imitate the Omaha auto update environment by creating your own service that you periodically check and run Courgette.
I've been using Omaha in various projects since 2016. The projects had between a handful and millions of update clients. Target operating systems were mostly Windows, but also some Linux devices and (via Sparkle) macOS.
Omaha is difficult to set up because it requires you to edit Google's C++ implementation. You also need a corresponding server. The standard implementation is omaha-server and does not come from Google. However, in return it also supports Sparkle for automatic updates on Mac (hence why I mentioned Sparkle above).
While setting up the above components is difficult, once they are configured they are work extremely well. This is perhaps not surprising given that Google use Omaha to update millions (billions?) of devices.
To help others get started with Omaha, I wrote a tutorial that gives a quick overview of how it works.
UPDATE
Customizing google omaha isn't that easy espacialy if you have no knowledge about c++, python or com.
Updates aren't published that frequently
crystalnix/omaha is managed by the community and they try to merge the main repo into their's; additional features are implemented and basic things are fixed
google/omaha is more active and changes from google are added but not frequently
To implement manual updates in any language you can use the com classes
Resume
google omaha is still alive but in a lazy way
bugs are fixed but do not expect hotfixes
google omaha fits for windows client apps supported from windows vista and upwards
the server side I'm using supports also sparkle for crossplatform support
feedbacks and crashes are also supported on the server
feedbacks are sent with the google protocol buffers
crash handling is done with breakpad
I personaly would go for google omaha instead of implementing my own solution. However we will discuss this internal.
In the .NET world you might want to take a look at ClickOnce deployment.
An auto-update mechanism is something I'd personally code myself, and always have in the past. Unless you have a multi-gigabyte application and want to upload bits and pieces only, just rely on your own code/installer. That said, I've not looked at Google's open source library at all.. and didn't even know it existed. I can't imagine it offering anything superior to what you could code yourself, and with your own code you aren't bound by any licensing restrictions.