I have made several scripts for my work as an Accountant that automates many of our daily tasks like downloading some pdfs and mailing them.
This scripts are made with Ruby, Watir and chromedriver.
The main problem that i thought i was going to have is the change in the websites but that was not as problematic as the updates in chrome.
Every time there was a chrome update they changed the flags so i was unable to download pdfs i had to find the appropriate flags and it was fraustrating.
I manage to solve the above problem by creating a new profile of chrome for every script then changing the settings and manually saved them.
But there are at least 50 scripts and everyone needs a different setting for the chromedriver, it starts to get on my nerves.
Except that, I deployed an Ubuntu machine so everything will be more automated and not starting manually the script from my windows machine. Even in there the chromium keeps getting the same changes and eventually when updated it breaks everything.
I thought that the phantomjs could be good but I see that it is dead.
So the main question is do you know any driver that I can use, that hasn't got all the cr#p that the chrome does?
Thanks
To anyone dealing with Watir and Chromedriver or Chrome in general.
It seems that the pref directory_upgrade must be set in order for the chromedriver to download the file.
Also to the ones using watir.
In the latest versions this
prefs = {
download: {
prompt_for_download: false,
default_directory: path,
},
plugins: {
always_open_pdf_externally: true
},
}
must be modified like this
prefs = {
download: {
"prompt_for_download" => false,
"directory_upgrade" => true,
"default_directory" => path,
},
plugins: {
"always_open_pdf_externally" => true
},
}
Related
I am using quite large notebooks in JupyterLab to run Python code. They contain many Markdown cells with text and some images. The problem I am having is that when I close the Notebook and reopen, some of these cells have collapsed and can't be expanded (show as a horizontal line). Sometimes I will get a message telling me how many cells are hidden but they can't be expanded. Others seem to have disappeared completely.
Occasionally, I can get some cells to expand if I reload the page. I thought it may have been because I had lots of Markdown header levels and those too far down the hierarchy were collapsing. However, even removing many of the header levels has not solved the problem.
Have others had this issue and has anyone been able to resolve it? Thanks!
Edit: Thank you Vinson. My Jupyter Version is Version 3.1.7, running on Google Chrome (Version 92.0.4515.159 (Official Build) (64-bit)), on Windows machine.
This was fixed in JupyterLab 3.1.10 (this PR) released on 2021-09-01 - the issue should disappear after you upgrade and restart JupyterLab:
# (or conda-forge equivalent if you use conda/mamba)
pip install -U "jupyterlab>=3.1.10"
If however, you are unable to update right now, you can use a workaround of disabling the placeholder rendering, by going to Advanced Settings Editor -> Notebook and in the right pane (User Preferences) paste the following:
{
"renderCellOnIdle": false,
"numberCellsToRenderDirectly": 10000000000000
}
then press save and reload JupyterLab.
I do not know how to fix this with conda. But option 2 is working for me. For those who are not family with the deep tech, you can try these, two extran configure there are shown the line numbers.
{
"markdownCellConfig": {
"lineNumbers": true
},
"codeCellConfig": {
"lineNumbers": true
},
"renderCellOnIdle": false,
"numberCellsToRenderDirectly": 10000000000000
}
Scenario: A custom(legacy) app depends on Firefox on Windows. The following Firefox preferences are manually configured at install:[default]
modify: "dom.popup_maximum": [20] 500,
modify: "browser.cache.check_doc_frequency":[3] 1,
create: "dom.successive_dialog_time_limit": 0,
Goal: Update all current Firefox installs to a current version and apply the custom settings using enterprise capabilities. Establish process to manage Firefox for all future installs and updates. Don't break the app.
Problem: These changes can be easily applied individually via about:config. They are not part of the GPO templates and its not clear how to add them or if it can be done. Applying them via policies.json doesn't seem to work either.
On a representative test machine, a directory called \distribution has been created in the same directory as the firefox.exe [standard install, no hanky panky]. The file policies.json exists in the \distribution directory:
{
"policies": {
"Homepage": {
"StartPage": "homepage",
"URL": "https://www.google.com/"
},
"NewTabPage": true,
"DontCheckDefaultBrowser": true,
"Preferences": {
"browser.cache.disk.enable":true,
"dom.popup_maximum": -1,
"dom.successive_dialog_time_limit": 0,
"browser.cache.check_doc_frequency":1
}
}
}
about:policies results
This image shows the results of about:policies. The other settings, used to validate that the policies are working, get applied.
The results from about:config show that the three preferences that I need to affect, have not changed:
dom.popup_maximum;20
browser.cache.check_doc_frequency;3
and dom.successive_dialog_time_limit does not get created.
I believe that these are old preference options. But I also believe that if I can make the changes manually and achieve the desired results, there must be a method to accomplish it programatically.
I think that the best way to change preferences is to use a javascript file that you add to the source code in browser/defaults/preferences where you specify each preference individually.
See here for more information.
I'm trying to develop an extension to run on the FirefoxDeveloperEdition (which doesn't require signing) on mac.
I followed the "Your first WebExtension" guide and everything works fine when using the "Load temporary add-on". But when I try to package it and install it using the "install add-on from file", it shows "this add-on could not be installed because it appears to be corrupt".
I zip all the files (borderify.js, manifest.json, icons, without the container folder) and change the suffix to .xpi. Is this the correct way of packaging? some answers mention that there should be a "install.rdf" ?, if so, how can I create that file? it seems there is no guide on the docs.
UPDATE:
I've tried using the mac builtin "compress n items", xpi file, also tried using web-ext build, xpi file. they all end up with the same error alert.
UPDATE 2:
I've set xpinstall.signatures.required false in about:config.
My firefox version is: 51.0a2 (2016-10-17) (64-bit)
Is there anyone able to load the unsigned xpi? Is it a Firefox bug? or is it just me?
If you want to install .xpi, you need to provide an id.
Add this to your manifest.json root
"applications": {
"gecko": {
"id": "borderify#mozilla.org",
}
}
It's not particularly well documented, specifically this page tells that "add-on will be assigned a randomly-generated temporary ID when you install it in Firefox.". However, that only seems to work for installing over about:debugging - xpi installation still requires an ID. It might be any string, since you've running it on DevEdition with disabled checks anyway.
Goes without saying, that would not work on release Firefox.
P.S: Ctrl-Shift-J will open a browser console that will usually contain additional information about the extension installation error - might be useful next time.
I didn't find a way to debug Greasemonkey scripts with the Firebug extension.
Does anyone know how to do this ?
Thanks.
Updatier: The Mene+Shuman fix now is busted with Firefox 30 and Firebug 2. Firefox 31 may provide workarounds (will investigate). In the meantime, use the "General workaround strategies" listed below.
Update: This answer is now obsolete.
If you open about:config and
set extensions.firebug.filterSystemURLs to false
then you can use Firebug to debug the Greasemonkey script just like any other.
This works irregardless of the #grant mode.
See Mene's answer -- with an assist from Shuman.
Old answer:
Because Greasemonkey operates in a sandbox, Firebug cannot see it. There is no easy way around this.
General workaround strategies:
Test all parts of a GM script that don't use GM_ functions, in Firebug's JavaScript console first. Minimize use of GM_ functions and don't use GM_log() at all.
All of Firebug's console functions work great from within a GM script.
Note: this answer refers to old versions of Firefox. Firebug is no longer available, but lives on in the Developer Edition of Firefox.
Current Firefox and Firebug can now debug current Greasemonkey scripts just like any other javascript. Just find your *.user.js script in the dropdown menu. The console also works.
This works at least on Firefox 28.0 and Firebug 1.12.7; I haven't tried earlier versions.
Note: In order to get it to work, you probably have to set extensions.firebug.filterSystemURLs to false. See "Profiling Greasemonkey scripts" in the Firebug, bug tracker. (Thanks to Shuman)
var e = document.createElement("script");
e.src = 'http://www.xxxxxxxx.com/yyyyyyyy.js';
e.type="text/javascript";
document.getElementsByTagName("head")[0].appendChild(e);
you can add this to your xxx.user.js, and install it in greasemonkey.
Then, you can debug your js as you wish.
None of the other solutions here worked for me, but Jan Odvarko's answer on how to debug Firefox extensions worked perfectly for GreaseMonkey scripts as well:
On Firefox 19 or later, it's possible to use the built-in JS debugger
on the browser itself. Go to about:config and set the following two
prefs:
devtools.chrome.enabled: true
devtools.debugger.remote-enabled: true
After you restart the browser, you can access the Browser Debugger
through Tools > Web Developer > Browser Toolbox.
(note that you must accept the incoming connection)
See more at:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_JavaScript#JavaScript_Debugger
Then just search for the name of your userscript and start debugging.
It can be done using native Firefox debugger as it was mentioned before. Below is the instruction for modern versions of Firefox.
Set the following preferences in about:config:
devtools.chrome.enabled: true
devtools.debugger.remote-enabled: true
devtools.debugger.prompt-connection: false
Open the global script debugger window via
Tools → Web Developer → Browser Toolbox → Debugger (or Ctrl+Shift+Alt+I) .
Search for the name of your userscript and start debugging.
-- This answer is obsolete, please use #Brock Adams solution above --
Load your main script externally, instead of running it via GM. So you're just using GM to inject the script.
This is a bit of a hybrid between #bigml and #Yuval's solution and it uses jquery. It also works in frames.
// ==UserScript==
// #name My GM script
// #include The website I want this to run on
// #require http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js
// ==/UserScript==
$(document).ready(function() {
// fetch jquery dependent scripts using $.getScript()
});
Note: ChromeBug no longer exists. The Developer Edition of Firefox is an alternative.
Chromebug can see sandboxed scripts, http://getfirebug.com/wiki/index.php/Chromebug_User_Guide, but I've not tried it on Greasemonkey.
Similar to #bigml's suggestion, you can run it unprivileged if you setup a local webserver (apache) to serve the userscript file, then in your userscript add something along the lines:
if (typeof GM_addStyle == "undefined") {
loadScript("http://localhost/path/to/script.user.js");
}
else {
runScript();
}
function loadScript(url) {
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = url;
document.getElementsByTagName('head')[0].appendChild(res);
}
function runScript() {
// ... whatever your userscript does ...
}
Of course you wouldn't be running in a privileged context. But this way you can easily continuously debug the script as any other script.
Note: this answer refers to old versions of Firefox. Firebug is no longer available, but lives on in the Developer Edition of Firefox.
I've tried ChromeBug, it doesn't seem to work.
With FireBug I have had the starting point of success by adding "debugger" to my GM code. This causes a breakpoint and I can inspect variables on the stack, but the right file is not shown so I can't step or anything.
I have had the best success with FirebugMonkey (https://
addons.mozilla.org/en-US/firefox/addon/13623/), which I just got working to do basic
debugging of GreaseMonkey scripts thanks to some explanation in a
recent comment on the extension page by f0rsvinn. Here are the instructions I just posted at http://groups.google.com/group/greasemonkey-users/browse_thread/thread/994cfa58c79d222:
It never occurred to me that the way it works is by creating its own
sandbox around the script rather than using Greasemonkey's, you
actually have to turn GM off. There are some GM aspect things that
will not work though because the script really isn't in GreaseMonkey.
As an example, GM_getValue returns undefined.
Still, it works for basic debugging - and is way better than nothing.
Usage steps are as follows:
Install FireBug 1.5.4 (later versions do not seem to work)
Install FireBugMonkey
Use the Script Manager in FireBugMonkey to select the files you want to debug
Disable GreaseMonkey (scripts will run inside FireBugMonkey, not
GreaseMonkey)
Enable FireBugMonkey
Enable scripts in FireBug
The scripts you added in the ScriptManager should be visible in the
FireBug scripts list.
As the others have said, you can setup a simple HTTP server and serve it to your page using Greasemonkey like so:
function loadScript(url) {
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = url;
document.getElementsByTagName('head')[0].appendChild(script);
}
WEBrick and Python -m SimpleHTTPServer are good for this. We can also expose the GM_... functions to the script by adding a custom event handler to the document within GreaseMonkey:
function gMHandler(e){
GM_log(e.detail.message);
e.detail.response = "Hi!"
}
document.addEventListener("gM", gMHandler, false);
and then in the served script, raising this event on an arbitrary DOM element will run the handler and modify the element's response parameter:
$(document).ready(function() {
var event = new CustomEvent(
"gM",
{
detail: { message: "Hello World!" }
bubbles: true,
cancelable: true,
}
);
document.getElementById("AnyElement").dispatchEvent(event);
alert("Response was: " + event.detail.response);
});
Debugging a Firefox addon is a slow process: (1) edit source code in a JS editor (2) package into XPI using a build script (3) drag into Firefox to install (4) restart Firefox (5) open the JavaScript Debugger
Can we speeden up the process? Like install it into Firefox without a restart, or configure the build script to install it into Firefox as well?
You'll want to locate your profile folder. Once you find it, go into the folder called 'extensions', and then locate the folder for the add-on you are working on. Replace that folder with a file of the same name (minus .xpi if that's part of the name), and inside the file place the full path to your source directory of the add-on.
In Linux and Mac, that'll look like:
/full/path/to/yourExtension/
And on Windows:
C:\full\path\to\yourExtension\
Remember the trailing slash and beware of extra whitespace.
As long as you don't use jar files inside your add-on, you will no longer have to rebuild (this is covered in a bit more depth here).
Additionally, you'll want to set nglayout.debug.disable_xul_cache to true. For edits to xul or js files, you'll just have to open up a new window to see your changes instead of restarting the application. There are other preferences here that you may find useful as well.
Extra tips:
Starting firefox with a certain profile (dev), while other firefox profile is open and with the debugger already on:
"C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -no-remote -P dev -jsconsole
Check out the restart addon (saves time).
i use Netbeans with the Foxbeans Plugin for addon development, there you just press the "run button", and firefox starts up with the addon installed (into a test profile). maybe you should give this a try!
You need the "edit source" and "restart firefox" steps; they can't be removed from the process...
When you install the addon, the javascript ends up on disk, in your firefox profile. If you edit it in there, and restart firefox, the new stuff will be picked up. When you're done, create the xpi from the files in your profile.
http://simplygenius.com/2005/08/debugging-firefox-mozilla-extensions_25.html contains a good description of debugging FF extensions in venkman
Came here via google - FF nightly 31 has new tools for debugging add ons. Its a god send. Details here:
https://blog.mozilla.org/addons/2014/04/08/add-on-debugger-now-in-firefox-nightly/
To make development of the add-on faster, an important goal is to eliminate restart of FF to test every code change. Three options that I can think of:
Use the FF nightly 31 build, based on the other answers in this post.
Use the following add-on https://addons.mozilla.org/en-US/firefox/addon/autoinstaller/
Build it in your code with a restartless add-on. Refer to the answer in this post firefox restartless bootstrap extension script not reloading
I have used the last two options and it works greatly for me.
You can also set dynamic breakpoints via the debugger keyword. Open the "Browser Toolbox" to make the debugger stop at the line.
I think it's nice because you don't have to lookup the source file and line after every restart.
Also take a look at this Debugging extension code in firefox answer which mention the improved debugger capabilities for restartless extensions since Firefox 23.
As of 2022 most of the old answers are quite outdated.
Installing unsigned extensions/addons/themes is not possible anymore for the Release versions of firefox, especially just copying them into the profile/extension folder ("sideloading", see here).
Only ESR, Developer, Nightly and Unbranded versions of firefox still allow installation of unsigned extensions.
Mozilla gives a nice Firefox workflow overview for creating extensions.
For running and debugging extensions you can use the tool web-ext or the following (both methods described in link above):
in firefox open a new tab exteand type about:debugging
under This Firefox you can Load temporary Addon... to load your extension
(don't load a .xpi file, just select any file within the directory you develop your extension in)
the extension is loaded and you can debug it
you need to use the Browser Toolbox to debug extensions
in case the devTools won't work make sure devtools.chrome.enabled = true in about:config
when you made code changes you can click Reload in the debugging tab
Finally, after coding and testing, when you want to create a new .xpi file, VS Code's Tasks are handy.
This here is a very simple task that uses 7-zip on Windows to create a .xpi:
{
"version": "2.0.0",
"tasks": [
{
"label": "Make Theme .xpi",
"type": "process",
"windows": {
"command": "C:\\Program Files\\7-zip\\7z.exe",
"args": ["a", "-tzip", "${relativeFileDirname}-theme.xpi", "${fileDirname}\\*"]
}
}
]
}
(this snippet uses variable substitution to read files and put .xpi file into specific dir)