7

Windows 7 / Firefox Latest versions / Preferrably 64bit beta versions

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.

So far my research has brought me to: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWindowMediator 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".

I have limited experience of the firefox API. I'm executing code through userchrome.js.

Any pointer would be gladly received.

UPDATE 1 20151125 0748: I believe this is the xul - https://archive.is/NyGBS - any pointer on how to "overlay" it within userchrome.js? I can also try to enumerate windows of windowtype="Addons:Compatibility".

UPDATE 2 20151125 0748: 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.

[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]

TL;DR version with info about the problem follows.

I currently have a vbs script that:

  1. Deletes FIREFOX_RUNNING_PROFILE folder.
  2. Copies FIREFOX_BASE_PROFILE folder-> FIREFOX_RUNNING_PROFILE folder.
  3. Runs FIREFOX_RUNNING_PROFILE.

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 RUNNING_PROFILE is recreated every time.

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.

I have a few of this BASE_PROFILES, hence I would like to handle the updates programmatically.

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.

Options:

1) userchrome.js -> 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:

var strProfileFilePath=Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("ProfD", Components.interfaces.nsIFile).path;

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.

2) Autohotkey. 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.

3) One of the avenues through Autohotkey involves using the MozRepl Firefox addon behind the scenes. Library discussed here https://archive.is/73u4f, github seems out of date https://github.com/arbiter34/FF-Control. 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.

4) Selenium. 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.

5) There is also the option of writing an addon, but again, I think 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.

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:

Additional Points:

a. As a general principle, I have zero desire to update anything (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. YMMV. NEVERTHELESS I'm still forced to upgrade whenever (1) I "make a mistake" (all it takes is for one 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).

b. The arcane art of keeping your firefox profile integer across updates also involves search engines - 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.

MrR
  • 411
  • 5
  • 12
  • @Cerbrus, @"Daniel A. White", @"Shikkediel", @"dippas", @"Frederik.L" I have edited the question so that the first part is very cohesive and concise, and the reader is still free to look at the problem and thought process I've been through. Can you please un-hold or tell me what to remove? I feel there are a lot of people in this boat, and the existing questions on how to manage firefox profiles are inconclusive. – MrR Nov 23 '15 at 06:53
  • @MrM If you're looking for help with developing a Firefox add-on, I suggest adding the firefox-addon tag. Then your question will be seen by the right audience. – Rob W Nov 23 '15 at 10:23
  • @"Rob W" I structured the initial question starting from a problem statement, and trying to define my background and the options I had considered before asking the community. I was actually trying to avoid writing an addon. I can see how this would be beneficial though, as the APIs used in writing an addon are the same as those I am trying to use from userchrome.js. – MrR Nov 23 '15 at 17:36
  • Your question shows a lot of research (which is good!), but it's not easy to find what you're really looking for. How is Firefox started? How should [insert desired solution here] be activated and control Firefox? I suggest to read https://stackoverflow.com/help/how-to-ask. – Rob W Nov 23 '15 at 17:46
  • @"Rob W" "How is Firefox started? How should [insert desired solution here] be activated and control Firefox?" You are asking me to specify additional constraints - which I do not have at this time. I have specified those I have upfront - operating system and firefox version. Everything else, I am up for it, including the options I have enlisted. – MrR Nov 23 '15 at 17:47
  • @"Rob W" Furthermore, I don't think your comment refers to the **edited** version of the question - where I have restricted the initial request to a very specific subset to try and appease "too broad" claims. If it is the additional background that is confusing, I am ready to remove it and only leave the initial question. As I already commented "the first part is very cohesive and concise". If you disagree on that please be specific on the reasons and I will try to refine it further. – MrR Nov 23 '15 at 17:51
  • The question is clear to me, I already voted to re-open when I made my first comment. You need 3 more votes to get the question re-opened. Meanwhile, you could make the question easier to read/answer by trimming down the unnecessary parts of the question. And the penultimate paragraph is seemingly confusing, because the statement about not wanting to update add-ons is contrary to what you've asked in the previous paragraphs. – Rob W Nov 23 '15 at 17:57
  • **Appreciate your swift replies.** Regarding point (a) under "Additional Points". I want to explain rather clearly the circumstances forcing me to end up having to update _despite my default stance_. That is because I am open to inputs that would deal with those cases (i.e. those listed following "NEVERTHELESS I'm still forced to upgrade whenever...") and solve my problems at the very root. – MrR Nov 23 '15 at 19:20
  • 1
    This is a real cool idea you're trying to attack. I usually start by running DOM Inspector on things, but in this case firefox hasnt started up yet. So what you would do is search DXR, you start by searching localized strings maybe that you see there. Then go backwards from there. Once you find that xul file it should be easy to overlay. – Noitidart Nov 24 '15 at 05:13
  • 1
    @Noitidart - appreciate the appreciation. I think it should be in the reopen review queue. Not sure what I can do anymore to affect the status. – MrR Nov 25 '15 at 04:15
  • @Noitidart Regarding the DOM inspector - I don't think that's the only problem (firefox not having started); it rests to be seen whether the inspector works on this "internal" firefox dialogs (excuse my lack of terminology precision). For instance it doesn't work on the "view page info" dialog. Regarding DXR - I'll have to google it up, it's a new keyword for me. Regarding identifying the xul dialog - are you talking about the file in memory or in the omnia.ja superjar? – MrR Nov 25 '15 at 07:35
  • DXR is firefox nightly codebase: http://dxr.mozilla.org/ - DOM Inspector works with everything I think, get the addon Element Insepctor, then Shift + Right Click anything and it pop up in DOM Inspector :) – Noitidart Nov 25 '15 at 23:58
  • Ty, I got to the mediator code and it looked promising `Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator); winMediator.getMostRecentWindow('xxx');` Then from here enumerate the buttons and push it? Or look at this overlay you were talking about. But as I said the change in prefs.js doesn't make me suffer from this so it has become less of a priority. I reiterate that the element Inspector doesn't work on some dialogs - i.e. at least it doesn't on the "View page info" dialog. – MrR Nov 26 '15 at 09:14

0 Answers0