I need help to create a callback when my chrome extension in disabled. I have already referred this link that says about adding a listener onDisable. But this doesnt work for own. When my extension is disabled, it does nothing. There is an answer in this link that says we can not do this, But I am still hoping that I can find something new on this topic. Please help me in this.
You are correct that management API cannot catch the extension itself being disabled or uninstalled. This is by design - you don't want extensions to be able to stop you from removing them.
There is no event you can process when either of those happen.
There is an exception in that your content scripts continue to run in an "orphaned" state and can detect that the parent extension is not there anymore by poking at Chrome API (and possibly onDisconnect event on a Port object), but at that point the content script can't do much.
Curiously, there is no event that will fire on enabling either. This can cause problems when an update happened while an extension was disabled and relies on runtime.onInstalled event to perform upgrades.
Related
I'm working on Chrome extension which needs to perform an action just before Chrome closes. Is there any method like chrome.window.onClose.addListener(...), or chrome.runtime.onClose.addListener(...) to ensure that something will be done and then chrome will close itself?
I've been struggling with this problem for two weeks. Here are the options for potential solutions that I've found, but they didn't work.
My investigation results:
Using function: chrome.runtime.onSuspend.addListener(...) - I don't know why, but it doesn't work at all for me. For example, I've tried to write a callback for this event, which tries to add hardcoded data to the indexed DB, but it doesn't add it. Description of this method even says that the callback is not guaranteed to be completed. OnSuspend documentation
Sent to the event page just before it is unloaded. This gives the extension opportunity to do some cleanup. Note that since the page is unloading, any asynchronous operations started while handling this event are not guaranteed to complete.
Chrome working in a background - with this option my extensions seems to work, but... only on Windows older than Windows 10. I've checked few options and on my other computer, which has Windows 7 installed, processes connected to Chrome are closing more slowly, which gives time for my extension to perform necessary tasks. Unfortunately, Windows 10 kills all the processes much faster. I've check option "continue running background apps when google chrome is closed", but it doesn't change anything. I've also enabled flag "#enable-push-api-background-mode", it hasn't helped either.
Keep Chrome running in the background on Win10, Enable flag to keep Chrome processes running
chrome.app.window.current().onClosed - I've found a similar question on Stack Overflow, and one of the answers was the code mentioned above. The problem is when I try to type chrome.app.win... inside console, it doesn't show any suggestions both in background script and content script. Google's documentation doesn't mention any permission that I've to add inside my manifest.json to get access to this functionality.Stack Overflow similar question, Google's documentation about chrome.app
Methods build in web browser - I've thought that method window.onclose might be useful in my case. I've performed the same test as for chrome.runtime.onSuspend, but the result was exactly the same. Documentation
I've stuck and haven't got any idea how to solve my problem. Maybe I missed something important? Hope you will help me.
I want to run my test cases via protractor, but due to some limitation I want protractor to start on a page that is already open, meaning I don't want driver to start by loading chrome and going to the url defined in test case. Is there any way if I can use the url that is already opened on screen and then process further with what is defined in the test case such as clicking on elements or sending keys etc.
Regards
Syed Zaidy
This feature is not implemented in selenium. It was requested but rejected because it is not feasible.
If you read the issue here, and scroll down to last comment :
I'm going to make a call on this one: it's a browser specific feature, and not something
that we can implement in a general way. With IE, it's possible to iterate over the
open windows in the OS and find the right IE process to attach to.
Firefox and Chrome, OTOH, need to be started in a specific mode and
configuration, which means that just attaching to a running instance
isn't technically possible.
Closing as "not feasible" here as this is a browser specific feature.
I have a problem with my Chrome Extension that that depends on the
chrome.tabs API.
My extension is mostly running normally. Sometimes I do a
chrome.runtime.reload() and that works mostly without problems, but
now and then (I have neither been able to predict when or reliably
replicate it) when the background script comes back after the restart
the chrome.tabs reference is undefined. Since I depend on that API
the extension can't start. That scenario can be detected, but when I
try to do a chrome.runtime.reload(), chrome.runtime.reload is also
undefined. So then I don't have a method to restart again.
I realise that I probably ought to develop soft restart capabilities
for my extension to return to a blank state, but that's very work
intensive, so I wanted to ask the community if anyone else have any
experience with this problem, and in that case, how have you solved
it?
Here is my permissions from the manifest.json file:
"permissions": [
"tabs",
"contextMenus",
"webNavigation",
"webRequest",
"webRequestBlocking",
/* some whitelisted web URLs... */
Thanks a lot #Xan for
pointing me towards this
other
question that seems to cover the exact same phenomenon.
I have decided that enough indications point towards this being a bug
in chrome's handling of background pages.
I also have some additional observations:
The question pointed to by #Xan have references to a likely bug in
Chrome's background pages.
When I replicated the bug by calling chrome.runtime.reload() in my
background page's developer tools console I found that
chrome.runtime.reload() was available as usual to my extension's
popup UI.
Background pages are not (yet) deprecated, but the first line in the
documentation
recommends migrating to event pages instead, they can't possibly be
high on the Chromium team's priority list. In other words, I consider
the risk of this bug - if it is one - to have a high risk of being
categorized a 'wontfix', therefore, it looks unproductive to try
to wait out a fix.
Therefore, I have devised a workaround that I think will be
satisfactory until I have the resources to either develop
soft-restart capabilities in my extension OR migrate to event pages:
Given that:
Most of my extensions functionality is triggered via a Chrome
browserAction. Before the browser action starts to render, I can
post a message to the background page that I know will call back
immediately.
When the extension have started normally, the fix will simply be a
no-op invisible to the end-user.
Since the fix normal operation is a no-op the fix won't hurt the
extension should the Chromium team fix the bug in a future release.
"Dead" background pages will have failed to register any message
listener. If the background page doesn't respond to the safety check
message, the popup can fix the broken state by restarting the
extension.
This comes at a cost: if the popup times out waiting for the 'safety
net' message and restarts, the popup UI will be brutally closed
without warning from under the end user's feet. Not nice - but after
some consideration I have decided that I think that behaviour is far
preferable to the extension just silently stopping working like it
can do now.
Comment if you have further ideas!
Looking through the API docs I think that the answer to this is no, but is there any way to toggle support for Chrome commands from inside an extension?
The problem: When using global commands Chrome will hijack that hotkey so other applications that are listening for that key will never get it. For example, I have an extension that uses the media keys. Many desktop applications (itunes, etc.) use the media keys as hotkeys as well. When the extension commands are set to use the media keys globally, Chrome is the only application that receives those key presses.
There is a bug report here about this problem, but no work has been done on it yet.
From an extension perspective, the best solution with the current implementation would be a button inside the extension's browser action that could toggle Chrome listening for commands (which would in turn free up the keys that it is listening for). Is anything like this possible?
The best that I have come up with is a button inside the browser action to actually disable the extension (using management.setEnabled). The problem with this approach is that the user will then have to navigate to chrome://extensions to re-enable it - far from ideal.
I have been recommending to my users to change the hotkeys to something else if they are encountering this problem, but that is also not a great solution.
Any other suggestions?
At the moment I have a custom ActiveX plugin that drops down the usual yellow bar with the install button if the user doesn't have it. When they finish installing, however, I need the page to automatically refresh. Is there a way to detect that the plugin has been successfully installed that isn't constantly polling for the plugin's presence. That is to say, not doing this:
function checkForPlugin() {
try {
control = new ActiveXObject('Object.One');
//refresh
} catch (e) {
setTimeout("checkForPlugin()" ,2000);
}
}
This doesn't seem terribly professional and I'm curious if there is a better approach I could be taking. Come to think of it...I'm not exactly sure how I'd refresh there anyway, does anyone have insight on that as well? Thanks.
Update -- I have it working using the above method and even solved the refresh issue. I'm really not thrilled with this as an implementation though. It just feels wrong to leave the browser sitting there constantly polling in the background until it gets what it wants. It's not terrible I guess but I wish there was a more clean approach. Does anyone have any ideas?
You could have your control fire an event and listen for it.
I think, capturing ActiveX install finish event is a kind of misconception.
Basically web pages run in single thread. There are no asynchronous processing such as a background installing.
In a life time of a web page, you will have the already installed ActiveX control or nothing. If control = new ActiveXObject throws, never you can instantiate the ActiveX control in this life time of the page.
That is, if the ActiveX control is not installed already you need to refresh the page to use the newly installed ActiveX control. This refresh is done automatically by the IE.
While the two answers given are perfectly valid, neither solution will really work within my time constraint or implementation. I thank you both for answering but ultimately I went with as described in my question.