I fail to either set global or window property or require/import within browser console, which makes live testing impossible. I avoid running this code in SSR with platform.isNode condition.
Related
I'm trying to debug a Chrome extension that uses chrome.runtime.getPlatformInfo() to choose which codepath to execute depending on the OS. Functionality is different depending on the operating system (this is not something I agree with, but I do not control the extension's development). While I could try to replace each instance in the source code, returning false data instead of actually calling the browser-provided function, I find such a solution inelegant and prone to human error.
I'm doing my testing on a computer running macOS. I want the extension to think I'm running ChromeOS (where the returned object has the "os" property set to "cros"). How would I go about spoofing the returned object to have the properties set to my desired values?
I've tried searching for command line startup flags, but I couldn't find one for this purpose. I tried using the User-Agent flag, but as one may expect, that only affects the User-Agent header and not the data returned from chrome.runtime.getPlatformInfo().
I'm trying to write a Firefox extension which hooks into WebAudio and adds a 'master-gain' to all AudioContexts.
I am trying to do this by overriding the AudioContext constructor in the window namespace. This way I can return a GainNode (which is internally connected to the destination) when the user tries to access destination. It's a hack, but I think it might be useful.
I'm currently struggling at exporting my newAudioContext constructor from the addon script(privileged scope) into the page script (less-privileged).
I tried...
unsafeWindow.AudioContext = cloneInto(newAudioContext,unsafeWindow);
But I still get the original AudioContext in the page script.
I also tried
exportFunction(newAudioContext, unsafeWindow, {defineAs: "AudioContext"});
but that exports it as a function and not as a constructor.
I understand that structured cloning has limitations, but are there any other ways I can override the window.AudioContext from an AddOn?
If you need to run more complex code (e.g. object construction) in the unprivileged context you can simply import a script into the target window (after waiving xrays) through the mozIJSSubScriptLoader.
Any function that needs to call into privileged code can be patched into its prototype from the chrome side after the script has been loaded.
You can do this before DOM parsing - and thus before any content script execution - by listening to the DOMWindowCreated event.
You will have to do this from a frame script, since the addon-sdk's page-mod sandboxes don't have enough privileges to access the script loader.
Keeping interaction with the unsafe window to a minimum, i.e. either running code wholly in the privileged environment with xrays or completely in the untrusted environment with the minimal amount of glue methods between those two seems like good security hygiene anyway.
Of course you should be aware that content code will be able to pick apart and modify any classes you create in content. It is untrusted after all.
I'm absolutely new to CasperJS and I'm wondering what's the difference between those 'two modes'.
Both access the DOM, it seems that test mode has a limited access and functionality.
I looked for this question around and didn't find the answer.
In test mode you have access to the tester module and with it access to asserts, test suites and (xml) reports. This is not accessible in plain mode anymore (earlier versions than 1.1-beta4 had access to some of the test mode stuff in plain mode).
The only drawback to test mode is that you can only have one casper instance which is injected. This leads to:
When you try to create it, you will get an error.
(Nearly) all options have to be assigned directly and cannot be passed to create as an object.
Some things cannot be done like this one: A: How to open a new tab in CasperJS
The problem: toggle javascript support without restarting firefox (nor resorting to different driver) during cucumber test run.
If Firefox's prefutils were exposed to javascript in a web page, that would make it possible. But it is not the case.
So, is there a plugin that does it? Or is there another way to solve the problem? Or is there a good tutorial (that highlights the exposing bit) on how to make such a plugin?
Edit
On a second thought, how would javascript be of any help once it is disabled? Probably the whole idea is a bit screwed.
I assume that your tests run with normal web content privileges. In that case, they aren't going to be able to affect browser settings such as whether JavaScript is enabled (I assume that's what you mean by "toggle JavaScript support").
I'd implement a simple XPCOM component with a method to turn JS support on and off (by setting the appropriate pref). You can expose it as a JavaScript global property so that your tests can access it. See Expose an XPCOM component to javascript in a web page for more details. Package your component in an extension and make sure it is installed in the Firefox instance where your tests are running.
If you want to access the preferences API directly from your content script, you can add the following prefs to Firefox, either in about:config or by adding the following lines to prefs.js in your profile directory:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect UniversalBrowserRead UniversalBrowserWrite UniversalPreferencesRead UniversalPreferencesWrite UniversalFileRead");
user_pref("capability.principal.codebase.p1.id", "http://www.example.com");
user_pref("capability.principal.codebase.p1.subjectName", "");`
user_pref("signed.applets.codebase_principal_support", true);
Replace www.example.com with the domain that you want to grant the privileges to. Also add this line to your JS code before you call the preferences API:
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
A local file (something loaded from file:///) is allowed to request additional privileges. Normally you would get a prompt asking whether you want to allow access - you can "auto-accept" the prompt by adding the following lines to prefs.js in the Firefox profile:
user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p0.id", "file://");
user_pref("capability.principal.codebase.p0.subjectName", "");
You page can then do:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
var branch = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
branch.setBoolPref("javascript.enabled", false);
This will definitely work if your page is a local file. Judging by the error message however, you are currently running code from about:blank. It might be that changing capability.principal.codebase.p0.id into about:blank or into moz-safe-about:blank will allow that page to get extended privileges as well but I am not sure.
However, none of this will really help if JavaScript is already disabled and you need to enable it. This can only be solved by writing an extension and adding it to the test profile. JavaScript in Firefox extensions works regardless of this setting.
That means you need Javascript to toggle enabling or disabling Javascript.
function setJavascriptPref(bool) {
prefs = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
prefs.setBoolPref("javascript.enabled", bool);
}
I have an NPAPI Plugin that runs in Firefox, but any time that the tab is "torn off" (by dragging the tab into space so a new window is formed), the plugin is destroyed and recreated. The problem is that the plugin needs to be initialized with information from an Ajax call, and I cannot find any way in Javascript to detect this, so the plugin is not getting the necessary initialization information.
So, any ideas as to how to detect this event and/or make the plugin not be destroyed/recreated when the tab is torn off?
What operating system are you dealing with? If it is actually destroying your plugin and recreating it, you could always have the plugin attempt to call a javascript method on startup.
Specify the name of the function in a param tag and then on plugin startup, attempt to get a reference to that method by calling NPN_GetProperty on the window NPObject (which you can get by calling NPN_GetValue(NPNVWindowNPObject, &npobjectptr) and then calling NPN_GetProperty(npp, npobjectptr, NPN_GetStringIdentifier(functionname), &destObj)
Then you can invoke that method with a reference to your plugin (which you can get again with NPN_GetValue) and the js function will know that it's time to initialize your plugin (again?).
You could do other things as well, such as store initialization data in global space and try to figure out a way to detect that it should be the same plugin instance... not sure how to be sure it's supposed to be the same one, though.