Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding an @require breaks Greasemonkey (when files are locked) #1466
I'm using Firefox 8.0, Greasemonkey 0.9.12, on Windows 7 (all latest updates).
I've been using a hand rolled Greasemonkey script to update parts of an Intranet page I use all the time. I changed the require tag to use the latest jQuery and the script stopped executing.
After a lot of testing, I've broken the problem down to the smallest parts possible to see if I was doing something wrong. I have:
My entire script reads as follows (domain name changed):
// ==UserScript== // @name Helper Scripts // @namespace w // @include http://example.com/* // @require http://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js // ==/UserScript== alert('working');
<UserScriptConfig> <Script filename="helper_scripts.user.js" name="Helper Scripts" namespace="w" description="" version="" enabled="true" runAt="document-end" basedir="helper_scripts" modified="1320954850701" dependhash="30ee872c576e6e700ef9c9ad7e01f8605a750f52" updateAvailable="" lastUpdateCheck=""> <Include>http://example.com/*</Include> <Require filename=""/> </Script> </UserScriptConfig>
I'm assuming that the GM adding the tag with the empty filename attribute is messing things up. If you edit the XML directly, and reload, GM will wipe it out and revert it back to an empty attribute again.
I'm perplexed, and would love to have my GM scripts back. Any help would be appreciated.
A work around that seems to fix the problems in config.xml, and allows scripts to run...
Example of my file path URL:
This is happening to me, too, triggering:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.remove]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://greasemonkey/content/script.js :: <TOP_LEVEL> :: line 507" data: no]
This is the remove() call in:
That tries to remove Vim's .swp file, which fails since the file is open and locked. This should be more selective about what it deletes, and not fail entirely if removing a single file fails.
A more usable workaround is to close Vim (or whatever you're using that's creating a lockfile) after changing dependencies, and reload the page to cause dependencies to be updated while your editor is closed.
Interesting! Thanks for that report, zewt. What platform are you running vim on that locks files? On both Linux and Windows (cygwin) I can delete the .swp file.
The right fix is probably to find require/resource/icon entries for the old version of the script, and just deleting those files. Detecting and warning for failure (rather than breaking like this) if even that fails, while we're at it, is probably good too.
A native Windows build (not cygwin). See the top link (currently gvim73_46.exe) at http://www.vim.org/download.php#pc.
Windows locks all opened files by default, including files opened with fopen(); the only way to open files without locking is to use a lower-level Win32 API to explicitly disable it. Cygwin may be doing just that in order to more closely emulate Unix, where files aren't locked by default, which may be why you're not seeing this with a Cygwin build of Vim.
referenced this issue
Jan 23, 2012
Reporters: Please test and report whether this build fixes your issues: