Adding an @require breaks Greasemonkey (when files are locked)

[john-sanders-2]

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:

1. Created a new profile.
2. Installed Greasemonkey, and created a new script for the page.
3. The only code added was: alert('working');
4. Verified the script worked, and it does.
5. Edited the script again (GM icon->manage scripts->edit), and added a require tag to bring in jQuery 1.7 (although any version I've tried causes the same problem). The script fails to run.

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');

The script stops working. Does not kick any errors or warnings in the Javascript console. I did notice the config.xml does get updated, but not correctly (i presume). Here's the result of the config.xml after I load the test page:

<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.

John Sanders

[john-sanders-2]

A work around that seems to fix the problems in config.xml, and allows scripts to run...

1. Get the file path to the broken script.
2. In the Firefox URL, type file:///< file path to broken script >
3. GM will see this as a user script to install, it will overwrite your current version that is broken, and set up config.xml properly.
4. Reload the page with the broken script. Should work.

Example of my file path URL:

file:///C:\Users\john\AppData\Roaming\Mozilla\Firefox\Profiles\wivgvq8w.greasemonkey_testing\gm_scripts\helper_scripts-2\helper_scripts.user.js

[arantius]

I can't reproduce.

[zewt]

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:

// Get rid of old dependencies.
var dirFiles = this._basedirFile.directoryEntries;
while (dirFiles.hasMoreElements()) {
  var nextFile = dirFiles.getNext()
      .QueryInterface(Components.interfaces.nsIFile);
  if (!nextFile.equals(this.file)) nextFile.remove(true);
}

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.

[arantius]

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.

[zewt]

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.

[arantius]

Reporters: Please test and report whether this build fixes your issues:
https://github.com/downloads/arantius/greasemonkey/greasemonkey-0.9.15.xpi