JavaScript Acrobatics
When you disable the JavaScript support in Adobe Acrobat or Acrobat Reader, you get this somewhat confusing warning every time the application exits:
Let's try to ignore the error in the message text (you don't pluralize a language name) and focus on the error causing it to be shown. This message is obviously supposed to notify the user of potential problems when opening a PDF document with embedded scripts, but it is in fact shown whenever you quit the application. The warning is likely triggered by some internal use of JavaScript.
I'm not the first person to investigate this bug (which isn't fixed in version 7.0.1, by the way): Richard Griswold was sufficiently annoyed to create patches for the Acrobat 7.0 ECMAScript plugin, EScript.api. His patches, which are distributed as Perl scripts, will replace the code to display the message with NOP instructions.
It looks like the patch for the Windows version would work for Acrobat 7.0.1 too (I don't think that plugin was updated), but I try to avoid patching binary files for problems such as this. In this case I wouldn't have to create the patch myself, but I may need a new patch for the next application update and I don't want to rely on a third party to provide it. I had to modify an Internet Explorer binary in order to get around its "Your current security settings prohibit running ActiveX" messages, but I prefer simpler solutions when possible. Features like self-repairing applications and Windows File Protection also have a tendency to get in the way.
Maybe there's a less intrusive solution? One way would be to disable the JavaScript plugin entirely (the plugin is loaded even if you disable JavaScript support through the settings). Attempting this revealed that several other plugins depends on EScript.api, including an automatic update function I'd like to keep.
Next I tried tracking process file accesses while exiting Acrobat and found a likely culprit. On application exit the file glob.settings.js was written to a JavaScripts subdirectory in Acrobat's application data directory:
\Documents and Settings\<login>\Application Data\Adobe\Acrobat\7.0\
glob.settings.js is not actually a JavaScript file, despite the .js suffix. I guess it just contains JavaScript-related settings. Removing the file or the JavaScripts subdirectory turns out to remove the error message, but only during the next exit because the file is recreated if not found.
There's a simple trick that'll often work when Windows applications insist on running or loading files you don't want them to (and recreating them): keep the file around, but deny all access to it through file system permissions. Perhaps surprisingly, many applications will ignore access denied errors rather than complaining about them.
To deny all access, right-click the abovementioned JavaScripts directory, then uncheck "Allow inheritable permissions from parent to propagate to this object" under the Security tab, choose Remove, and click OK. You'll see a warning about denying everyone access, click Yes.
There could be unforeseen problems, but with this change JavaScript is still shown as disabled in Acrobat and the exit warning message is gone, so it appears to be an easy workaround for the bug.
10 April, 2005
Feedback
by Thom
As far as I know Johan's solution only works in case the harddisk is formatted NTFS and w2k or wxp is used. Otherwise setting access permission is not possible.
An easier solution is:
Delete file "glob.settings.js" and create an empty folder with that name in the same directory instead. Since Acrobat cannot write to this newly created folder, the error message won't appear.
by Johan
You mean there are still people running Windows 95/98/Me? Masochists. ;-)
Replacing the file with a directory and the parent directory with a file should work just as well. One advantage of changing just the file permissions is that it's easy to undo if it turns out to break things.
by Leni
I've been running Johan's solution and it seems to work great. I didn't see the need to mess with the directory permissions - creating a zero-length file and setting it's permissions to deny-all did the trick.
If you can't find the Security Tab (when you right-click the file and select Properties), go to the Folder Options (Tools/Options/View in Explorer) and deselect "Use simple file sharing (recommended)". This allows you to set per-user security permissions.
by peter g
Thank you Johan!
(and google for making this page easy to find)
I fear mr adobe is turning this lightweight reader into a bit of a monster.
by chris m
thanks again, and power to google... if I get around to giving this link in the Adobe forums, you'll have lots more visitors!
by Robert Tarrall
Fix for OS/X version of Acrobat Reader, based on the above:
open a Terminal window
type:
cp /dev/null ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/glob.settings.js
sudo chown -R root ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/
sudo chmod 0555 ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/
That should do it. Thanks for the info on this page, which got me on the right track.
by Oliver Gehrke
Thank you very much, Johan! Your little permissions hack works beautifully...
by Martin
Thank you Johan!
by CAT
It works also for Linux:
chmod 000 $HOME/.adobe/Acrobat/7.0/JavaScripts
by Greg
Thanks very much for this tidbit (I actually used Thom's solution) which I found instantly once I got fed up with the issue and searched with google. Now to look around for a solution to the annoying ActiveX dialog you mentioned. That's been driving me nuts for years now. Thanks again!
by Bill Denneen
Thank you for this simple and effective solution. It worked like a charm on Mac OS X.
I fear the terminal window, so I did this: Control-click on the file (glob.settings.js in library/acrobat user data/7.0/JavaScripts), select "Get Info", change permissions to "no access", problem solved!
by Bill Denneen
I spoke too soon...the next time I opened Reader after it was fully closed, it reverted to its old ways. I don't know how it got past the "no access" permission on the file, but it did. So I deleted the file and changed permissions on the JavaScripts folder to read-only. Now it seems to be working.
by Johan
If Acrobat has write permission for the directory it'll still be able to remove and create files in it (this might seem a bit confusing at first, but it's the way *nix directory permissions usually works). That's why you want to deny access to the JavaScripts directory rather than to the file itself.
by Peter
Thanks for this simple fix! I run Linux and did as CAT.
So much for Adobe and their monster reader.
by Max
Actually Win98 is superior to XP. I've tried both and 98 is the zenith of Windows development.
by Mike
Still a problem in Acrobat 7.0.3, and Johan's permissions hack seems to work fine.
by baffotremendo
I can't get Johan's trick working, on an XP and Acrobat 7.0.3. I understand conceptually the trick but it seem non working at me.
by Eric
Thanks for the workaround! And thanks to the other readers for followup suggestions, too!
by bj
Thanks for the fix! That annoying window has been bugging me for years.
Aside: Adobe is an idiot company. Once PDFs were a secure way to distribute documents, but in their vain attempt to be all things to all people by embedding JavaScript they've PDFs are now no better than Microsoft Word .DOC files.
I hope Microsoft show a brain and in their upcoming-PDF killer Metro are smart enough to keep scripting out. Well, that seems unlikely, but Adobe truly deserve to go out of business.
Feedback is closed for this entry.
by Greg Allen
Like the ideas above, but here's a trivial fix...
Rename or delete the directory %APPDATA%\Adobe\Acrobat\7.0
mv JavaScripts JavaScripts.go.away
Create a *file* called "JavaScripts" - e.g. from a command line:
cd %APPDATA%\Adobe\Acrobat\7.0
mv JavaScripts JavaScripts.go.away
echo >JavaScripts
This prevents reader from recreating glob.settings.js