title: Programmatically update firefox profiles
body: <p>Windows 7 / Firefox Latest versions / Preferrably 64bit beta versions</p>
  
  <p>Whenever a Firefox Profile is updated, the user is presented with a dialog to check for updates to the addons. I would like to interact with tha dialog programmatically so that it is automatically ok-ed.</p>
  
  <p>So far my research has brought me to:
  <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWindowMediator" rel="nofollow">https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWindowMediator</a>
  For that I need a windowtype to enumerate. The window type correspons to the attribute in the XUL definitions. On my installation of Firefox, these seem to be compressed inside "c:\Program Files\Mozilla Firefox\browser\omni.ja\chrome\browser\content\browser".</p>
  
  <p>I have limited experience of the firefox API. I'm executing code through userchrome.js.</p>
  
  <p>Any pointer would be gladly received.</p>
  
  <p><strong>UPDATE 1 20151125 0748</strong>: I believe this is the xul - <a href="https://archive.is/NyGBS" rel="nofollow">https://archive.is/NyGBS</a> - any pointer on how to "overlay" it within userchrome.js? I can also try to enumerate windows of windowtype="Addons:Compatibility".</p>
  
  <p><strong>UPDATE 2 20151125 0748</strong>: It looks like the extensions update dialog is not showed if I have:
      user_pref("xpinstall.signatures.required", false);
  Which marks the addon as unsafe but allows you to continue using it.</p>
  
  <p>[Which solves my immediate problem, but I am sure I will have this requirement at another point for another dialog, so would still like to get to the bottom of this]</p>
  
  <hr>
  
  <p>TL;DR version with info about the problem follows.</p>
  
  <p>I currently have a vbs script that:</p>
  
  <ol>
  <li>Deletes FIREFOX_RUNNING_PROFILE folder.<br></li>
  <li>Copies FIREFOX_BASE_PROFILE folder-> FIREFOX_RUNNING_PROFILE folder.<br></li>
  <li>Runs FIREFOX_RUNNING_PROFILE.</li>
  </ol>
  
  <p>Whenever a firefox update takes place, a number of dialogs need to be confirmed by the user in relation to checking/updating extensions.
  The outcome of this process will not stick to the profile as obviously given my setup the <code>RUNNING_PROFILE</code> is recreated every time.</p>
  
  <p>Note that for the purposes of this discussion it doesn't matter whether the udpate is performed automatically. I have the ability to rewrite the prefs.js so i can change behaviour dynamically just by doing that and restarting the browser externally - it's vbs right now but I'm ready to move over to something else if I hit some limitations with process / window management, or I want this to be portable (e.g. python). Note these are not dealbreakers right now and I'd be happy for a reasaonbly sleek windows-only solution.</p>
  
  <p>I have a few of this <code>BASE_PROFILES</code>, hence I would like to handle the updates programmatically.</p>
  
  <p>I have not found a way of achieving this that does not involve interacting with the dialogs firefox presents in the GUI. And I have noticed that the dialogs popping up after each update can change.</p>
  
  <p><strong>Options</strong>:</p>
  
  <p>1) <strong>userchrome.js</strong> -> I already use this to manage some imacros autostart features, including grabbing the profile name from Components.Interfaces. I am reporting snippets below to help the reader understand what is the most sophisticated snippet I've written against the Mozilla xpcom components:<br></p>
  
  <pre><code>var strProfileFilePath=Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("ProfD", Components.interfaces.nsIFile).path;
  </code></pre>
  
  <p>I have had a look at the documentation and it looks rather impressive. It feels like it will let me do pretty much everything, so my next move here would be to undersrtand how to enumerate dialogs and somehow select the right one based on some properties, then push the "ok" button. I think that's pretty much all I need to do. <br></p>
  
  <p>2) <strong>Autohotkey</strong>. I can try and send keys to the firefox window (not sure about the exact dialog inside the window). The dialogs normally have shortcuts that would respond to those to this keysends (nice theory). In autohotkey I can also "position-click", although it is less desirable for obvious reasons.</p>
  
  <p>3) One of the avenues through Autohotkey involves using the <strong>MozRepl</strong> Firefox addon behind the scenes. Library discussed here <a href="https://archive.is/73u4f" rel="nofollow">https://archive.is/73u4f</a>, github seems out of date <a href="https://github.com/arbiter34/FF-Control" rel="nofollow">https://github.com/arbiter34/FF-Control</a>. I could then use mozrepl directly, no need for Autohotkey. I would rather code in python, java, or even javascript, powershell, vbs than autohotkey. Ar a first look it looks like it would give me the same power that userchrome.js currently offers.</p>
  
  <p>4) <strong>Selenium</strong>. There are some profile manipulation capabilities I could exploit - although Selenium was not really designed to interact with Firefox own's dialogs, and I don't see an API to automate that. Rather one would synthesise a profile on the fly, installing on top all the required extensions from a known superprofile (that would contain a superset of all the extensions to be used), and applying whatever mods to prefs.js also dynamically. This sounds a bit ugly for my original requirements but experience has told me that ugly is still better than manual.</p>
  
  <p>5) There is also the option of writing an <strong>addon</strong>, but again, I <em>think</em> I'ld be interacting with the same interfaces that I can get in userchrome.js (actually I believe userchrome.js is even better as it seems to have unfettered access to the core components, which is exactly what I sense I might need for my case). I would rather avoid having to write an addon, although I might be lost for words trying to explain why exactly.
  I appreciate I have not "fully" investigated further, but I am at a point now where I need to elicit the opinion of the community before I start spending substantial time on either of these.</p>
  
  <p>The below isn't strictly required to address the question above, but I feel it might be useful to share this as there must be a few others undergoing the same predicament:</p>
  
  <p><strong>Additional Points:</strong></p>
  
  <p>a. As a general principle, <strong>I have zero desire to update anything</strong> (firefox.exe, addons, language packs, plugins and what not) (plugins are actually completely disabled). I am ok with the way the system works, and I don't want to change it one millimitre. Yes, NOTHING, not even the security updates. This is because of the particular circumstances of my app, my particular estimation of the particular risks I'm taking, and my general aversion to risk. <strong>YMMV</strong>. NEVERTHELESS I'm still forced to upgrade whenever (1) I "make a mistake" (all it takes is for <em>one</em> profile to have the update settings wrong for the exe to be updated for all the profiles on the machine - doh! there's only one exe); (2) Firefox is crashing too much / unusable (happened twice); (3) I need functionality offered by the upgrade (hasn't happened); I would also like to reserve the option for the "very critical security updates" (sigh! sometimes even I can bow).</p>
  
  <p>b. The arcane art of keeping your firefox profile integer across updates also involves <strong>search engines</strong> - it doesn't matter if I say I don't want to update them, whenever there's a firefox.exe update I will get the new standard fluff installed in the program folder. I currently have a way of resetting that by (1) emptying the firefox program subfolder containing the xml files (in %programfiles%\Mozilla...), and (2) deleting search-metadata.json and the searchplugins folder (in the profile folder), then copying them over from a baseline afresh. It all feels very greasy. I have yet to try this on the 64bit version I'm running right now as this is a minor issue and I would rather not introduce more entropy. The firefox search engines mechanism might have changed in the meantime.</p>