How do the runtime.onUpdateAvailable and runtime.onInstall events follow each other?
(1°Q) First, can they coexist in the same background script?
The documentation states that onUpdateAvailable can be useful for
postpone an update for example, when you are in the middle of some important operation that we don't
want it to be interrupted.
If the extension has registered an event handler for onUpdateAvailable, then the update will be applied the next time the extension is reloaded.
This happens when:
we restart the browser
the extension is disabled and then re-enabled
the extension reloads itself by calling the runtime.reload method
So I imagine that the onUpdateAvailable event handler that will be executed is the one referring to the old version.
(2nd Q) Am I right?
Now I ask myself:
(3nd Q) When the extension is reloaded later in one of the above ways, will the onInstall event be honored or ignored?
(4th Q) Is there a way to test this behavior by myself, specifically I am referring to the onUpdateAvailable event?
Regardless of onUpdateAvailable's presence, the extension will always be updated when the background script is inactive (i.e. it doesn't run), in particular when it's reloaded or re-enabled.
An onUpdateAvailable listener was necessary for a persistent background script in ManifestV2 because without this listener Chrome would automatically terminate the extension and update it. Chrome did it to prevent an outdated extension continuously running for days/months.
In ManifestV3 the background script can't be persistent by design, so Chrome won't restart an extension even if it doesn't have this event listener. However, you may want to use this event anyway if you connect to a native app via chrome.runtime.connectNative in Chrome 105 or newer because it makes the background run forever (i.e. it becomes persistent) or if you prolong its lifetime artificially.
The onUpdateAvailable and onInstalled listeners can co-exist and are triggered independently.
onUpdateAvailable (of the current version) runs before updating,
onInstalled (of the new version) runs afterwards.
To test the event in case a newer version is present in the web store, press the Update button in chrome://extensions page or call chrome.runtime.requestUpdateCheck() in your extension.
To test the event independently of the web store, configure your extension to use local updates.
Related
The command:
node-debug sls offline
opens a new browser window every time it is run.
How do we stop it from opening a new window every time? I want to reuse the existing window!
This is a known issue with node inspector. Take a look here.
Since 0.9.0 we use https://github.com/benderjs/browser-launcher2 to
start the browser, and make sure it's Chrome/Chromium/Opera (i.e. the
browsers that can properly render node inspector; we detect installed
browsers in the system and choose the most appropriate one; earlier we
used opener module which just delegated opening the browser to the OS,
which would open the defaul browser, which could have been e.g.
Firefox) and this could be the reason why the behavior has changed.
browser-launcher2 actually does a bit more than just launching a
browser, for instance it creates a new profile for Chrome in a
subfolder of ~/ - this is probably the issue that #CalvinScott
reported (i.e. Chrome that was opened was the new profile created by
browser-launcher, not your original profile; you should be able to
open your original profile of Chrome normally)
Also, you may consider this:
Since version 6.3, Node.js provides a buit-in DevTools-based debugger
which mostly deprecates Node Inspector, see e.g. this blog post to get
started. The built-in debugger is developed directly by the
V8/Chromium team and provides certain advanced features (e.g.
long/async stack traces) that are too difficult to implement in Node
Inspector.
1) I was trying to create a portal startup hook, and was overwriting a startup action. The wording in application.startup.events description was a bit vague: it says that this event runs once for every web site instance of the portal that initializes. Does 'web site instance of the portal' mean the same as 'portal' instance?
2) Whenever I redeploy my hook, my application startup event action gets called. Does it mean that the portal instance reinitializes? If so, why don't I observe the same behavior if I redeploy other plugins? (When I redeploy other plugins, startup event action doesn't get called)
3) When I try to overwrite global.startup.events instead of application.startup.events in my hook, my startup action never gets called (I inserted some print statements into the startup method and restarted the server). How can this behavior be explained?
I'd appreciate if you answer even partly, since it would still benefit me and probably the community.
Thanks in advance
A hook is deployed as a web application. Thus an application.startup.events-configured action will fire when the hook gets deployed. AFAIK it will be called with all available instance ids (technically companyId). It seems that the wording in the documentation is unfortunate. However, as all webapplications deploy independent of each other, this is the best effort that's available. And if you update your hook's code and redeploy it, you might want to run the changed startup event.
global.startup.events can not be configured in a hook, thus you see no activity - it's strictly ignored.
Is there any event I can listen to from a Chrome extension when it is removed by the user?
I use Google Analytics to monitor the usage of my extension, and I would like to see if a user removes it.
You can't listen to an event (because you were uninstalled), but you can set a page to open when your extension is uninstalled with
chrome.runtime.setUninstallURL(url, callback)
You can use chrome.tabs.executeScript
While the extension still installed and send an uninstallation function to one tab. The function will be run after 10 seconds using setTimeout.
After 9.7 seconds you need to run clearTimeout so your script will never run.
BUT, if the user will uninstall the extension, the first setTimeout will be called, but the second "clearTimeout" will not be called. So the first function (the uninstall function) will be run in average 5 seconds after uninstalling the extension.
Sorry, if it little hard to understand from my English, but try it, it is working, and you can run any script (that do not using chrome API), after the extension uninstalled. (Edits are welcome)
I am having again (see old question) problems downloading files using the WebClient class. If I open the App and go directly to a page and start downloading, it works great. But if I first click around for a while and then try to download a file the WebClient downloads the first 1% and then stops, triggering a download complete event without errors. I tried only registering to the DownloadProgressChanged event but the WebClient still stops after 1%. And it is always 1%, not 2% or 3%... The current version of the App "FliteLevelTV" is already on the store and performs the downloads, with exactly the same code, without problem.
I am currently using Xamarin Studio 4.0.8(build2) with Xamarin.iOS Version: 6.2.7.1 (Business Edition).
I first thought that probably my WebClient is being garbage collected before it finishes, but if that was the case it would not trigger the download complete event. In any case, in my App, the whole download system is controlled through a Singleton that has a single instance of the file downloader as class property, which also has a single instance of the WebClient as property, and controls that only one file is downloaded at a time using a queue.So I am not sure how I could architect it differently to be more efficient.
Please help, I really need to push some updates and this issue is holding the whole thing.
Just in case anyone is tripped by this problem.
I implemented the process with the HttpWebRequest and found the problem. One of the events hooked to the WebClient was making a change to a value object that was triggering a change to the UI, which of course won't work, being the WebClient on a background thread. It looks like in this situation the WebClient simply swallows the exception, kills the download thread and triggers the completed event without errors.
I want to launch the browser in a different process when a particular link is clicked on the page. When I checked the net I found the following tip: http://www.dslreports.com/faq/3849 . But there we have to change the registry. Is there any simple way of doing this without touching the registry?
If you use the Google Chrome browser, each new window or tab runs in a separate process. Internet Explorer version 8 will do the same (it's currently in the second beta round).
Earlier versions of IE will run a new window in a separate process if it is launched from, say, the Start menu or the command line, or a link in an email (but not by clicking a link within IE). I imagine you could create a proxy that the client would run through, which would intercept the links you care about and launch them by running a command line request. That seems like more trouble than mucking with the registry though (assuming that registry change still works -- looks like your link is from 2002).
I don't believe this is possible unless you change the client computer setup or software it's running.
Why do you want to do this?