If an add-on changes a preference outside its own preference branch, then it should revert them back to their previous state (not necessarily the default state) on uninstalling the add-on.
I imagine, the current preferences have to be saved and then at uninstall used to revert back.
Running AddonManager.addAddonListener() seems to be an option (but running a process continuously!). Is there any other option?
In a bootstrapped addon, there is a function uninstall() {}, but how is it done in an overlay add-on?
Other useful topics on the subject (but not fully answering this question):
Firefox Addon: how to remove preferences when addon is being uninstalled?
Set preferences in the user branch and unset them on uninstall
Update
By running a process continuously I meant, running a listener/process for example for an event that may happen once a year. I have already thought of another way which could be more efficient but since that was a hypothetical situation, I don't have the anything to test it on.
Using AddonManager.addAddonListener() is the correct path to take when using an old school overlay add-on.
I'm not sure what you mean when you say but running a process continuously! the listener is just added to an array of listeners, and there is no new process running.
No, you should not run a process continually, nor have a listener on any preferences you changed. There is no reason for it. For the application that you described, you have no need to know when a preference changes. You only need to know what the preference is:
Prior to you changing it
What you changed it to
What it is at the time you uninstall
You have no need to keep track of intermediate changes. Thus, no listener.
When you uninstall, if the preference is the value to which you changed it, change it back to the value which it was prior to you changing it. If it is some value you did not set, then either the user, or another extension, changed it and you should not change it back to the value it was prior to you installing your extension (i.e. you should not undo something the user has hand set, or was set via another extension).
However, if you are an overlay extension, you should add a AddonListener with AddonManager in order to detect when your add-on has been (or will be) disabled/uninstalled. This is so you can know when you should be changing the preferences back.
Bootstrapped (restartless) extensions have their own uninstall notification.
Add-on SDK extensions also have their own way.
It would probably be a good idea to read Appendix B: Install and Uninstall Scripts.
This question has some good information: Firefox Addon: how to remove preferences when addon is being uninstalled?
Related
Now that FF has a sync feature, and assuming that there are folks who are ok with their data being stored on the cloud, does it still make sense to have a backup process using MozBackup?
More background:
I have a script that I use to take a zip of the complete profile folder, and move it from time-to-time onto my cloud backups. But, since FF Sync does all the backups (including preferences, open tabs, bookmarks, installed extensions, themes), I am not sure if I still need such a manual backup. as long as I click the "Sync now" button/menu item from time-to-time, can I rest assured that my offline backup is no longer needed?
I found out that the FF Sync does indeed sync the preferences, installed addons, etc, and all the open tabs on the first machine showed up in the "sync sidebar" on the second machine as well. BUT, the synced tabs lose a couple of important "features"
The order of the open tabs is messed up
The status of whether tab was pinned or not was also lost.
With the above, at this point, I feel I still need to continue with a full-backup of the profile folder.
I have an App Store app in which the free version is not scriptable, but the premium version is. AppleScript support is one of the key differences. I know the App Store reviewers are pushing more and more towards free + in-app-purchase, which will help declutter the App Store. Fine, I'll play ball.
Now I need to do something programmatically that I've always just worked into the build.
Is there a way to disable AppleScript if my OSAScriptingDefinition and NSAppleScriptEnabled are set in my Info.plist? This would still allow people to open the dictionary, and maybe they'd like what they see and consider activating the upgrade. Or,
Is there a way to enable AppleScript after the fact? Obviously with code-signing, I can't do things like modify Info.plist, or add my SDEF to the bundle later. But maybe if the SDEF were in a non-standard location, I could load it from the bundle and tell the system about it manually.
Does the SDEF have to live in my bundle? If not, I'm not sure how to point to the user's Application Support directory in the sandbox. I've also considered xinclude an SDEF I can install after the fact, but again, the SDEF and plist require actual directory paths and not functions.
I've tried a couple of things such as attempting to set NSScriptSuiteRegistry's singleton to nil, to no effect.
Because OSAScriptingDefinition and NSAppleScriptEnabled enable "automatic" support, surely there must be a manual way to make them to effect if not in the plist, and hopefully with a public API.
Any ideas here? Thanks!
A few points, for orientation:
All AppleScript commands are subclasses of NSScriptCommand
All AppleScript objects are represented by subclasses of
NSScriptObjectSpecifier
The scriptability of an app is controlled by its shared instance of NSScriptSuiteRegistry
This gives you a few options. You could try, for instance, overriding NSScriptSuiteRegistry setSharedScriptSuiteRegistry: and setting it to nil for the free version. You could also write a category on NSScriptCommand and/or NSScriptObjectSpecifier that does a version check. That would give you fine-grained control: you could call it from any methods that handle a script command or returns a script object, and decide on the fly which you want to allow and which you want to block; maybe even pop up a 'Pay for Full AppleScript Access' dialog.
CocoaScripting is a black box and not very adaptable. Simplest (kludgy) solution would be to wait until CS has installed its Apple event handlers then call -[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:] to replace those with a dummy handler that always sends back a "requires in-app purchase" error. (Don’t replace the standard open, quit, etc. handlers obviously.)
I have made a program to change the mouse sensivity in the same way as you can do it with the Control Panel.
The changes are made in the registry, the keys at HKEY_CURRENT_USER\Control Panel\Mouse and they are in fact done (I have checked them from regedit.exe) but the mouse works as if this changes are not made. In other words, the changes do not take any effect, they only do if you use the control panel. Why do they not take effect?
Windows registry isn't something that is refreshed all the time. The changes you made will be applied after the current user (that's why it's HKEY_CURRENT_USER) logs in again, or as you said after using control panel, which will read the registry. I don't know, what language your program is written in, but you should check out this link: "https://msdn.microsoft.com/en-us/library/ms724947.aspx"
In general, tweaking registry settings directly is unsupported, especially when there's an API to tweak the setting. In this case, the API is SystemParametersInfo. In particular, you need to use the SPI_SETMOUSESPEED as the argument for the uiAction parameter.
In other words, the changes do not take any effect, they only do if you use the control panel. Why do they not take effect?
Because there's often a little more to it than setting the value in the registry. Often there is a notification that must be sent after changing the value in order to tell the all the other software on the machine to drop any cached values and replace them with the new value that's now in the registry. In many cases, the notification will be in the form of a broadcast message.
In the case of mouse driver settings, you probably need to use the SPIF_UPDATEINIFILE argument for the fWinIni parameter. You might also need to OR it with SPIF_SENDCHANGE to broadcast a WM_SETTINGCHANGE message, but I'm not sure about that.
I want to use the VIM keyboard commands to edit a Google Document. Preferably I'd like to use my .vimrc file and have changes I make reflected in real time (or at least on save). I want to do this for a technical coding interview.
So far I've tried using GoogleCL which only pushes/receives changes on quitting VIM (which is too slow). And I've tried the Vimium Chrome plugin but that seems to be just for navigation not text editing. I however may be overlooking a feature of one of these.
I'm using OSX and Chrome, Safari or Firefox.
You can:
sync your google docs then edit normally
use vim-anywhere plugin
use GoogleCL inside au FileWrite
use some library to quickly create your own thing, for instance google-drive-ruby (see short example on its page).
To collaborate and see changes real time you could for instance use ruby library to upload/dowload changes every now and then. If you always overwrite your original file even as you edit it, you can diff external changes to see what the other users did.
I have written an application suite on Windows which amongst other things installs a Firefox add-on which once run modifies the Firefox network preferences by interfacing with nsIPrefService.
The extension itself resides in a folder under Program Files along with other parts of the application which work together with each other.
Since the application consists of a number of components, the correct way to uninstall it is via the Control Panel or via an uninstall shortcut I provide for the users.
I have no control over whether Firefox will be running or not when the user chooses to uninstall (possibly I could try to detect if it's running in the uninstaller and request the user close it to continue).
Since the purposes of the uninstaller is to remove all traces of the program from the end-users system i.e:
all the files under the Program Files folder, including the extension components
remove the add-on from Firefox (by removing the registry key under HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions, causing the add-on to unregister on next Firefox restart)
remove application specific registry keys
Then after uninstall there isn't any of my code left on the users system capable of restoring the network preferences to what they were before the component was installed. This results in end-users not being able to browse the web and being very frustrated!
The only way I can figure out how to do this at the moment is to have my component write to the window's registry the location of the users profile folder - which I can do with my add-on:
Components.classes["#mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties).get("ProfD",
Components.interfaces.nsIFile).path
And then have my uninstaller modify the prefs.js file in that location directly. But this will only work if I can guarantee Firefox isn't running during uninstall (since prefs.js is re-written on FF close)
To me this is not an elegant solution:
It seems not to be future proof since it is dependent on the format and symbols used prefs.js which may change in future FF releases.
Firefox has a nasty habbit of not always closing properlly (sometimes other installed add-ons prevent it from completely unloading from memory. This would break my uninstaller).
This wouldn't work (without elaborate modification) if the user has multiple FF profiles setup all using my add-on.
Is there a better or "standard" way to achieve this simple task?
Did you try to package defaults files (defaults/preferences/myprefs.js) in your extension? I didn't check if it works for overriding Firefox-wide defaults, but it should.
Can't the uninstaller "insist" that Firefox be closed? eg,
check if FireFox is open
if open, inform user "FF must be closed, or cancel uninstall" ok/cancel
loop
I've had several installers do this to me. Not unistallers, though, that I can remember.
Also, this doesn't future-proof the solution, nor deal with profiles.