Check if Opera extension installed in developer mode - javascript

Is there some predicate or variable that one can use in the extension code to determine whether it was installed normally or in developer mode?
(I'd like to put some debug output visible only in developer mode.)

No, there is no way to get this info directly.
But what you can do is the following:
Create a file with the name debug.txt (or what you want) in your extensions folder.
Make sure you always delete this file when creating the zipped .oex-file!
Now you can add the following code to your background script:
var debugFile = opera.extension.getFile("/debug.txt");
if (debugFile) {
//This is debug mode!!
}
You will get a valid [File]-Object if the file exists and null otherwise.
(Infos: http://dev.opera.com/articles/view/extensions-api-resourceloader/)

Related

How do I read a JSON file using HTML?

Here is my code:
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js">
</script>
<script>
$(function() {
var thing = [];
var bar = $.getJSON('C:\Users\cccompro\foo.json', function(obj) {
for (i = 0; i < obj.length; i++) {
thing.push(obj[i]);
}
});
});
</script>
I'm not sure why it doesn't work. "foo.json" contains an array of objects.
If you are trying the code at Question at Chrome or Chromium browsers, launch the browser instance with --allow-file-access-from-files flag set. Note that open instances of Chrome or Chromium should be closed when you launch the browser or the instance will be launched with the open browser instances' configuration folder, instead of with the flag set. You can launch Chrome or Chromium with an existing instance open and honoring the flag by using --user-data-dir flag with value set a different directory than open instance of Chrome or Chromium.
Technically, it is also possible to write to user file system without using an extension with window.webkitRequestFileSystem. Though using chrome.fileSystem within an extension provides an API designed to achieve the read/write.
See
Jquery load() only working in firefox?
Read local XML with JS
How to Write in file (user directory) using JavaScript?
How to use webkitRequestFileSystem at file: protocol
JavaScript/Ajax Write to File
Using <input type="file"> element
How to print all the txt files inside a folder using java script
You cannot read files directly from the users hard drive without the browsers permission. This would be a huge security issue if you could even though there are ways to allow this (checkout guests answer).
You could however try to make the user select the file and then read it with Javascript.
This is called the HTML 5 file API.
However, this doesn't work for any browser and you probably have to use a server anyway in this case.
For more information on this checkout this or this post.

I can't use the browser object from the settings page of my Firefox add-on

I'm making a Firefox Add-On that needs to keep track of a list of words. From the main javascript file I can read and modify a stored Array under the name "list", but when I try to access it from the settings page I get an error:
ReferenceError: browser is not defined
Here is the function from which I try to access the local storage (this is in the .js file that is used in my .html settings page).
function EmptyList() {
if (confirm("Empty list?")){
browser.storage.local.set({
list : []
});
}
}
I don't understand what am I doing wrong. I'm not doing anything different from what they do in the mozilla tutorial.
Apparently it has something to do with the cache.
Disable and reenable the add-on (or remove it and add it again) and it works. Go figure.

Debugging Firefox extension - How to see all JS and XUL files contained in the XPI?

I'm trying to debug a Firefox extension, using Firefox 28.0.
I have set up the dev environment as suggested in https://developer.mozilla.org/en-US/Add-ons/Setting_up_extension_development_environment (actually I just took the lazy way out and installed the DevPrefs extension to set all the necessary about:configs)
I then open Firefox and go into the debugging environment (Tools > Web Developer > Browser Toolbox).
I then go to the Debugger tab.
However, under the Sources pane, under my extension (e.g. chrome://myextension), I only see some of the JS and XUL files that are contained in my extension XPI.
How can I manually "load files" in the debugger, so that I can set a breakpoint and trace the runtime of my extension?
The debugger doesn't have any functionality that would allow loading files "manually", instead it will show you every file that is currently loaded by the JavaScript engine. If you dig into details, this means that whenever the JavaScript engine compiles a new script the debugger is notified and adds the corresponding file to its list. So normally all you need to do is open a page or dialog that uses that script and it will become visible in the debugger. I say "normally" because in my tests this didn't seem to work reliably - there appears to be some bug which makes the debugger miss out some scripts, maybe that's what prompted your question.
Now of course you can consider faking the notification to force the debugger to load a particular file - e.g. if you want to set breakpoints before the file actually loads. I tried it and it is indeed possible, but it requires you to mess with Firefox internals and it relies on a number of implementation details that might change in future Firefox versions. In particular, you need to get the DebuggerServer instance used to communicate with the debugger. While the in-process debugger always uses the same instance which is trivial to get, a new instance is created for each remote debugger. From what I can tell, getting to that instance is only possible with the changes implemented in bug 993029 which means that it will only work with Firefox 32 (currently available from the Firefox Aurora channel) and above.
The problem is that the DebuggerServer instance is being created by the BrowserToolboxProcess class declared in ToolboxProcess.jsm. Before the changes introduced by bug 993029 a BrowserToolboxProcess object would be created and no reference to it kept - meaning that it would be impossible to access it and the corresponding connection after the fact. Starting with Firefox 32 all created BrowserToolboxProcess objects are stored in the processes set and can be enumerated.
This code can be used to fake a Debugger.onNewScript() call that will be forwarded to the remote debugger:
(function()
{
// Iterate over existing processes
const {processes} = Cu.import("resource:///modules/devtools/ToolboxProcess.jsm", null);
for (var process of processes)
{
// Iterate over connections associated with each process
var debuggerServer = process.debuggerServer;
for (var connID in debuggerServer._connections)
{
if (!debuggerServer._connections.hasOwnProperty(connID))
continue;
var conn = debuggerServer._connections[connID];
// Get ChromeDebuggerActor instance for the connection
var chromeDebugger = conn._getOrCreateActor(conn.rootActor._extraActors.chromeDebugger.actorID);
// Fake new script call
chromeDebugger.onNewScript({
url: "chrome://myextension/content/script.js", // CHANGE THAT LINE
source: {text:""},
getChildScripts: () => []
});
}
}
})();
As mentioned above, this code should only work starting with Firefox 32, I tested it on Firefox 33.0a1. You can run it from Scratchpad, make sure to switch environment to "Browser". There is no guarantee whatsoever that it will continue working in future Firefox versions, there are several implementation details used here that can change at any time.

How to bypass document.domain limitations when opening local files?

I have a set of HTML files using JavaScript to generate navigation tools, indexing, TOC, etc. These files are only meant to be opened locally (e.g., file://) and not served on a web server. Since Firefox 3.x, we run into the following error when clicking a nav button that would generate a new frame for the TOC:
Error: Permission denied for <file://> to get property Location.href from <file://>.
I understand that this is due to security measures within FF 3.x that were not in 2.x, in that the document.domain does not match, so it's assuming this is cross-site scripting and is denying access.
Is there a way to get around this issue? Perhaps just a switch to turn off/on within Firefox? A bit of JavaScript code to get around it?
In firefox:
In address bar, type about:config,
then type network.automatic-ntlm-auth.trusted-uris in search bar
Enter comma separated list of
servers (i.e.,
intranet,home,company)
Another way is editing the users.js.
In users.js, write:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://site1.com http://site2.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
But if you want to stop all verification, just Write the following line into users.js file:
user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");
You may use this in firefox to read the file.
function readFile(arq) {
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
var file = Components.classes["#mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
file.initWithPath(arq);
// open an input stream from file
var istream = Components.classes["#mozilla.org/network/file-input-stream;1"].createInstance(Components.interfaces.nsIFileInputStream);
istream.init(file, 0x01, 0444, 0);
istream.QueryInterface(Components.interfaces.nsILineInputStream);
var line = {}, lines = [], hasmore;
do {
hasmore = istream.readLine(line);
lines.push(line.value);
} while(hasmore);
istream.close();
return lines;
}
Cleiton's method will work for yourself, or for any users who you expect will go through this manual process (not likely unless this is a tool for you and your coworkers or something).
I'd hope that this type of thing would not be possible, because if it is, that means that any site out there could start opening up documents on my machine and reading their contents.
You can have all files that you want to access in subfolders relative to the page that is doing the request.
You can also use JSONP to load files from anywhere.
Add "file://" to network.automatic-ntlm-auth.trusted-uris in about:config

Chrome API: Get Window Type

I'm working on a project and run into an issue where I need to distinguish a chrome app window from normal ones. (Specifically I'm using the --app=URL from a bash script) Because of the way things are setup, I have to have run a js script on all windows, but only do something if they are an app window. It seems that the API listed here is what I need to distinguish one window from another, but all I've managed to get are errors saying that a function or object is undefined. So how am I suppose to get the window type from the API with something like window.type?
Additionally, if you know of some other way to tell the difference between chrome windows if they are an app window or not, then that would also work. I really just need to be able to do:
if (window is app) //I don't really care how it's done
{
doSomething();
}
More information:
Tried in both Chrome and Chromium (both fully updated)
Using Ubuntu 18.04
JavaScript is running in the app window and not an extension (not developing an extension)
Can you try the following. In your console
windowType=window.location.host
It should return if you are in app window it will return as "app". Using this you can write your logic
if (windowType === 'app' ) //I don't really care how it's done
{
doSomething();
}
Hope it helps.
Doing windowType.window.location.host returned not the type of window but rather the url provided with the --app=url flag in my bash script. This means that if you open a normal window and go to the same url as provided in the app window, both would return the same url. However, since the normal window would be the same content just a different window type, the JavaScript code that I need to run on the webpage is the same, thus I would want it to run on both windows. So this solution works for me, but for anyone else who is looking for a window specific identifier, and not just a url, I suppose that is still up in the air.
(Thanks Ragavan Rajan)

Categories

Resources