Currently, electron 5.0 removed the ability to use nativeWindowOpen with nodeIntegration, so it's impossible to use ReactDOM.createPortal on the document.body returned by window.open. They didn't put any workaround, and I've tried everything found in other answers, like:
IPC back the DOM node to the new remote.BrowserWindow, it doesn't send back a valid DOM node to attach to
webContents.executeJavascript, with either (function(){ return window })() document or body, makes the process hang
I just don't seem to be able to do the equivalent using BrowserWindow:
// this is what works in Electron 4 with a warning see https://github.com/electron/electron/pull/15193
const container = window.open("about:blank", "someuniqueid"); // window = current main window
const stylesheet = document.createElement('link');
stylesheet.rel = 'stylesheet';
stylesheet.href = document.querySelector('link').href; // document = current main window
container.document.body.appendChild(stylesheet);
// [... edited for brevity]
return createPortal(
props.children(container), // children = render props, pass the window to the children
container.document.body
)
nothing is able to return a valid DOM node from the created window. require('electron') also doesn't work for obvious reasons (nodeIntegration is always disabled)
Related
I have a simple SVG loaded inside a object tag like the code below. On Safari, the load event is fired just once, when I load the first time the page after opening the browser. All the other times it doesn't. I'm using the load event to initialize some animations with GSAP, so I need to know when the SVG is fully loaded before being able to select the DOM nodes. A quick workaround that seems to work is by using setTimeout instead of attaching to the event, but it seems a bit akward as slower networks could not have load the object in the specified amount of time. I know this event is not really standardized, but I don't think I'm the first person that faced this problem. How would you solve it?
var myElement = document.getElementById('my-element').getElementsByTagName('object')[0];
myElement.addEventListener('load', function () {
var svgDocument = this.contentDocument;
var myNode = svgDocument.getElementById('my-node');
...
}
It sounds more like the problem is that, when the data is cached, the load event fires before you attached the handler.
What you can try is to reset the data attribute once you attached the event :
object.addEventListener('load', onload_handler);
// reset the data attribte so the load event fires again if it was cached
object.data = object.data;
I also ran into this problem while developing an Electron application. In my workflow I edit index.html and renderer.js in VSCode, and hit <Ctrl>+R to see the changes. I only restart the debugger to capture changes made to the main.js file.
I want to load an SVG that I can then manipulate from my application. Because the SVG is large I prefer to keep it in an external file that gets loaded from disk. To accomplish this, the HTML file index.html contains this declaration:
<object id="svgObj" type="image/svg+xml" data="images/file.svg"></object>
The application logic in renderer.js contains:
let svgDOM // global to access SVG DOM from other functions
const svgObj = document.getElementById('svgObj')
svgObj.onload = function () {
svgDOM = this.contentDocument
mySvgReady(this)
}
The problem is non-obvious because it appears intermittent: When the debugger/application first starts this works fine. But when reloading the application via <Ctrl>+R, the .contentDocument property is null.
After much investigation and hair-pulling, a few long-form notes about this include:
Using svgObj.addEventListener ('load', function() {...}) instead of
svgObj.onload makes no difference. Using addEventListener
is better because attempting to set another handler via 'onload'
will replace the current handler. Contrary to other Node.js
applications, you do not need to removeEventListener when the element
is removed from the DOM. Old versions of IE (pre-11) had problems but
this should now be considered safe (and doesn't apply to Electron anyway).
Usage of this.contentDocument is preferred. There is a nicer-looking
getSVGDocument() method that works, but this appears to be for backwards
compatibility with old Adobe tools, perhaps Flash. The DOM returned is the same.
The SVG DOM appears to be permanently cached once loaded as described by #Kaiido, except that I believe the event never fires. What's more, in Node.js, the SVG DOM remains cached in the same svgDOM variable it was loaded into. I don't understand this at all. My intuition suggests that the require('renderer.js') code in index.html has cached this in the module system somewhere, but changes to renderer.js do take effect so this can't be the whole answer.
Regardless, here is an alternate approach to capturing the SVG DOM in Electron's render process that is working for me:
let svgDOM // global to access from other functions
const svgObj = document.getElementById('svgObj')
svgObj.onload = function () {
if (svgDOM) return mySvgReady(this) // Done: it already loaded, somehow
if (!this.contentDocument) { // Event fired before DOM loaded
const oldDataUri = svgObj.data // Save the original "data" attribute
svgObj.data = '' // Force it to a different "data" value
// setImmediate() is too quick and this handler can get called many
// times as the data value bounces between '' and the actual SVG data.
// 50ms was chosen and seemed to work, and no other values were tested.
setTimeout (x => svgObj.data = oldDataUri, 50)
return;
}
svgDOM = this.contentDocument
mySvgReady(this)
}
Next, I was very disappointed to learn that the CSS rules loaded by index.html can't access the elements within the SVG DOM. There are a number of ways to inject the stylesheet into the SVG DOM programmatically, but I ended up changing my index.html to this format:
<svg id="svgObj" class="svgLoader" src="images/file.svg"></svg>
I then added this code to my DOM setup code in renderer.js to load the SVG directly into the document. If you are using a compressed SVG format I expect you will need to do the decompression yourself.
const fs = require ('fs') // This is Electron/Node. Browsers need XHR, etc.
document.addEventListener('DOMContentLoaded', function() {
...
document.querySelectorAll ('svg.svgLoader').forEach (el => {
const src = el.getAttribute ('src')
if (!src) throw "SVGLoader Element missing src"
const svgSrc = fs.readFileSync (src)
el.innerHTML = svgSrc
})
...
})
I don't necessarily love it, but this is the solution I'm going with because I can now change classes on the SVG object and my CSS rules apply to the elements within the SVG. For example, these rules from index.css can now be used to declaritively alter which parts of the SVG are displayed:
...
#svgObj.cssClassBad #groupBad,
#svgObj.cssClassGood #groupGood {
visibility: visible;
}
...
I have a simple SVG loaded inside a object tag like the code below. On Safari, the load event is fired just once, when I load the first time the page after opening the browser. All the other times it doesn't. I'm using the load event to initialize some animations with GSAP, so I need to know when the SVG is fully loaded before being able to select the DOM nodes. A quick workaround that seems to work is by using setTimeout instead of attaching to the event, but it seems a bit akward as slower networks could not have load the object in the specified amount of time. I know this event is not really standardized, but I don't think I'm the first person that faced this problem. How would you solve it?
var myElement = document.getElementById('my-element').getElementsByTagName('object')[0];
myElement.addEventListener('load', function () {
var svgDocument = this.contentDocument;
var myNode = svgDocument.getElementById('my-node');
...
}
It sounds more like the problem is that, when the data is cached, the load event fires before you attached the handler.
What you can try is to reset the data attribute once you attached the event :
object.addEventListener('load', onload_handler);
// reset the data attribte so the load event fires again if it was cached
object.data = object.data;
I also ran into this problem while developing an Electron application. In my workflow I edit index.html and renderer.js in VSCode, and hit <Ctrl>+R to see the changes. I only restart the debugger to capture changes made to the main.js file.
I want to load an SVG that I can then manipulate from my application. Because the SVG is large I prefer to keep it in an external file that gets loaded from disk. To accomplish this, the HTML file index.html contains this declaration:
<object id="svgObj" type="image/svg+xml" data="images/file.svg"></object>
The application logic in renderer.js contains:
let svgDOM // global to access SVG DOM from other functions
const svgObj = document.getElementById('svgObj')
svgObj.onload = function () {
svgDOM = this.contentDocument
mySvgReady(this)
}
The problem is non-obvious because it appears intermittent: When the debugger/application first starts this works fine. But when reloading the application via <Ctrl>+R, the .contentDocument property is null.
After much investigation and hair-pulling, a few long-form notes about this include:
Using svgObj.addEventListener ('load', function() {...}) instead of
svgObj.onload makes no difference. Using addEventListener
is better because attempting to set another handler via 'onload'
will replace the current handler. Contrary to other Node.js
applications, you do not need to removeEventListener when the element
is removed from the DOM. Old versions of IE (pre-11) had problems but
this should now be considered safe (and doesn't apply to Electron anyway).
Usage of this.contentDocument is preferred. There is a nicer-looking
getSVGDocument() method that works, but this appears to be for backwards
compatibility with old Adobe tools, perhaps Flash. The DOM returned is the same.
The SVG DOM appears to be permanently cached once loaded as described by #Kaiido, except that I believe the event never fires. What's more, in Node.js, the SVG DOM remains cached in the same svgDOM variable it was loaded into. I don't understand this at all. My intuition suggests that the require('renderer.js') code in index.html has cached this in the module system somewhere, but changes to renderer.js do take effect so this can't be the whole answer.
Regardless, here is an alternate approach to capturing the SVG DOM in Electron's render process that is working for me:
let svgDOM // global to access from other functions
const svgObj = document.getElementById('svgObj')
svgObj.onload = function () {
if (svgDOM) return mySvgReady(this) // Done: it already loaded, somehow
if (!this.contentDocument) { // Event fired before DOM loaded
const oldDataUri = svgObj.data // Save the original "data" attribute
svgObj.data = '' // Force it to a different "data" value
// setImmediate() is too quick and this handler can get called many
// times as the data value bounces between '' and the actual SVG data.
// 50ms was chosen and seemed to work, and no other values were tested.
setTimeout (x => svgObj.data = oldDataUri, 50)
return;
}
svgDOM = this.contentDocument
mySvgReady(this)
}
Next, I was very disappointed to learn that the CSS rules loaded by index.html can't access the elements within the SVG DOM. There are a number of ways to inject the stylesheet into the SVG DOM programmatically, but I ended up changing my index.html to this format:
<svg id="svgObj" class="svgLoader" src="images/file.svg"></svg>
I then added this code to my DOM setup code in renderer.js to load the SVG directly into the document. If you are using a compressed SVG format I expect you will need to do the decompression yourself.
const fs = require ('fs') // This is Electron/Node. Browsers need XHR, etc.
document.addEventListener('DOMContentLoaded', function() {
...
document.querySelectorAll ('svg.svgLoader').forEach (el => {
const src = el.getAttribute ('src')
if (!src) throw "SVGLoader Element missing src"
const svgSrc = fs.readFileSync (src)
el.innerHTML = svgSrc
})
...
})
I don't necessarily love it, but this is the solution I'm going with because I can now change classes on the SVG object and my CSS rules apply to the elements within the SVG. For example, these rules from index.css can now be used to declaritively alter which parts of the SVG are displayed:
...
#svgObj.cssClassBad #groupBad,
#svgObj.cssClassGood #groupGood {
visibility: visible;
}
...
I'm trying to convert my overlay add-on to restartless.
I can't access the bookmarks panel (on the sidebar) in SeaMonkey, in order to load my overlay UI.
Specifically, I need to do load my overlay to the bm-panel.xul similar to the following:
myListener.document.loadOverlay("chrome://myBookmarksPanelOverlay.xul");
For that, I need the window of bm-panel.xul but I only have the main window of the browser.
SeaMonkey has a different structure from Firefox, so the following example
var sidebarPanels = window.document.getElementById('sidebar');
which is in documentation, does not work for SeaMonkey.
I can see the bm-panel.xul window in the Dom Inspector, but I can't get to it with Javascript.
I was able to access only the sidebar panels but that's as far as I can go:
var sidebarPanels = window.document.getElementById('sidebar-panels');
How do I access the bookmarksPanel page itself?
I'm not 100% certain if your question is really limited to just finding the bookmarksPanel. Thus, this answer contains generic information about accessing the bookmarksPanel, viewing the DOM, accessing the sidebar from an overlay or restartless extension, and obtaining a window reference.
Accessing the bookmarksPanel
The following should get you a reference to the <page id="bookmarksPanel">:
var sidebarDocument = document.getElementById("sidebar").contentDocument;
var bookmarksPanelElement = sidebarDocument.getElementById("bookmarksPanel")
Note that you need to use the getElementById() in the sidebarDocument, not the main window.document.getElementById() which will not search into the sidebar.
Viewing the DOM
If you are having issues with knowing what the DOM structure is for a particular element, I would suggest that you install DOM Inspector (for SeaMonkey) (to view the DOM) and Element Inspector (which allows you to shift-right-click on an element and open the DOM Inspector on that element).
This is an example of the DOM Inspector viewing a Bookmark Sidebar in Firefox:
Accessing the Sidebar From an Overlay or Restartless Extension
Quoting from MDN: "Sidebar: Accessing the sidebar from a browser.xul script":
Accessing the sidebar from a browser.xul script
The sidebar content is always in a document separate from the main browser document (the sidebar is actually implemented as a XUL browser element). This means you can't directly access the sidebar content from a script referenced from a browser.xul overlay.
To access your sidebar's window or document objects, you need to use the contentWindow or contentDocument properties of document.getElementById("sidebar") respectively. For example the code below calls a function defined in the sidebar's context:
var sidebarWindow = document.getElementById("sidebar").contentWindow;
// Verify that our sidebar is open at this moment:
if (sidebarWindow.location.href ==
"chrome://yourextension/content/whatever.xul") {
// call "yourNotificationFunction" in the sidebar's context:
sidebarWindow.yourNotificationFunction(anyArguments);
}
Depending on how the current code you are running was started (e.g. UI button), you may need to obtain the current browser window.
Copying significantly from another answer of mine, you can obtain that by:
Obtaining a reference to the most recent window:
Firefox add-ons generally run in a scope where the global window object is not defined (if it is defined depends on how the portion of your code that is currently running was entered). Even if it is defined, it is often not defined as the window which you are expecting (the window of the current tab). You will probably need to obtain a reference to the window object for the most recently accessed window/tab.
If a browser window exists (in some instances you could be running where no browser window exists, yet, e.g. at start-up), you can obtain a reference to the most recent browser window, document, and gBrowser with:
if (window === null || typeof window !== "object") {
//If you do not already have a window reference, you need to obtain one:
// Add/remove a "/" to comment/un-comment the code appropriate for your add-on type.
/* Add-on SDK:
var window = require('sdk/window/utils').getMostRecentBrowserWindow();
//*/
//* Overlay and bootstrap (from almost any context/scope):
var window=Components.classes["#mozilla.org/appshell/window-mediator;1"]
.getService(Components.interfaces.nsIWindowMediator)
.getMostRecentWindow("navigator:browser");
//*/
}
if (typeof document === "undefined") {
//If there is no document defined, get it
var document = window.content.document;
}
if (typeof gBrowser === "undefined") {
//If there is no gBrowser defined, get it
var gBrowser = window.gBrowser;
}
If you are running the code in response to an event (e.g. a button command event), you can obtain the current window with:
var window = event.view
The lack of having the global window object available, or having it reference something other than what you are expecting, is something that many people encounter as a problem when writing Firefox add-ons.
Note: If you are wanting to be natively compatible with multi-process Firefox (Electrolysis, or e10s), then gaining access to the contents of the current document is more complex. There are shims in place which should make your code continue to work with multi-process Firefox for some time, but they may/will eventually go away.
References:
nsIWindowMediator
Working with windows in chrome code
SDK: window/utils
SDK: windows
Multiprocess Firefox
Working with multiprocess Firefox
Large portions of this were copied from my earlier answers, including this link.
This may not be the only way or the best, but here is what I am doing:
Find the sidebar element (sidebar-panels)
search the sidebar childNodes for the element with attribute src=chrome://communicator/content/bookmarks/bm-panel.xul
Searching the childNodes must be delayed until the relevant frames are loaded, and the search itself is a recursive iteration over all elements.
following is a minimal stripped code:
var sidebarE = domWindow.document.getElementById('sidebar-panels');
setTimeout(function() {
var sbPanelE = searchChildNodes(sidebarE);
}, 350);
function searchChildNodes (aElement) {
var stackNew = [];
var current;
var i, lenArr;
iterate(aElement);
function iterate(current) {
var childrenE = current.childNodes;
for (var i = 0, lenArr = childrenE.length; i < lenArr; i++) {
iterate(childrenE[i]);
foundE = checkElement(childrenE[i]);
if (e.nodeType == 1){ // Element node
if (e.getAttribute('src') == loc){
stackNew.push({ //pass args via object or array
element: childrenE[i],
});
return;
}
}
}
}
for (i=0;i<stackNew.length ;i++ ){
var itm = stackNew[i].element;
return itm;
}
} // searchChildNodes
I try to add an eventListener to my extension. I want to execute a function everytime a tab is active (got clicked by the user) or is new loaded.
I tried this:
window.addEventListener("DOMContentLoaded", checkHost(), false);
It gives me the error
Uncaught Reference Error: window is not defined
It drives me cracy, i can't find examples on the web. Please help me.
For those wanting to use the window object, you can create it using this code:
var { viewFor } = require("sdk/view/core");
var window = viewFor(require("sdk/windows").browserWindows[0]);
This code can be found on MDN at: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/windows
Via your current status: http://builder.addons.mozilla.org/package/206579/latest
The online builder is an online IDE for developing with the Addon-SDK, where window isn't in global scope -- it's not any specific window.
You can include the tabs module and listen for ready events or activate (a tab is now focused) events, which may be what you want.
let tabs = require('sdk/tabs');
tabs.on('ready', function (tab) {
console.log(tab.url + ' is ready!');
});
The issue is that Firefox extensions do not run in the context of any particular window. As such, they often do not have the window object defined, or it is defined as something which you are not expecting if you are not familiar with writing extension code. This is particularly true if you are approaching this from the point of view of writing JavaScript for use within an HTML page. Extensions operate in a significantly larger context which includes the entire browser and all windows and tabs. Thus, there is no automatically appropriate window to use as the window object. In the context of an extension, each HTML page is just a part of the whole.
You can obtain each primary browser window through the use of nsIWindowMediator. The following function, from MDN, will run the function you pass to it once for each open window:
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));
}
You will often want to find the window for the most recent browser/tab which was accessed by the user. The following code will define and set the window variable to the most recently used browser/tab. It will work either in the Add-on SDK, or in overlay/bootstrap extensions depending on which portion you un-comment.
For more information about using windows in a Firefox extension, you should see Working with windows in chrome code.
if (window === null || typeof window !== "object") {
//If you do not already have a window reference, you need to obtain one:
// Add a "/" to un-comment the code appropriate for your add-on type.
/* Add-on SDK:
var window = require('sdk/window/utils').getMostRecentBrowserWindow();
//*/
/* Overlay and bootstrap (from almost any context/scope):
var window=Components.classes["#mozilla.org/appshell/window-mediator;1"]
.getService(Components.interfaces.nsIWindowMediator)
.getMostRecentWindow("navigator:browser");
//*/
}
Alternately using Services.jsm to access nsIWindowMediator:
/* Overlay and bootstrap:
Components.utils.import("resource://gre/modules/Services.jsm");
//*/
if (window === null || typeof window !== "object") {
//If you do not already have a window reference, you need to obtain one:
// Add a "/" to un-comment the code appropriate for your add-on type.
/* Add-on SDK:
var window = require('sdk/window/utils').getMostRecentBrowserWindow();
//*/
/* Overlay and bootstrap (from almost any context/scope):
var window = Services.wm.getMostRecentWindow("navigator:browser");
//*/
}
You have to put the eventlistener inside a script referenced in the browser.xul overlay:
Try it like this:
window.addEventListener("DOMContentLoaded", function() {checkHost();}, false);
This question already has answers here:
Access variables and functions defined in page context using a content script
(6 answers)
Closed 9 months ago.
I would like to make a Chrome extension that provides a new object inside window. When a web page is viewed in a browser with the extension loaded, I would like window.mything to be available via Javascript. The window.mything object will have some functions that I will define in the extension, and these functions should be callable from console.log or any Javascript file when the page is viewed in a browser with the extension enabled.
I was able to successfully inject a Javascript file into the page by using a Content Script:
var s = document.createElement("script");
s.src = chrome.extension.getURL("mything.js");
document.getElementsByTagName("head")[0].appendChild(s);
mything.js looks like this:
window.mything = {thing: true};
console.log(window);
Whenever a page loads, I see the entire window object as I expect it to be in the console. However, I can't interact with the window.mything object from the console. It seems at if the injected script hasn't really modified the global window object.
How can I modify the global window object from a Chrome extension?
You can't, not directly. From the content scripts documentation:
However, content scripts have some limitations. They cannot:
Use chrome.* APIs (except for parts of chrome.extension)
Use variables or functions defined by their extension's pages
Use variables or functions defined by web pages or by other content scripts
(emphasis added)
The window object the content script sees is not the same window object that the page sees.
You can pass messages via the DOM, however, by using the window.postMessage method. Both your page and content script listen to the message event, and whenever you call window.postMessage from one of those places, the other will receive it. There's an example of this on the "Content Scripts" documentation page.
edit:
You could potentially add some methods to the page by injecting a script from the content script. It still wouldn't be able to communicate back with the rest of the extension though, without using something like postMessage, but you could at least add some things to the page's window
var elt = document.createElement("script");
elt.innerHTML = "window.foo = {bar:function(){/*whatever*/}};"
document.head.appendChild(elt);
After hours trying different attempts and facing security issues like CORS, I found ways to edit the window object on Chrome, Firefox and Safari. You need to use different strategies for each one:
Chrome
Add your script to content_scripts.
Inside your script file, append a script to the page and make it run your custom code inline. Like this:
;(function() {
function script() {
// your main code here
window.foo = 'bar'
}
function inject(fn) {
const script = document.createElement('script')
script.text = `(${fn.toString()})();`
document.documentElement.appendChild(script)
}
inject(script)
})()
Firefox
On Firefox, the solution above doesn't work due to a Content-Security-Policy error. But the following workaround is currently working, at least for now:
Add 2 scripts to content_scripts, e.g. inject.js and script.js
The inject script will get the full absolute url of the script.js file and load it:
;(function() {
const b = typeof browser !== 'undefined' ? browser : chrome
const script = document.createElement('script')
script.src = b.runtime.getURL('script.js')
document.documentElement.appendChild(script)
})()
Your script.js will contain your main code:
;(function() {
// your main code here
window.foo = 'bar'
})()
Safari
It's very similar to Firefox.
Create 2 javascript files, e.g. inject.js and script.js
The inject script will get the full absolute url of the script.js file and load it:
;(function() {
const script = document.createElement('script')
script.src = safari.extension.baseURI + 'script.js'
document.documentElement.appendChild(script)
})()
Your script.js will contain your main code:
;(function() {
// your main code here
window.foo = 'bar'
})()
Source code
See full code here: https://github.com/brunolemos/simplified-twitter
As others have pointed out, context scripts do not run in the same context as the page's, so, to access the correct window, you need to inject code into the page.
Here's my take at it:
function codeToInject() {
// Do here whatever your script requires. For example:
window.foo = "bar";
}
function embed(fn) {
const script = document.createElement("script");
script.text = `(${fn.toString()})();`;
document.documentElement.appendChild(script);
}
embed(codeToInject);
Clean and easy to use. Whatever you need to run in the page's context, put it in codeToInject() (you may call it whatever you prefer). The embed() function takes care of packaging your function and sending it to run in the page.
What the embed() function does is to create a script tag in the page and embed the function codeToInject() into it as an IIFE. The browser will immediately execute the new script tag as soon as it's appended to the document and your injected code will run in the context of the page, as intended.
A chrome extension's content_script runs within its own context which is separate from the window. You can inject a script into the page though so it runs in the same context as the page's window, like this: Chrome extension - retrieving global variable from webpage
I was able to call methods on the window object and modify window properties by essentially adding a script.js to the page's DOM:
var s = document.createElement('script');
s.src = chrome.extension.getURL('script.js');
(document.head||document.documentElement).appendChild(s);
s.onload = function() {
s.remove();
};
and creating custom event listeners in that injected script file:
document.addEventListener('_my_custom_event', function(e) {
// do whatever you'd like! Like access the window obj
window.myData = e.detail.my_event_data;
})
and dispatching that event in the content_script:
var foo = 'bar'
document.dispatchEvent(new CustomEvent('_save_OG_Editor', {
'detail': {
'my_event_data': foo
}
}))
or vice versa; dispatch events in script.js and listen for them in your extension's content_script (like the above link illustrates well).
Just be sure to add your injected script within your extension's files, and add the script file's path to your manifest within "web_accessible_resources" or you'll get an error.
Hope that helps someone \ (•◡•) /
I've been playing around with this. I found that I can interact with the window object of the browser by wrapping my javascript into a window.location= call.
var myInjectedJs = "window.foo='This exists in the \'real\' window object';"
window.location = "javascript:" + myInjectedJs;
var myInjectedJs2 = "window.bar='So does this.';"
window.location = "javascript:" + myInjectedJs2;
It works, but only for the last instance of window.location being set. If you access the document's window object, it will have a variable "bar" but not "foo"
Thanks to the other answers here, this is what I'm using:
((source)=>{
const script = document.createElement("script");
script.text = `(${source.toString()})();`;
document.documentElement.appendChild(script);
})(function (){
// Your code here
// ...
})
Works great, no issues.
Content Scripts can call window methods which can then be used to mutate the window object. This is easier than <script> tag injection and works even when the <head> and <body> haven't yet been parsed (e.g. when using run_at: document_start).
// In Content Script
window.addEventListener('load', loadEvent => {
let window = loadEvent.currentTarget;
window.document.title='You changed me!';
});