I'm writing a Firefox extension which takes a custom switch from the command line and sets a variable inside my cmdline.js in the components directory, we'll call the variable switchDetected which is a boolean. Now based upon this variable I want actions to be carried out in my overlay.js file in the chrome/content directory.
The problem I'm having is I can't seem to be able to access the variable switchDetected that is declared in components/cmdline.js from within chrome/contents/overlay.js.
I've tried numerous ways of doing this but nothing seems to work. So I'm just wondering if anyone knows how this can be achieved.
A script loaded in an overlay runs in the context of the browser window - its global variables are stored as properties of the window object corresponding with the browser. If you open a second browser window the same script will load a second time and run in the context of the new browser window - it will have different global variables. The scripts containing XPCOM components on the other hand only load once and they have their independent context that isn't bound to a window. So their global variables cannot be accessed from a browser window directly, just like two browser windows cannot access each others global variables directly.
Instead the browser window should communicate with the XPCOM component using the usual approach: get a component instance and call its method. If you don't want to define your own interface for that (you probably don't) you can use a trick, something like this:
CommandLineHandler.prototype = {
handle: function(commandLine) {...},
get helpInfo() {...},
isSwitchDetected: function()
{
return switchDetected;
},
get wrappedJSObject()
{
return this;
},
QueryInterface: XPCOMUtils.generateQI(["nsICommandLineHandler"]);
};
The wrappedJSObject property makes sure that your component can be unwrapped - all its methods and properties will become accessible then and not just the ones defined in the interface. So your overlay script needs to do the following:
var cmdLineHandler = Components.classes["#myself.com/my-command-line-handler;1"]
.getService()
.wrappedJSObject;
var switchDetected = cmdLineHandler.isSwitchDetected();
Related
If you are using FireFox, navigator has a property oscpu.
The property can be easily changed by appending general.oscpu.override value in about:config.
But, this option is present only in FireFox and does not exist in any other browser. This allows a 100% certainty to determine the type of browser.
Conventional means can not remove it. Whatever happened that ( oscpu in navigator) would return false.
All this does not work:
delete navigator.oscpu;
'oscpu' in navigator; // true
navigator.oscpu = null;
'serviceWorker' in navigator; // true
navigator.oscpu === null; // false
Object.defineProperty(navigator, "oscpu", {
configurable: true,
value: undefined
});
'oscpu' in navigator; // true
navigator.oscpu === undefined; // true
Are there ways to remove this property from navigator? And indeed any other parameter. I am writing a Firefox Add-on SDK extension.
There are potential side effects of doing what you are wanting to accomplish. It would be helpful to know what your goals are in order to determine a good way to accomplish what you desire.
However, for what you have specifically requested, removing navigator.oscpu in the current scope, the following works:
//This specific code relies on navigator referring to the object which you want to
// modify. In an Add-on SDK extension, if navigator is _actually_ the object you need
// to modify to accomplish what you desire will depend on the scope you are in and
// what object you have set the variable navigator to refer to.
delete navigator.__proto__.oscpu;
console.log(navigator.oscpu); // undefined
'oscpu' in navigator // false
Note that you will need to do this within every context/scope in which you desire for it to have effect. In general, this means that you will need to inject a content script into every page and frame in which you wish this to be the case. It also means that you should take care to only do it in the context/scopes in which you are wanting it to be seen by whatever JavaScript you are attempting to spoof (i.e. within the scope of page scripts, not in the scope of code running with Chrome privileges.).
I'm creating a Firefox add-on with the Firefox Add-on SDK. This add-on does two things:
Inject a content script into every page with sdk/page-mod.
Add a context menu item using sdk/context-menu.
I want that when user clicks the context menu item, the add-on will call functions in the content script which was loaded by PageMod().
Unless your page-mod script is doing other things, it sounds like it might be more appropriate to load it using the context-menu contentScript or contentScriptFile properties. Alternately, load the portions of it that are needed by the context menu using this methodology. How best to split the script you are using depends on what you are actually doing. Without more information from you it is difficult to provide specific recommendations.
Communicating between content scripts loaded at different times or by different methods:
There is no method of directly doing what you desire. Content scripts that are not loaded at the same time by the same methodology are loaded into different contexts. They are unable to directly call functions between them. Multiple content scripts which are loaded at the same time and the same methodology share the same context/scope and can directly call functions between them.
However, you can communicate between content scripts. If they are not loaded into the same page, then you will need to communicate from one content script to another by using your main add-on script to first receive a message from one content script. Then, your main add-on script will need to send a second message (potentially containing exactly the same data) to the second content script. In other words, your main add-on code would need to relay the message between the two content scripts.
For content scripts that are loaded into the same page via different methods (e.g. one with page-mod and another as a context menu item – the situation in which you are interested), you can communicate directly between them using the DOM postMessage() API or a CustomEvent. Either can be used to send whatever JSON serializable data you desire between the two scripts. The DOM postMessage() API provides for more security, but is a bit more complex. With it you must also filter out any other "message" events that are sent on it by random code. It should probably be used if you are going to have code in a released add-on execute functions based on the content of the messages. This is a security issue which will depend on exactly what you are doing with the messages.
Example:
The following code will load a page-mod script into every page that matches "*.mozilla.org". It also creates a context menu item in those same pages which is displayed on links. Clicking on the context menu item will send an event from the context-menu content script with data containing the URL for which the context menu was displayed. The custom event will be received by the page-mod script. The page-mod script will then issue an alert with the URL for the link.
var pageMod = require("sdk/page-mod");
pageMod.PageMod({
include: "*.mozilla.org",
contentScript: 'function contextMenuAlert(href) {'
+ ' window.alert("The context menu click on a link with URL:\\n" + href);'
+ '};'
+ 'window.addEventListener("myAddonId-contextMenu-clicked",'
+ ' function(event){contextMenuAlert(event.detail);});'
});
//Context menu
let cm = require("sdk/context-menu");
cm.Item({
label: "Alert link URL",
context: [
cm.URLContext(["*.mozilla.org"]),
cm.SelectorContext("a[href]")
],
contentScript: 'self.on("click", function (node, data) {'
+ ' var event = new CustomEvent("myAddonId-contextMenu-clicked",'
+ ' {detail:node.href});'
+ ' window.dispatchEvent(event);'
+ '});'
});
The above code produces a context menu that looks like:
When clicked on, the page-mod added content script initiates the following alert:
Using the message sent to choose from multiple different functions:
The information passed through the event can be expanded to allow multiple different functions to be called depending on the content. One method of doing this is to send an object as the message. One property of the object can be the function desired and another can be data to use in that function. My answers to the following questions contain examples of doing this:
Add menu item created with the sdk/context-menu API to the top of the context menu: This answer has code which uses the same passed message to indicate that either a click was made on a context menu item and pass the URL on which the context menu item was clicked, or to tell the main script that the context menu is about to be displayed so it can be modified.
How to console.log from ChromeWorker (alternative to dump): This answer shows sending a message that will result in a call to one of a variety of different functions and pass data to the function which was called. It was implemented as a way of using console methods from a worker with just console.log("message"). I'd code this one a bit differently were I doing it today, but it works and demonstrates the concept.
Because the documentation on MDN (here and here) was not very clear on content script to content script communication, I have updated the pages I found on which it was discussed. I have also added the above code as an example.
In main.js I am opening a tab and attaching a script with page-mod. The html file that is being opened it has a bunch of regular includes.
Sort of have two issues.
The script from page mod does not get attached until after those other scripts are loaded, and also
the regular scripts can't access variables defined in the script that is attached with page mod.
You have to send messages.
Directly
In your page-mod, send a message:
page-mod.js
window.postMessage(projectUniqueId + '|' + message, domain);
If your page needs to work with all domains (being a plug-in), you might need '*' as a domain.
tab-attach.js
window.addEventListener('message',function(event){
var words = event.data.split('|');
if (words[0] == projectUniqueId){
handle(words[1]);
}
});
The script from page mod does not get attached until after those other scripts are loaded,
Specifying contentScriptWhen: 'ready' in the page-mod constructor should "[l]oad content scripts once DOM content has been loaded, corresponding to the DOMContentLoaded event"
the regular scripts can't access variables defined in the script that is attached with page mod.
Have a look at Expose objects to page scripts. You need to use
var contentScriptObject = {"greeting" : "hello from add-on"};
unsafeWindow.clonedContentScriptObject = cloneInto(contentScriptObject, unsafeWindow);
in the content script to make the object accessible.
I have a Firefox overlay extension with a tree in a sidebar.
How can I keep the tree state synchronized in several windows?
For example in first window added new item in tree, how update tree in other windows?
If somebody can show minimal code for it (with use code modules, observers, broadcasters or something else), please help.
I read similar question, but it did not help:
Firefox extension - Share common state between two or more windows
The answer in the question you reference is good, but short on explanation. You should read the references to which it links. I have duplicated those links here.
One way to keep state information outside of a window context is to use JavaScript code modules (JSM). The section Sharing objects using code modules talks briefly about doing this. Once you have set up your JSM to share the data, it is merely a matter of informing each window that a change has been made and it should update the displayed state. This is easily accomplished by using an event which you define. All of the sidebars listen for a particular event in their window. Then there is one function in the JSM which runs through all the windows signalling them that they need to update.
The code to signal could look something like:
Components.utils.import("resource://gre/modules/Services.jsm");
function forEachOpenWindow(todo) {
// Apply a function to all open browser windows
var windows = Services.wm.getEnumerator("navigator:browser");
while (windows.hasMoreElements()) {
todo(windows.getNext().QueryInterface(Components.interfaces.nsIDOMWindow));
}
}
function signalUpdateNeeded(window){
let event = window.document.createEvent("Event");
event.initEvent("myExtensionName-UpdateAvailable",false,false);
window.dispatchEvent(event);
}
function sendUpdateAvailableToAllWindows(){
forEachOpenWindow(signalUpdateNeeded);
}
Then in the code for the sidebar:
//This imports your JSM, it does not need the .jsm extension, you can use
// whatever extension you want.
Components.utils.import("chrome://MyExtension/content/moduleName.jsm");
window.addEventListener("myExtensionName-UpdateAvailable",
updateDataFromModule, false);
//Instead you may need the following (or another way to get to the
// top window). What is actually needed will depend on the context in
// which your sidebar code is running. You should see below for code to
// access the main browser window from within a sidebar.
//window.top.addEventListener("myExtensionName-UpdateAvailable",
// updateDataFromModule, false);
function updateDataFromModule(){
//Whatever it is you need to do here.
mylocalVariable = myExtensionModule.dataStructure.whatever;
}
Refactoring the first code section above so that it looks like it is in a module that uses one variable to reduce namespace clutter. The code for the module could be something like:
var EXPORTED_SYMBOLS = [ "myExtensionModule" ];
Components.utils.import("resource://gre/modules/Services.jsm");
var myExtensionModule = {
dataStructure: {
whatever: true,
you: 1,
want: ["here.", "It", "is", "your", "data."]
};
forEachOpenWindow: function(todo){
// Apply a function to all open browser windows
var windows = Services.wm.getEnumerator("navigator:browser");
while (windows.hasMoreElements()) {
todo(windows.getNext()
.QueryInterface(Components.interfaces.nsIDOMWindow));
}
},
signalUpdateNeeded: function(window){
let event = window.document.createEvent("Event");
event.initEvent("myExtensionName-UpdateAvailable",false,false);
window.dispatchEvent(event);
},
sendUpdateAvailableToAllWindows: function(){
this.forEachOpenWindow(this.signalUpdateNeeded);
}
}
I have not actually tested this, so there may be some errors.
Having either your sidebar code access the main browser window, or the JSM code find which sidebar your code is in (in order to send or listen fro events) may be a bit more complicated than you think. You should see Working with windows in chrome code. Specifically, Accessing the elements of the top-level document from a child window. That section provides the following code to access the main browser window from within a sidebar:
var mainWindow = window
.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
.getInterface(Components.interfaces.nsIWebNavigation)
.QueryInterface(Components.interfaces.nsIDocShellTreeItem)
.rootTreeItem
.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
.getInterface(Components.interfaces.nsIDOMWindow);
An alternative is for your JSM to keep a reference to an object in the data structure on which all of the sidebars place listeners. This could be an object which it creates. If you do use this method and choose to use a window, then you need to make sure that handle releasing the reference if the window is closed. If you don't you could end up with a memory leak.
I'm converting a standard browser based app that's working fine to a chrome-app.
Once the page loads up, it has already hit an error - Uncaught TypeError: Cannot call method 'appendChild' of null. This occurs after several hundred lines of JS have done their job but its the first time the code makes a reference to the document object, specifically document.getElementById('mainDiv').appendChild(...).
I can clearly see the div with the id="mainDiv" in the debuggers elements tab. Yet, document.getElementById('mainDiv') must be returning a null. Any attempt at putting in breakpoints fails as they are ignored. I've added them to the line that fails as well as to lines that lead up to it and breakpoints are never triggered. I've read some of the threads on SO and I'm certain the breakpoints issue is just a bug in the debugger, but not recognizing an id when I can clearly see it and the code when run in the browser works fine leaves me wondering what's going on. Is document in the browser different from document in the app version?
Any ideas?
If I choose "inspect background page", the breakpoints work but it still fails but in a different way. The elements tab does NOT show my html page, but the pseudo generated background one and I can't get the debugger to show my page at all.
Any enlightenment would be appreciated. I've searched and read what I could find, but much of the docs are clearly out of date.
You seem to be accessing the document object of the background page, instead of that of your POS.html file.
Try this:
chrome.app.window.create('POS.html',{
'bounds': {
'width': screen.availWidth,
'height': screen.availHeight
}
}, function(appWin) {
var pageWindow = appWin.contentWindow;
var pageDocument = pageWindow.document;
pageWindow.addEventListener('load',function() {
// now use
pageDocument.getElementById('yourid');
// instead of
document.getElementById('yourid');
},false);
});
Also to inspect elements in your page right-click anywhere in the app window and select Inspect Element (this works only when the app was loaded as an 'unpacked extension')
Alternatively you can navigate to chrome://extensions and click the page link next to your app entry.
As lostsource mentioned, you're probably accessing the wrong DOM's document. You should think about the javascript in your app running in different global contexts, one for each page. There is (at a minimum) a page for the background page, and a page for each window.
Each of these pages runs in its own global context. This means global variables like document and window are different.
In the background page will be scripts which you load via the background manifest tag. When you open a window, it can also load its own script via script tags (make sure you do not use inline or block script tags, but use script src="foo.js". See http://developer.chrome.com/apps/contentSecurityPolicy.html).
The code that runs in the callback to chrome.app.window.create runs in the background page's context, so its document variable is for the background page's DOM, which is usually empty. Instead you can make it refer to the window's DOM using win.contentWindow as lostsource suggested, or add a page.js file with the script in it, and include it from the page via a script src='page.js' tag.
Is your call occurring after the load event, e.g. the JS called in a function set on window.onload?