Parallels desktop 8 for Mac keyboard switching and painting issues

In this post I'll describe the solutions for two issues encountered after upgrading to Parallels Desktop 8 on my Mac 10.7 (with Win XP as the guest OS).

Windows not painting fully

The first problem was that popups and windows (such as the Windows Start menu or task manager) were not always displayed correctly in Coherence. Part or all of the window was blank (white) until something caused it to repaint (see a related thread on Parallels forums):

This was fixed by turning 3D acceleration on (Virtual Machine menu -> Configure... -> Hardware tab -> Video).

The fix was suggested by Parallels' support, who said the glitch was an unintended side-effect of other improvements that went into PD 8 and that unless turning 3D acceleration on causes other problems, this is the fix (i.e. keeping 3D acceleration on will be required).

Keyboard layout / input language not switching

Another problem was with switching input languages in the guest OS. Command+Space (the shortcut I use to switch languages ("input sources") on Mac) could not change the language to English while Parallels was focused.

Turned out this was due to keyboard configuration in the Win XP "Text services and input languages" dialog. I somehow ended up with "United Kingdom (Apple) - Parallels" as the only keyboard for the "English (United States)" language:

The problem disappeared when there was a "US" or a parallels US keyboard in the list of available layouts for the language:

dyld: unknown required load command 0x80000022 starting Firefox (and others) on Mac OS X 10.5

If you get a message like this when running a Mozilla application on Leopard:

dyld: unknown required load command 0x80000022
Trace/BPT trap

...chances are the system tries to run a build intended for Snow Leopard.

A workaround you could try is to run Terminal.app and use the arch command like this:

arch -i386 /Applications/Firefox.app/Contents/MacOS/firefox-bin

(Substitute /Application/Firefox.app with the location of the app, and use the name of the executable (ending with -bin) instead of firefox-bin as necessary.)

As with any other command you can create a launcher icon for the command easily.

This should apply to newer Mozilla-based applications: Firefox 4 (including Minefield builds since Oct 2010), Thunderbird post 3.2, BlueGriffon, and future versions of other applications based on Mozilla 2 (Komodo, Songbird, etc.)

Technical details

If the workaround works for you, the application is a i386/x86_64 universal binary. The x86_64 part of the application uses 10.6-specific features, so it can't run on 10.5; the i386 binary is intended for 10.5.

The cause of the error message is that the wrong architecture is selected for some reason. This happened to me when trying to run such an executable directly from the command line (technical details are in this Mozilla bug).

Stripping x86_64 part from the binary

This tip is brought to you by JW from the comments (via jarib from github): if you don't control the command line command used to start Firefox, you can instead strip the x86_64 part from firefox-bin using ditto:

cd /Applications/Firefox.app/Contents/MacOS
mv firefox-bin firefox-bin.original
ditto --arch i386 firefox-bin.original firefox-bin

Warning: with this workaround (unlike when running via arch) you will stop receiving Firefox updates and this change will have to be re-applied each time you update Firefox manually.

Couldn't load XRE functions with XULRunner on Mac OS X

While trying to upgrade XULRunner and ChatZilla on my Mac OS X (10.5), I got into a state where running ChatZilla.app didn't have any effect.

When I tried to run /Applications/ChatZilla.app/Contents/MacOS/xulrunner in the terminal, I got "Couldn't load XRE functions."

Going into /Library/Frameworks/XUL.framework/Versions/ and deleting the old 1.8 version of XULRunner fixed this (I don't know why, though).

Using Firefox profiles on Mac OS X

If you are a Firefox power user, you are probably familiar with its profile system. A profile is a folder where Firefox keeps all your customizations, history, bookmarks, cookies, and other data.

Firefox lets you run several independent instances using different profiles simultaneously -- by specifying special options in the command line. The basics are covered in this lifehacker article.

Unfortunately on Mac OS X there's no easy way to specify command line parameters in a "shortcut", like there is on Windows. The well-known workarounds are:

1. Use Terminal.app or similar to execute /Applications/Firefox.app/Contents/MacOS/firefox-bin with the necessary parameters.
2. Use a separate launcher application like MultiFirefox, which is similar to Firefox's own profile manager, and also lets you choose the Firefox version to run.
3. Use Script Editor.app to create an "application" that runs Firefox with the command-line parameters you want.
4. Create multiple slightly edited copies of Firefox.app that run with the specified profile.

I used a combination of these until recently, and they're all imperfect: the first and second workarounds require several steps to run Firefox, and the third option was too slow for me. The fourth just seems wrong.

My solution

This solution was tested with Mac OS X Leopard, Snow Leopard, and Lion. We create a lightweight bash-based application, which starts Firefox with the right command line arguments.

You can download a zip with the template application, which should show the profile manager when run (assuming you have Firefox installed to the standard location).

Here's how you create this application:

1. Create a folder /Applications/FirefoxWork.app with a folder Contents inside it. (To open an *.app folder in Finder use the context menu Show Package Contents.)
2. Inside the Contents folder create a file named Info.plist (note: all names are case sensitive!) with the following contents:

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
   <dict>
     <key>CFBundleExecutable</key>
     <string>FirefoxLauncher</string>
     <key>CFBundleIdentifier</key>
     <string>com.example.FirefoxLauncher</string>
     <key>CFBundleInfoDictionaryVersion</key>
     <string>6.0</string>
     <key>CFBundleName</key>
     <string>FirefoxLauncher</string>
     <key>CFBundlePackageType</key>
     <string>APPL</string>
     <key>CFBundleSignature</key>
     <string>????</string>
     <key>CFBundleVersion</key>
     <string>1.0</string>
   </dict>
   </plist>

   (the meaning of these keys is explained in the Core Foundation Keys reference).
   
3. Inside Contents create another subfolder named MacOS.
4. Save the following to a file called FirefoxLauncher in the MacOS folder:

   #!/bin/bash
   /Applications/Firefox.app/Contents/MacOS/firefox-bin -no-remote -P work &

   Adjust the path to Firefox and the profile name as appropriate.
   Update: You may need to prepend arch -i386 to the command if you're trying to run newer Firefox (version 4 and later) on Mac OS X 10.5.
   Update 2: (thanks to Daniel Beck on superuser.com for this tip) you can use open instead to avoid hardcoding the path to the application and the binary name:
   

   open -n -a Firefox.app --args -no-remote -P work

5. Run chmod u+x /Applications/FirefoxWork.app/Contents/MacOS/FirefoxLauncher in the terminal to make the script executable.
6. Now test if the program runs by executing open /Applications/FirefoxWork.app.
• If you get an error saying "LSOpenFromURLSpec() failed with error -10810 for the file /Applications/FirefoxWork.app.", most probably the script couldn't be run - either the name in CFBundleExecutable parameter didn't match the actual script name in MacOS or the file doesn't have the execute bit set (see chmod command above).
  If you edited Info.plist, be sure to touch FirefoxWork.app to invalidate OS X's cache. 
7. Voila! You can now drag FirefoxWork.app to the dock or run the application via QuickSilver and it doesn't take a second to run the shell script.