January 2006

Phantoms & Ghosts on my LCD

With recent events concerning the stability of my hardware I'm a little careful now whenever I see something strange or unusual... A few days ago I had a déjà vu on the LCD screen of my 20" iMac G5 (rev. B "ALS"). I looked at a browser window that displayed a dotted yellow line - and when I looked a little to the right, I saw a line of faint dots, too:

When I place a window with a dotted line like above on certain areas of the screen, these shadows or phantom images are absolutely reproducable. This seems to be a problem of the screen itself, not one of the graphics card or the video ram - because the phantom dots do not appear on screen shots (I had to take a photo to depict the shadow line).

Now, is this a common effect of LCDs? Or is this something to be afraid of, a first sign of a decaying screen? Well, we'll see, maybe time (or Google) will tell. But fortunately, this time I've got AppleCare.

iCab 3.0.2 Beta 386 in Session

The first iCab beta version in 2006 offers the option to save all open documents automatically (and restore them the next time iCab is started). It's called "auto-save session" and you'll find it at the end of the "File" menu. Oh, yes, and "Digest Authentication" is supported, finally. Other new features and fixes since beta 382 include:

• Workaround for JavaScript code which generates invalid HTML code with missing but required end tags like </SELECT> and which ask for these Elements to modify them again in the same JavaScript call.
• Better recognition of RSS feeds where the server sends a wrong "Content-Type"
• The "Content-Disposition: attachment" HTTP header will now force a download.
• Fixed a small memory leak.
• Fixed a problem when disabling StyleSheets via JavaScript.
• Small modification for the "Flip4Mac" Plugin (for WMV files). This plugin treats the origin setting slightly different than the other browser plugins, which caused WMV files to be displayed shifted to the bottom and to the right.
• Small modification in the JavaScript property "navigator.appVersion" to prevent that "iWeb"-generated web pages treat iCab as Internet Explorer for Windows when iCab uses its default identity setting. "iWeb" rearranges its code when it encounters the browser IE for windows and this would make some images invisible in iCab. With this modification iWeb sites will now work with the default identity as well, so there's no need to change to the "Firefox" identity.
• When HTML "block" elements were nested in HTML "inline" elements (which is invalid), the "clearance" of floats could fail in certain circumstances.
• Fixed an issue with receiving gzip-compressed data from the server.
• When JavaScript code created lists using the W3C-DOM, the list item bullets were not initialized correctly.
• If JavaScript code created a new SCRIPT element to dynamically load a new external JavaScript file, iCab didn't load this file.
• If JavaScript code removed the text of an OPTION element, iCab could crash.
• Fixed an issue with the history menu. If a submenu of the history menu contains more than 400 items, iCab didn't list the newest items anymore.
• "about:"-URLs will no longer used for the URL completion.
• Fixed a small issue in the CSS properties min-width/max-width/min-height/max-height
• If a web page contains the BODY or HTML tags many times (which is invalid) nested deep insider other tags, there were some layout issues.
• An IFRAME document could not retreive the NAME attribute of its own IFRAME tag.
• The option "Always show Scrollbars in Frames" will now also enable scrollbars in popup windows which are opened by JavaScript code and where the scrollbar is switched off by the JavaScript code, even if the whole content can not be displayed without scrollbars.
• Added some new workarounds for some new invalid HTML code on the Apple web page.

Alexander also mentions one special OS (Carbon?) bug that he's fixed (or found a workaround for):

• Because of an error in MacOSX (at least in MacOS 10.3.x and 10.4.x) when retrieving the location of the temporary items folder, iCab sometimes get an invalid folder information from the MacOSX and so downloads may fail and displaying a web site could result in only displaying an error message "-43" (in very rare conditions the MacOSX seems to put an invalid folder references into an internal cache and if an application asks for the temporary items folder it will get the invalid data from this cache. And because the MacOS seems to never update its cache when after gets corrupt, the only fix is to relaunch the application. This error is so rare that most users probably have never seen this so far).
  iCab tries to find out if this error occurs and then will try to find an alternative folder for its temporary files. But this did not always work in the past. Now iCab should work much better in this error condition. But to get some additional information, iCab will now display some debugging messages in its Console window (can be opend from within the "Tools" menu) when it find out that MacOSX starts to return invalid data about the temorary items folder. In case you notice some output about "LTemporaryFileStream" in the Console Window please send this output to <support ät icab.de>. In case you see an error -43 message in the browser window when loading a web page (which shouldn't happen anymore), please open the "Console" Window and send me its content as well.

JavaApplicationStub

Java applications can be launched like native Mac OS X applications if their bytecode (usually a JAR archive) is packaged as a Mac OS X application bundle. The actual launch code is a native executable, usually called JavaApplicationStub, that's placed in Your.app/Contents/MacOS/ (if you want to use a different name for the stub file, you'll have to change the value of the CFBundleExecutable key in Info.plist, too).

The stub file changed from Java release to Java release, and unfortunately some stub versions have been more capable of launching Java applications on various system versions than others. Just recently, after updating to QuickTime 7.0.4 on Mac OS X 10.3.9, certain old stub files refused to launch Java applications any more (the fix is easy: just copy a current stub file from /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/ to your affected application bundles).

These problems led to a discussion on Apple's Java developer mailing list on how to ensure that always the latest stub version is used. We came up with the following solution: Don't use a copy of the stub file in your application bundle, but a symlink (not a Finder alias!) to the system's current stub instead:

ln -s /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub PathToYour.app/Contents/MacOS/JavaApplicationStub

The solution has a little drawback: You cannot use a different name than JavaApplicationStub, which makes it hard to tell different Java processes apart in a Unix shell (the Finder uses the bundle name from Info.plist, which can still be whatever you want, so this seems acceptable in most cases). And of course, the symlink will break if Apple decides to change the framework structure some time. But until now, the framework structure has proven to be more stable than a copy of the stub file itself, so the symlink is likely the most elegant solution to always use the latest stub in your Java application bundles.

[Update] There have been reports that this approach does not work as expected - you cannot use more than one Java application that uses the linked stub at the same time... So it seems we'll have to wait for Apple to provide a reliable solution.