As for open an URL upon my extension has been uninstalled, I found the easiest way to do is using chrome.runtime.setUninstallURL, (1) any other good ways?
As for open an URL upon my extension has been first time installed, I don't find something like chrome.runtime.setInstallURL, I implemented the feature with
chrome.runtime.onInstalled.addListener(function(details){
if (details.reason=="install"){chrome.tabs.create({ url: homePage});}
})
I saw AdBlock opens its options page upon first time installed, but it doesn't even used chrome.runtime.onInstalled, its source code is so much complicated , I cannot figure out how it implement the feature ,(2) how it do it ? any other ways to open an URL or its options page upon the extension has been first time installed?
(3) what are the common ways to do something when an extension has been installed or uninstalled?
SetUninstallURL seems to be specifically designed for your task, so it's certainly the right way.
Regarding the installation page, not sure how AdBlock does it, but if you have a persistent background page, one of the simpler ways would be to show the page on every launch if a certain localStorage key is not set.
// background.html startup, for example DOMContentLoaded handler
if ( !localStorage.getItem('intro_shown') ) {
localStorage.setItem('intro_shown', true);
showIntroPage();
}
Local storage of the extension's background page will be persistent, apart from several corner cases (incognito mode in FF, etc).
Upd by Makyen:
chrome.storage seems to be a much better option specifically designed for extension storage needs. It could also be automatically synced with Chrome sync (using chrome.storage.sync)
I have finished an extension for my company and I want to put it on the company wiki so that in order to get it on everyone's machine all I have to do is go around and click the link.
First, I HAVE READ all the documentation from http://developer.chrome.com/extensions/hosting.html about hosting and autoupdating and all that. Part of it confuses me and I can't find any more information about this:
Google Chrome considers a file to be installable if either of the following is true:
The file has the content type application/x-chrome-extension
The file suffix is .crx and both of the following are true:
The file is not served with the HTTP header X-Content-Type-Options: nosniff
The file is served with one of the following content types:
empty string
"text/plain"
"application/octet-stream"
"unknown/unknown"
"application/unknown"
"*/*"
This looks like it wants a MIME style setup? but I have never done anything with this. I have the ability to change what I want to the Locally hosted Wiki, all I need is to understand what need to change to make the link installable. I will keep looking for examples.
Note: The reason it is not going on the app store is that there is really no reason to. It is branded for our company, and communication with our specific servers is hard-coded into it.
In version 21 (or so), Chrome disabled the ability to do a simple link-click install of off-store extensions. There is a discussion of the change in this bug report:
You are no longer supposed to be able to install extensions off-store in Chrome... In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.
There is, therefore, no longer any way to install an extension simply by clicking a link, except by hosting it in the Web Store. You will need to download the file and then drop it into chrome://extensions.
The documentation you reference looks out of date (that's Google's fault, not yours). It definitely fails to mention the new drag-and-drop requirement. It also talks about the file's "content type" and the X-Content-Type-Options HTTP header required to make the CRX installable; however, when you install an extension by dropping it into chrome://extensions, I doubt very much that Chrome remembers what HTTP headers were set when you first downloaded the file.
EDIT: You can also use the --enable-easy-off-store-extension-install command line flag to restore the old instalation behavior.
You can do an "inline install" of an app hosted on the web store. The new changes are forcing people to move our extensions to the web store, but the inline installation should allow your users to not need to leave your page to install.
I'm trying to use the new chrome inline install feature for extensions (see here: http://code.google.com/chrome/webstore/docs/inline_installation.html).
I can't get it to work unfortunately, and have very little clues to go by. I've added the link element to the head element
<link rel="chrome-webstore-item" href="https://chrome.google.com/webstore/detail/pnnfemgpilpdaojpnkjdgfgbnnjojfik">
and I call
chrome.webstore.install();
in a jquery event handler. I've also verified my domain, however, I'm testing this on a local machine but have a subdomain pointed to my localhost (i.e. testing on dev.getbentobox.com which is mapped to localhost in my hosts file if that makes a difference).
When stepping through my js using the chrome debugger, chrome.webstore.install() is getting called and the function is defined. However, nothing happens - no install, no javascript exception, no console printing, nothing.
any ideas?
Your Chrome Web Store item doesn't show the verified site. If you compare it to the "We Heart It" extension, which can be inline installed from http://weheartit.com/heart-button, it has a green check saying "from weheartit.com". You'll need to edit your Web Store item, and associate your verified site with the item.
As of December 2018 (Chrome version 71), Google has disabled this feature. The workaround is to send the user to your extension in the Chrome Web Store.
Source: https://developer.chrome.com/extensions/inline_faq#change_dec18
What will change in M71 (Dec 2018)?
Beginning in M71, Chrome will no longer support the chrome.webstore.install() method and calling it will fail, resulting in a broken installation flow on your site. At this point calls to the API will throw a JavaScript TypeError. You should remove any calls to the API method before this date.
I want temporarily disable websocket in Google Chrome to debug a javascript to make sure it work for any browser without websocket support.
To begin, I'd say that there are better mechanisms to test your JavaScript in a websocketless environment. You could run your JavaScript in IE9, for instance, which doesn't implement the protocol. They're still disabled for the moment in Firefox 4 as well, if that's more your style.
Assuming that there's some good reason that you need to test in a websocketless Chromium, I think you're out of luck. There's not a trivial mechanism to disable WebSockets in Chromium. It's not built in as a command-line switch, nor is there a configurable flag. Since there's no mechanism to make this happen natively, I wouldn't suggest spending time testing the scenario. Every version of Chromium that your users use (e.g. 9+) has websockets enabled.
All that said, if you really need to disable websockets, the closest you can get without recompiling the browser would be to drop the relevant variables in your test code:
WebSocket = undefined;
would be relatively brute force, but should work. You could even create an extension to inject that JavaScript into every page you visit, for a truly websocketless experience (assuming, again, that that's somehow valuable for your use case).
I was able to block WebSockets with Fiddler.
Go to Rules / Customize Rules... in the Fiddler menu
Add this code to class Handlers (I put it after the existing RulesOption items):
// Block Websockets
public static RulesOption("Block Websockets")
BindPref("fiddlerscript.rules.BlockWebsockets")
var m_BlockWebsockets: boolean = false;
Add this code in OnBeforeRequest:
if (m_BlockWebsockets && oSession.oRequest.headers.Exists("Connection") && oSession.oRequest["Connection"] == "Upgrade") {
oSession.oRequest.FailSession(502, "Blocked", "Fiddler blocked websocket connection");
return;
}
This adds a menu option Block Websockets to the Rules menu. When it is toggled on, ws connections should be blocked based on the Connection: Upgrade header.
After seeing #user3661841's answer on another question, I created a GreaseMonkey/TamperMonkey script that will allow you to disable WebSockets in a similar way.
Here's instructions for Chromium based browsers (Chrome, Brave, Sidekick, etc.):
Download the TamperMonkey extension from the Chrome Store
Install this script from GreasyFork. By default, installing this script will disable WebSockets on every site you visit. If you don't want to block WebSockets immediately, click on the TamperMonkey icon and the toggle switch to disable blocking.
When you want to turn off WebSockets, click on the TamperMonkey icon and the toggle switch to enable blocking. Refresh the page.
Disable the script when you no longer want to block WebSockets.
Here's the switch you want to click to disable/enable WebSocket blocking:
NOTE 1: You should be able to see output in your console marking that the WebSocket connection was attempted to be opened, but blocked.
NOTE 2: Make sure to disable this when you're done disabling WebSockets for development. If you only use TamperMonkey to disable WebSockets, You'll want your TamperMonkey to look like this most of the time:
And like this when you want to block:
To disable ws you can simply add "Request blocking" in chrome dev tools, but only if specific file is initiating websocket to prevent it from loading if you can't do that this solution might not work
For example:
https://www.websocket.org/echo.html
Websocket connection is initiated by echo.js, so you can prevent that file from laoding and websocket will never start.
Initiator file can be found in network tab
I'm writing a web app to be used offline on iOS. I've created a manifest, am serving it up as text/cache-manifest, and it usually works fine, when running inside Safari.
If I add it as an app to my home screen, then turn on Airplane mode, it can't open the app at all -- I get an error and it offers to close the app. (I thought this was the entire purpose of an offline app!)
When I load the app a first time when online, I can see in my logs that it's requesting every page listed in the manifest.
If I turn off Airplane mode, and load the app, I can see the first file it's requesting is my main.html file (which is both listed in the manifest, and has the manifest=... attribute). It then requests the manifest, and all my other files, getting 200's for all (and 304's for anything requested a second time during this load).
When I load the page in Chrome, and click around, the logs show the only thing it's trying to reach on the server is "/favicon.ico" (which is a 404, and which I don't think iOS Safari tries to load, anyway). All of the files listed in the manifest are valid and served without error.
The Chrome inspector lists, under "APPLICATION CACHE", all the cached files I've listed which I expect. The entire set of files is about 50 KB, way under any limit on offline resources that I've found.
Is this supposed to work, i.e., am I supposed to be able to create an offline iOS app using only HTML/CSS/JS? And where do I go about figuring out why it's failing to work offline?
(Related but doesn't sound quite the same to me, since it's about Safari and not a standalone app: "Can't get a web app to work offline on iPod")
I confirm that name 'cache.manifest' solved the offline caching problem in IOS 4.3. Other name simply did not work.
I found debugging HTML5 offline apps to be a pain. I found the code from this article helped me figure out what was wrong with my app:
http://jonathanstark.com/blog/2009/09/27/debugging-html-5-offline-application-cache/
Debugging HTML 5 Offline Application Cache
by Jonathan Stark
If you are looking to provide offline access to your web app, the Offline Application Cache available in HTML5 is killer. However, it’s a giant PITA to debug, especially if you’re still trying to get your head around it.
If you are struggling with the cache manifest, add the following JavaScript to your main HTML page and view the output in the console using Firebug in Firefox or Debug > Show Error Console in Safari.
If you have any questions, PLMK in the comments.
HTH,
j
var cacheStatusValues = [];
cacheStatusValues[0] = 'uncached';
cacheStatusValues[1] = 'idle';
cacheStatusValues[2] = 'checking';
cacheStatusValues[3] = 'downloading';
cacheStatusValues[4] = 'updateready';
cacheStatusValues[5] = 'obsolete';
var cache = window.applicationCache;
cache.addEventListener('cached', logEvent, false);
cache.addEventListener('checking', logEvent, false);
cache.addEventListener('downloading', logEvent, false);
cache.addEventListener('error', logEvent, false);
cache.addEventListener('noupdate', logEvent, false);
cache.addEventListener('obsolete', logEvent, false);
cache.addEventListener('progress', logEvent, false);
cache.addEventListener('updateready', logEvent, false);
function logEvent(e) {
var online, status, type, message;
online = (navigator.onLine) ? 'yes' : 'no';
status = cacheStatusValues[cache.status];
type = e.type;
message = 'online: ' + online;
message+= ', event: ' + type;
message+= ', status: ' + status;
if (type == 'error' && navigator.onLine) {
message+= ' (prolly a syntax error in manifest)';
}
console.log(message);
}
window.applicationCache.addEventListener(
'updateready',
function(){
window.applicationCache.swapCache();
console.log('swap cache has been called');
},
false
);
setInterval(function(){cache.update()}, 10000);
Sometimes an application cache group gets into a bad state in MobileSafari — it downloads every item in the cache and then fires a generic cache error event at the end. An application cache group, as per the spec, is based on the absolute URL of the manifest. I've found that when this error occurs, changing the path to the manifest (eg, cache2.manifest, etc) gives you a fresh cache group and circumvents the problem. I can vouch that all of our web apps work offline in full-screen with 4.2 and 4.3.
No offline web app (as of iOS 4.2) can run without an internet connection (which means Airplane mode, too) when using <meta name="apple-mobile-web-app-capable" content="yes" /> in the html head section. I have verified this with every example I've seen and the ones that use Safari to render the site work fine, but when you throw in that meta tag, it won't work. Try your app without it and you'll see what I mean.
I have found that clearing the Safari cache after enabling Airplane mode to be an effective way of testing whether the app is really functioning offline.
I have sometimes been fooled into thinking that the application cache was working when it wasn't.
I had struggled with this iOS 4.3 "no offline cache" problem since I updated my iPad to 4.3.1 from 4.2. I saw in another post in this site that it was working again in 4.3.2. So I updated by iPad again, now to iOS 4.3.3. But still couldn't get the offline caching to work until I renamed my manifest file to "cache.manifest". Then the caching started working again and I could run my HTML5 offline app from the Home Screen. I did not need to put the favicon.ico in to the cache manifest. And I also had full screen going (setting the "apple-mobile-web-app-capable" to "yes").
I have several working offline and on/offline web apps.
When I turn off airport mode, I get a request for the manifest and some other files.
I don't get requests for images, JavaScript, CSS or cached AJAX files.
If you see requests for your resources, IOS doesn't have them cached.
Safari in general is more picky with manifests.
I suggest you try Safari on your computer.
I have run into the same problem today on iOS 4.3. I was able to fix the problem by adding a favicon.ico file and also adding it to the manifest.
I've written an offline app that still seems to work in 4.2 and 4.2.1; the post is a little dusty, but the code still runs:
http://kentbrewster.com/backchannel/
Remy Sharp has a newer post with code that also works, here:
http://remysharp.com/2011/01/31/simple-offline-application/
His app:
http://rem.im/boggle/
After days of messing with getting offline web apps to work on an iPhone/iPod Touch using the Webserver's HTTP authentication, I discovered these useful nuggets:
Make sure Safari is at the URL root of the web app when tapping "Add to Home Screen". I used jQuery Mobile and was sometimes adding the link with"/#pageId". Caused trouble.
Run your Ajax calls in serial. This might only be important if your web app is using HTTP authentication, but my app was firing a whole slew of Ajax calls on page load in parallel and it caused the app to hang on the "apple-touch-startup-image".
Ajax calls are "successful" when offline (at least using Prototype.js). Test for an actual piece of data in the Ajax response, not just on the HTTP status. I used this to test for displaying cached (SQL) or live data.
In the manifest use "NETWORK:\n*\n". From what I could muster, this is a catch-all statement for anything not explicit in the "CACHE:" section. Use Chrome to make sure your manifest is correct. Look at Chrome's console for errors.
Not directly related, but tripped me up for a bit, openDatabase.transaction() calls are ASYNCHRONOUS! Meaning, the line of JS code after transaction (execute(), error(), success()) will execute BEFORE the success() function.
Good luck!
I found this solution that seemed to work for me, since I also ran into this problem during my development. This fix has worked fine for me so far and also for other people that I've asked to test it with, and I'm able to get it running offline (in airplane mode) and off the home screen after caching and whatnot. I've written a post about it on my site:
http://www.offlinewebapp.com/solved-apple-mobile-web-app-capable-manifest-error/
Delete your current web app icon on the home screen.
Go to settings and clear your Safari browser cache.
Double tap your home button to open the multitasking bar. Find the Safari one, hold your
finger down on it, and exit it.
Please let me know if this works for you also! Good luck!
I've written an app and it works fine through the mobile browser, but when adding the desktop... Doesnt work. I guess apple have given up on IOS4 and all efforts are now on OS5. Shame :(
I have one potential workaround for this - it seems a bit crazy, but here goes... I work with the cache.manifest and full screen apps a lot (here's a test if you need: http://www.mrspeaker.net/2010/07/12/argy-bargy/ - add to home screen then turn on flight mode and it launches - at least, as of iOS 4.2.1)
One weird thing I found is that sometimes it seems that some kind of "meta" information in files can mess them up from being cached - Have you ever noticed that in bash that if you do a "ls" some files (depending on your colour settings) are highlighted for no apparent reason? Files can have meta data that the operating system (I think) adds automagically - and there are ways to remove it... I can't remember why but here's some more details: Strip metadata from files in Snow Leopard
After tearing my hair out one day - and refusing to give up because I knew it SHOULD have worked... Chrome was saying it loaded all the files, but ended with a generic error. In the end I recreated the project structure with blank files and copy/pasted the contents over. It worked - started caching as it was supposed to!
When I looked at the files I noticed there was some meta info. I tried scrubbing this info and the original project worked again. I'm not sure this was the reason it worked again - perhaps it was just a coincidence.
Because it worked, I didn't think too much about it. The same problem happened again some months later and the copy/paste trick worked again. I was busy, so I didn't investigate further - but vowed I would get to the bottom of it the next time it happened.... but I haven't had to yet.
Phew. Anyway, glad I got to write that down somewhere...
[UPDATE: months and months later - I've not been able to reproduce this, so I don't think it's the metadata]