Numbers 3.5 (iWork): Hijacks cursor keys when editing cells

Posted by Pierre Igot in: Macintosh, Pages
February 27th, 2015 • 10:41 am

On February 25, 2015, I used Bug Reporter to submit the following bug report (#19951698) to Apple:

When I select a cell and start typing, the cursor blinks inside the cell. Yet if I use the Left or Right cursor key, Numbers jumps to the previous/next cell, instead of navigating inside the current table cell.

Steps to Reproduce:
1. Open any Numbers document containing a table.
2. Select a table cell by clicking ONCE on it.
3. Start typing.
4. Press the Left or Right cursor key.

Expected Results:
I expect the Left or Right cursor key to move INSIDE the current table cell by one character to the left or to the right.

Actual Results:
The Left or Right cursor key JUMPS to the previous/next table cell.

Numbers 3.5.2.
OS X 10.10.2.

To add insult to injury, the behaviour is not consistent across iWork apps. In tables in Pages, I get the expected behaviour.

I think this report is quite self-explanatory. For completeness’s sake, I probably should have added that when, instead of simply selecting a cell in Numbers before you start typing, you double-click on the cell to make its contents editable right away, then, for whatever reason, the cursor keys work as expected.

I can see absolutely no visual difference between a selected cell that becomes editable when you start typing and a cell that becomes editable when you double-click on it. And yet, in the first instance, the cursor keys do not work as expected — they jump from cell to cell, even though the I-beam cursor is blinking in the cell — whereas, in the second instance, they work as expected — they jump from character to character inside the cell whose contents you are currently editing.

I also should have pointed out that the impact of this hijacking of the cursor keys is that it also affects one’s ability to use the keyboard to navigate word-by-word inside cells, because the shortcuts for jumping from word to word inside a cell are the same standard shortcuts as elsewhere in OS X, i.e. option-Left and option-Right. In Numbers 3.5, after you select a cell and start typing in it, if you use option-Left and option-Right, instead of jumping from word to word, the application actually gives to those shortcuts the meaning that they have when you are not inside a cell, i.e. they insert a new column to the left or to the right of the current column. (I have already written here about the idiocy of that other hijacking of commonly used keyboard shortcuts in iWork.)

And of course, the additional impact of this hijacking of the cursor keys is that it also affects one’s ability to select text inside cells, because the shortcuts for extending the selection to the left or to the right are based on the cursor keys and are shift-Left and shift-Right. In Numbers 3.5, after you select a cell and start typing in it, if you use shift-Left and shift-Right, instead of extending the selection to the left or to the right inside the cell, the application gleefully selects you out of the cell and starts extending the selection of cells to the left or to the right.

(I should also mention the shift-option-Left and shift-option-Right shortcuts, which are also affected. In that case, Numbers ignores the Shift modifier and assumes that you meant to hit option-Left and option-Right, and so it inserts a new column to the left or to the right of the current column.)

Finally, it should be stressed that, when you enter a cell by double-clicking on it, all these other cursor-key-based shortcuts also work as expected, as do the cursor keys themselves. So at least the inconsistency is consistent (although I doubt very much that this is deliberate).

To Apple’s credit, I got an answer to my bug report within 48 hours:

Engineering has determined that this issue behaves as intended based on the following information:

Yes, this is behaving as designed. In tables in Pages we are expecting a user to type more text in a cell and so we favor text navigation with the arrow keys. For Numbers, we are expecting cells to contain short bits of data, like a number in each cell, so for that pattern we use the arrow keys to navigate to the next cell. That way a user could type 1, right arrow, 2, right arrow, 3, and quickly enter values into 3 cells.

If you have questions regarding this resolution, please update your bug report with that information.

We are now closing this bug report.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

I am afraid this makes very little sense. If indeed the idea behind the hijacking of the cursor keys is to enable the user to “quickly enter values” in a series of cells, then why is the behaviour different when the user double-clicks on a cell to make it editable?

In addition, we already have long-standing shortcuts for quickly entering values in a series of cells: the Tab and shift-Tab keys.

Also, just because the bits of data might be short, it does not mean that the user is less likely to make errors in his or her text input that require small corrections, which are one of the primary uses of cursor keys!

As well, the very reason for having universal, system-wide standard shortcuts is so that people can develop “muscle memory” that enables them to use these shortcuts in all contexts without even thinking and expect them to work all the time. Any application that hijacks universal keyboard shortcuts to give them a different meaning goes against such expectations, and there is simply no way that you can reasonably expect someone who has developed such muscle memory to remember to do the non-instinctive thing when she or he is in a specific application and refrain from using the shortcuts.

Finally, if indeed the expectation is that in tables in Pages, the user will “type more text in a cell”, and therefore have even more reason to use keyboard shortcuts for text navigation and selection, why are the keyboard shortcuts for word-by-word navigation and for extending text selection also hijacked in that application? (Granted, the hijacking there is limited to what happens when you are not inside a table cell, but it’s still far too easy to think that you are currently editing a cell and accidentally use these shortcuts when you shouldn’t.)

All this is to say that I cannot help but feel that the response I got from Apple is a lie and that nobody has really thought this through. If they had really thought this through and paid real attention to the issue, the behaviour would be the same whether you enter a cell by selecting it and starting to type or by double-clicking on it.

And even if the whole thing is deliberate, I think it’s the wrong decision. The theoretical advantage to some users (who might never have heard of the use of the Tab key to “quickly enter values” in consecutive cells) is simply far too insubstantial compared to the on-going disruption caused by this hijacking of universal, standard system-wide shortcuts.

Responsiveness problems in Yosemite: Menu-delay bug caused by ‘Reduce transparency’ option?

Posted by Pierre Igot in: Macintosh
December 19th, 2014 • 7:09 pm

When I was young and careless, I used to love being an early adopter of new technology, including computer technology. This meant that I often installed new system releases as soon as they became available, come what may. I was even quite excited when I was invited to join the AppleSeed program back in the early 2000s, because it meant that I would be able to use new versions of the system even before their official release.

Well, I am now older and wiser, and, more important, I have a lot of work that I need to do with my computer, which means that I cannot really afford to be so careless anymore. These days, I am increasingly cautious when it comes to experimenting with new builds of upcoming system releases, especially major system upgrades.

So when OS X 10.10 (Yosemite) came out, I didn’t install it right away. I read about it online, which is how I discovered, for instance, that there was an option to turn off the additional transparency “features” added by Apple to OS X in this new version. I saw absolutely no benefit to this additional transparency, and to me it was just the latest incarnation of Apple’s never-ending fascination with resource-wasting eye candy, which came to the fore (in a rather painful way) in the early days of OS X and has been plaguing every version of the system ever since. So I was relieved to see that at least Apple offered an option to reduce the transparency.

When the first incremental update of Yosemite (OS X 10.10.1) came out, I decided to finally take the plunge and upgrade my system. I figured that surely the worst bugs had been eliminated by then, and that the risk was fairly minimal.

As soon as I installed Yosemite, one of the first things I did was of course to activate the “Reduce transparency” option in the “Accessibility” preference pane. After all, if the option is there, it is meant to be used, and fully supported by Apple, right?


When it comes to Apple, it seems that things are never that simple. There has undeniably been a trend, in recent years, of letting quality standards slip and shipping stuff before it is actually ready for prime time. I am afraid that Yosemite has turned out to be a prime example of this.

As I have already explained in a couple of blog posts, in my experience, on a 2014 Mac Pro with 32 GB of RAM and a 1 TB SSD drive, driving two monitors via DisplayPort (an older 30″ Apple Cinema Display with a DisplayPort adapter, and a brand new 31.5″ Sharp PN-K321 display with a native DisplayPort connection), Yosemite feels distinctly sluggish.

I find this very disappointing. I specifically bought my rather expensive computer setup (in addition to the Mac Pro and the display, I also had to buy external Thunderbolt storage, of course) in anticipation of Yosemite, with what I thought was a guarantee that I would have, for years to come, a very fast machine that would be more than capable of handling my software requirements. (I don’t really do any hard-core audio or video editing, and so in some ways the Mac Pro is overkill, but I also want a very quiet machine and I don’t think that there’s anything else on the market that beats the new Mac Pro in that respect. Right now, all I can hear is my external Thunderbolt storage — and it is moving to another room in the basement very soon.)

Whereas things were quite zippy with Mavericks on the Mac Pro (with a few exceptions), as soon as I upgraded to Yosemite, I realized that this was not an OS optimized for speed and responsiveness. Even with the 10.10.1 update, basic interactions that involve the graphical user interface (GUI), such as switching apps, pulling down menus, resizing windows, etc., are sometimes unexpectedly and unexplainably sluggish.

I don’t know for sure if this is because Apple is so focused on battery-saving behaviours these days and feels that the majority of its users are willing to sacrifice a certain level of responsiveness in exchange for extended battery life on their laptops, but right now, my 2014 Mac Pro is only my “fastest Mac ever” on paper. In practice, I really feel, at times, as if we were back to the early days of OS X, when the hardware was desperately playing catch up with the software, especially because precious CPU cycles were wasted on “trendy junk”, a.k.a. “eye candy”. (I certainly remember how the pulsating Aqua buttons and animated progress bars felt on my Mac at the time…)

If that is the reality on my Mac Pro, I simply cannot imagine what it must be on other Mac computers, which are inevitably slower than the Mac Pro at a number of things.

A lot of my computing activities involve typing text and, overall, things aren’t too bad in Yosemite in that department. But I also rely heavily on keyboard-driven OS X automation tools such as Keyboard Maestro, LaunchBar and Typinator, and since the actions that are automated by these tools involve things that are normally done visually through the GUI, unfortunately, they are affected by responsiveness issues as well.

In addition, one particular area where Apple’s engineers appear to have really messed things up in Yosemite is accessibility, a feature on which these tools rely for executing their automatic processes. Because of this, I have had to rewrite or revise several of my Keyboard Maestro macros, and I have had to try and fine-tune LaunchBar’s settings, with mixed results so far. There are still things that do not work properly at all (using automated Tab keystrokes inside Open/Save dialog boxes in Keyboard Maestro macros, resizing windows in Preview with Keyboard Maestro macros, getting LaunchBar to hide its bar once the shortcut has been triggered, etc.). This means that, overall, my work environment has lost a significant amount of polish, smoothness and efficiency, and I am forced to do more things “manually” because Yosemite does not seem to be able to keep up with these automation tools. Yes, this, even on a 2014 Mac Pro with tons of RAM and a large SSD drive, which was working fine under Mavericks.

As regular readers of this blog and my Twitter feed know, one particular issue in Yosemite has been driving me up the wall in the past few weeks. It’s an issue that specifically involves the display of menus in the operating system: displaying menus under the menu headings in the menu bar, displaying menus under menu buttons or in front of pop-up controls in windows, etc.

Probably because of all the changes that Apple has made in Yosemite, with the switch to Helvetica Neue as the system font and new transparency “features”, there are now very visible and noticeable problems with displaying menus in OS X, at least on my machine (and on the machines of several people who have responded by email to my previous blog posts to confirm that they are experiencing similar issues).

When I click on a menu heading in the menu bar, instead of drawing both the blue highlighting behind the menu heading and the menu itself instantaneously, as it used to do, OS X seems to always need a fraction of a second to do so. It’s a tiny fraction, but it’s big enough to be noticeable, and to add to the feeling that the system is sluggish and unresponsive.

(I also highlighted, in a previous blog post, the specific behaviour of the “Help” menu, where the drawing of the blue highlighting is now so visibly slow that you can actually record the “filling down” of the rectangle with blue colour in real time with QuickTime Player.)

To be true, these problems do not seem to affect the usability of the menus themselves, and their impact is mostly of a subjective and “aesthetic” nature. Things just don’t feel right.

There is, however, one particular issue that is not just subjective and aesthetic in nature, and that is the one that I have been focusing on in the past couple of weeks, because it affects the usability of the system in a very real way. It took me a while to figure out exactly what was going on, but I eventually determined the following.

From time to time, when I click on a menu heading in the menu bar (in any application) or on a pop-up menu control in a window in Yosemite, instead of OS X showing the menu right away (even with the tiny delay mentioned above), nothing happens for several seconds. There is no change to the visual aspect of the control, and there is no Spinning Beach Ball of Death either. Then, after several seconds, all of a sudden the menu appears, but it just flashes for a fraction of a second and then immediately disappears again, without letting me select a menu item in it!

I then have to click on the same menu heading or control again, and this second time things work as expected.

There is absolutely no way to predict when this will happen. Sometimes, there is also an additional (and very noticeable) delay between the time the menu is displayed under the menu heading and the time the blue highlighting behind the menu heading itself is drawn.

It also does not matter whether I just execute a simple click action (i.e. a “click-and-release”) with the mouse button or a click-and-hold action (i.e. a click without releasing the mouse button). The latter, of course, used to be the only way to pull down menus a long time ago in Mac OS. But in both cases, the problem is the same. The menu-delay/flashing problem occurs with both types of clicking as far as I can tell.

As you can imagine, this problem, when it occurs on a regular basis, is downright infuriating, especially for someone who is used to working fast, like I am. My mouse-handling skills are of course not perfect (I’m only human), but they are pretty accurate, and, while I sometimes miss my target with the mouse, it’s relatively rare, and has nothing to do with this. (Indeed, the fact that the menu does eventually pull down or pop up, even if only fleetingly, proves that I did click on the target properly.)

It also does not matter whether I use the wireless Magic Mouse or the regular (wired) Apple Mouse. They are both affected.

Since I felt that this problem was clearly unacceptable on any machine, let alone on a fast machine like the 2014 Mac Pro, I decided to do something about it, even though I knew that it would be a time-consuming process, because the bug was intermittent, difficult to describe, and hard to reproduce reliably. But, assuming the eventual success of the process, I felt that the time spent on addressing the problem was worth it, simply because there was too much at stake. (I make my living with this machine, for crying out loud. And I have to try and retain my sanity.)

As I have said in my previous blog posts and on Twitter, as an experienced troubleshooter myself, I tried all kinds of things, to no avail. I won’t go into all the details here (this post is already long enough), but when I tell you that I even went as far as to do a so-called “clean install” of Yosemite after erasing the entire contents of my startup volume, if you’ve ever done this yourself, you’ll know that I really did try everything I could think of and could be reasonably expected of me as a Mac user.

I also spent quite a bit of time on the phone with Apple Care. I ended up talking to a couple of regular tech support people, and to two different senior advisors. They were mostly kind and understanding, and got me to do things that I couldn’t have done on my own (such as letting them remote-watch my system over the Internet using Apple Support’s proprietary tools, and also running data capture tools resulting in large log files destined to be uploaded to Apple’s servers).

But ultimately the whole process was very disappointing. The key thing was to try and get the senior advisors to talk to Apple’s engineers about this, and I did achieve this, but the initial response from the engineers was more than pathetic. Believe it or not, the first thing that they mentioned about the data captured on my system was that my system was being “spammed” (their word, not mine) with error messages such as these:

Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: MySpotlightImporter:persistentStoreCoordinator unable to add persistent store coordinator - Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f81226240b0 {NSSQLiteErrorDomain=14, NSUnderlyingException=I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file'}
Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: MySpotlightImporter:importFileAtPath:attributes:type: to find object id from path /Users/original/Library/Caches/Metadata/CoreData/DVDpedia/CCCF1415-9FB0-4846-B06E-9F265CFFD005/DVD/_records/6/1/0/p1634.pedia_md_d
Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: CoreData: error: (14) I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file'
Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: CoreData: error: -addPersistentStoreWithType:SQLite configuration:(null) URL:file:///Users/original/Library/Application%20Support/DVDpedia/Database.dvdpd options:{
	    NSReadOnlyPersistentStoreOption = 1;
	} ... returned error Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8122624210 {NSSQLiteErrorDomain=14, NSUnderlyingException=I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file'} with userInfo dictionary {
	    NSSQLiteErrorDomain = 14;
	    NSUnderlyingException = "I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file’";

To them, it was somehow an indication that there might be something uniquely wrong with my system, and that it had to do with something called “DVDpedia”, which apparently they had never heard of.

DVDpedia is part of a family of applications made by a developer named Bruji, which are an excellent alternative to the increasingly bloated and underwhelming Delicious Library (a tool that I gave up on after the last major upgrade).

DVDpedia is even sold through the Mac App Store!

It boggled my mind that Apple’s engineers apparently could not be bothered to look it up and figure out what DVDpedia was themselves. And it boggles my mind that they would even think that this was the cause of my problem.

DVDpedia is a stand-alone application that manages a database containing records of one’s collection of DVD and Blu-Ray disks (using data pulled from Amazon and other sources). In my mind, there was just no way that this app could cause the responsiveness problem with menus that I was experiencing. As I told the senior advisor, I was even able to reproduce the problem on my clean install of Yosemite before I reinstalled DVDpedia (which I don’t need for my work and is only for my personal use).

In addition, while I am not a developer, I see clearly from the log quoted above that the problem involves not the DVDpedia application itself, but the mdworker process, which is an OS X process used for Spotlight indexing. How could DVDpedia even be blamed for this?

Still, to be thorough, I did contact Bruji via Twitter and their prompt answer was unequivocal:

A warning from a bug in the Apple Spotlight framework, harmless. You can delete Caches/Metadata/CoreData/DVDpedia to fix.

So there you go. Instead of taking my complaints seriously, Apple’s engineers clearly did their utmost to try and find a third-party tool that might be responsible for my problems, even after all the troubleshooting work that I had done.

Now, of course, I couldn’t rule out the involvement of third-party software in this bug entirely, especially because the bug was hard to reproduce on a clean system before reinstalling all kinds of ordinary apps (iWork, Microsoft Office, Adobe Creative Suite, etc.). But, having eliminated any software that involved kernel extensions and the like, I was finding it difficult, if not impossible, to imagine that a regular, stand-alone application with no nasty behind-the-scenes process running in the background could explain, all by itself, a system-wide bug such as the one that I was experiencing.

I don’t know if the initial response from the engineers was due to communication issues with the senior advisor or simply to a lack of goodwill on their part (I suspect the latter), but I still find it shocking that they couldn’t even look into the DVDpedia thing themselves before getting back to me with that as a response.

Nonetheless, I did turn the Spotlight indexing of DVDpedia stuff off by following instructions provided by Bruji, and produced a new set of data for the engineers to examine, presumably without the “spamming” identified above. (I don’t know where they got these logged error messages from. I couldn’t find them myself via the Console.)

But that’s all I’ve heard from engineers so far, except for a separate response from the bug report that I submitted independently, via Bug Reporter a while ago, which eventually elicited a generic “Bug report is a duplicatemessage. This might be viewed as encouraging, except that, in reality, it only confirms that I am not the only one suffering from the problem. It gives no indication of whether the engineers are able to reproduce the problem themselves or working on a fix.

Meanwhile, the beauty of the Internet is, of course, that, by talking about this on my blog and on Twitter, I managed to elicit various responses from readers. Some shared Yosemite problems that had nothing to do with mine. But other shared that they too were suffering from the exact same menu-delay/flashing problem as the one I was experiencing.

Eventually, one of those readers suggested that I try turning on the “Increase contrast” option in the “Accessibility” preference pane in System Preferences, under Vision › Display. Apparently, this was helping him alleviate the problem somewhat.

Even though the increased contrast results in a fairly ugly visual interface, I was able to confirm that, on my machine at least, it did seem to not just alleviate the problem, but actually eliminate the menu-delay/flashing problem altogether!

Since the “Increase contrast” feature actually (and logically) automatically disables the “Reduce transparency” feature at the same time, I figured that the next step would be to try and reproduce the menu-delay/flashing problem without the “Increase contrast” setting turned on, but also without the “Reduce transparency” setting turned on.

(As mentioned above, turning on the “Reduce transparency” setting was one of the first things that I did after installing Yosemite.)

That was a couple of days ago, so maybe it’s still too early to tell. But so far, with both “Reduce transparency” and “Increase contrast” off — i.e. with the default values for these settings in Yosemite, I haven’t been able to reproduce the menu-delay/flashing problem.

Then this morning I turned the “Reduce transparency” setting back on, just to see. And within an hour, I was able to reproduce the menu-delay/flashing problem once. Needless to say, I have turned it back off.

The most reasonable conclusion for me at this point is that there is something wrong with Yosemite, and that the “Reduce transparency” feature actually makes it worse, much worse. It triggers a serious responsiveness issue that has a major impact on usability, whereas with the feature off, the responsiveness issue appears to remain dormant or at least be limited to “only” a general feeling of sluggishness.

Still, I am sure that there are tons of other users who are also using this “Reduce transparency” feature, which is well documented. (I am far from being alone in finding this extra transparency totally useless and distracting, to say the least.) So, if the menu-delay/flashing problem is indeed caused by this feature, how come there aren’t more people complaining about it and bringing it to Apple’s attention?

My theory at this point, based on the multiple troubleshooting steps that I have taken, is that the severity of the menu-delay/flashing problem itself is not identical for everyone, and depends on a variety of factors, including the size and number of displays used. I have two large screens and I have noticed that the problem is less prevalent if I only use the big Sharp screen, and even less prevalent if I only use the (smaller) Cinema Display. (But it’s still there, even with only one smaller display. It’s just far more intermittent, and the delays don’t seem to be as long.) It is also possible that this problem only affects certain Mac models, including the 2013/2014 Mac Pro and also (at the very least) some MacBook Pros, possibly because they use a certain kind of video card.

I wouldn’t be surprised, at this stage, if the severity of the bug was actually proportional to the number of pixels that the video cards in those machines have to handle, and also if it was affected by some other general factors, such as the amount of RAM currently in use (because the problem is definitely more noticeable when there are more apps running, even if they are not doing anything or using any CPU power).

This whole mess also highlights a couple of significant ironies:

  • This menu-delay/flashing problem when “Reduce transparency” is on effectively means that, far from improving system responsiveness by eliminating the waste of resources for useless eye candy, this accessibility feature actually make Yosemite less responsive. (This is also why I never thought that this feature was a possible suspect in all this, and I am eternally grateful to the Betalogue reader who brought it to my attention. I don’t know where he got the idea from.)
  • It is possible that this menu-delay/flashing problem only affects a specific category of machines, which happens to be a range of pro-level machines that people buy precisely because they seek power and high performance levels. So they, like me, pay a premium for quality hardware, and now they end up being somehow punished for it!
  • Spending hours on the problem with Apple Care yielded nothing, but sharing my problems with others online enabled me to find an apparent solution by myself.

I honestly find the response I have received from Apple Care (and from Apple engineers via Apple Care) so far severely insufficient. The very fact that, aside from this particular bug, Yosemite feels sluggish, even on a fast machine, is to me an indication that Apple’s priorities lie elsewhere and that they do not take performance issues seriously enough.

I realize that these issues are hard to describe, reproduce, and observe. But with the resources at its disposal, Apple has an obligation to engage in a serious effort of improving quality control and quality assurance processes. It is simply unacceptable that such a bug is allowed to slip through.

Allowing people to use beta software is all well and good, but it’s not an excuse for not doing your own testing in-house, recreating real-world configurations (with displays of various sizes and combinations, and third-party software from all kinds of sources and in all kinds of combinations).

Also, when I see how Apple tends to responds to the bug reports that I submit either via Bug Reporter or as part of my involvement with AppleSeed, I have serious reservations about the effectiveness of their communication system.

Right now, I am beta-testing the next build of OS X 10.10.2 on a separate partition. I am not allowed to talk about features or anything like that, but there is one serious new, 100% reproducible bug (on my machine at least) that causes a kernel panic every time I trigger it. I have sent a detailed bug report about it, but because it involves my specific system configuration and a couple of third-party hardware devices (external Thunderbolt storage, which I have no choice but to use with the storage-deprived Mac Pro!), I am not optimistic that the bug will be fixed by the time 10.10.2 comes out. Maybe it will. But I won’t be surprised if it isn’t. And if it isn’t, I’ll be deprived of any further improvements made to Yosemite until Apple fixes it, which could take months.

This whole experience has been quite traumatic for me as a Mac user. The menu-delay/flashing problem was driving me insane in my daily use of my Mac, and I sure hope that switching the transparency back on, regardless of how much I loathe it, keeps it at bay permanently.

But more generally, I still find the overall sluggishness of Yosemite unacceptable. I certainly expect better performance from a 2014 Mac Pro with tons of RAM and a fast SSD. I simply should not have to wait a couple of seconds when switching apps, for instance, especially when these apps are not doing anything significant at the time.

Is there anyone at Apple who cares about all this? Anyone who has the power to do anything about it? I do not know, but this general sloppiness and the lack of transparent (!) communication when real problems occur are highly problematic. I really feel that Apple has enough money in the bank to do a much better job of supporting its Mac users and providing them with a top-quality computing experience. I really feel that, as Mac users, we have yet to see the real benefits of the great financial boom that Apple has experienced in the past ten years or so.

OS X 10.10 (Yosemite): Responsiveness problems not solved by clean install

Posted by Pierre Igot in: Macintosh
December 8th, 2014 • 10:29 am

I just don’t understand.

Last week I reported about noticeable responsiveness issues that I was experiencing with OS X 10.10.1 (Yosemite) on my 2014 Mac Pro:

  1. visibly slow drawing of the blue highlighting behind the “Help” menu heading in the menu bar;
  2. interruptions when scrolling down a Finder window with a long list of files (namely, the /System/Library/Extensions/ folder, which contains over 200 .kext files) with the Magic Mouse;
  3. recurring addition of new log files in /private/var/log/asl/ involving the sandboxd process;
  4. and, last but not least, recurring lack of responsiveness of various UI controls, including menu headings and buttons for pop-up menus.

I also mentioned that I had talked to someone (named Justin) at AppleCare, who had promised to escalate the issue if I couldn’t solve it with the usual troubleshooting steps.

On November 28, I called AppleCare again and talked to a man who seemed much less interested in my problem than Justin had been a few days before. However, to his credit, he promptly put me in touch with a senior advisor, whose name was Ben.

Ben was very nice to me on the phone and he too agreed that the problem sounded real and was not normal for a powerful machine such as my 2014 Mac Pro. However, before referring the issue to engineering, he wanted me to try one other thing, which was to reinstall Mavericks (the OS that the Mac Pro came with) on a separate partition and to check if I could reproduce my issues there.

This took me a while, because of course I had to redownload the Mavericks installer from the App Store and create a bootable USB volume with it. (Ben wanted me to use Internet Restore for this, which would have neutralized my Mac for the duration of the download, i.e. at least two hours.)

With my Mavericks partition, I was above to confirm the following:

  1. There was no problem with drawing the blue highlighting behind the “Help” menu heading in the menu bar in Mavericks.
  2. The interruptions when scrolling down a Finder window with the contents of the /System/Library/Extensions/ folder with the Magic Mouse did also occur in Mavericks, so it wasn’t a new problem in Yosemite, just one that I had not noticed before.
  3. The recurring addition of new log files in /private/var/log/asl/ involving the sandboxd process didn’t seem to occur in Mavericks.
  4. The lack of responsiveness of various UI controls, including menu headings and buttons for pop-up menus, didn’t exist in Mavericks.

In addition, through additional tests of my own, I was able to establish the following:

  1. The interruptions when scrolling down a Finder window with the contents of the /System/Library/Extensions/ folder only occurred with the Magic Mouse, and not with the old wired Apple Mouse, so it was a Magic Mouse-specific issue, probably unrelated to other responsiveness issues in Yosemite.
  2. The recurring addition of new log files in /private/var/log/asl/ involving the sandboxd process was much worse in the early build of OS X 10.10.2 that I had been testing as part of my involvement in the AppleSeed program than in the official 10.10.1 release. I still saw the problem on occasion in 10.10.1, but much less frequently. There was also no clear indication whether this had any link to responsiveness issues.
  3. The only situation where I did not see the problem with the drawing of the blue highlighting behind the “Help” menu heading in the menu bar in Yosemite was when I used the Yosemite-based Internet Restore service (while on the phone with Ben). But with all other versions of Yosemite that I tried, including on a clean partition with nothing else installed on it, I could see the problem.

Ben had given me his contact info, so I sent him an email explaining all this. At the same time, however, I stressed that the most important issue for me was that recurring, undesirable delay when clicking on various UI controls to bring down menus. Such a lack of responsiveness is unacceptable on a machine as powerful as a 2014 Mac Pro.

I am convinced that the problem is caused by Yosemite itself, and not by any incompatibility with third-party software. Since Ben didn’t get back to me right away, or even after I left a message on his voicemail a few days later, I took it upon myself to rebuild my entire startup volume from scratch.

You need to realize that this is a massive undertaking. Wiping the system volume and rebuilding everything involves hundreds of manual steps, not just to reinstall the software, but also either having to redo all the configuration of the software manually in the software itself (which involves trying to remember where you have to do to set this and that, given that settings are never always where you expect them to be) or manually copying all kinds of preference/configuration files from an backup of the old volume to the new.

But that’s exactly what I did. It took me hours, and I made sure I didn’t install anything that involved any kind of kernel extension or any other “questionable” (at least in the eyes of Apple’s engineers as I imagine them) software practices on the part of third-party developers. (This means that, even now, several days later, I am still without my beloved Default Folder X, for instance.)

It was materially impossible for me to the following:

  1. Install only one new piece of software, configure it and start using it.
  2. Continue using the entire system for several hours (if not days) with only that one new piece of software, and see if the responsiveness issue with the UI controls resurfaces.

I have far too many pieces of software that I use and need for my work to be able to do this. It would take me weeks. So, yes, I reinstalled things in batches. But I did try and do the above for the most “suspicious” pieces of software, i.e. for system-wide utilities such as Keyboard Maestro, LaunchBar, and Typinator. These particular pieces of software might be deemed “suspicious” by Apple’s engineers not because they involve kernel extensions or anything like that, but because they effectively act as an additional layer between the user and the machine, which intercepts and processes some interactions in order to automate specific actions. They are extremely important for my productivity and I cannot really imagine doing any substantial work on my machine without them.

Still, for about 48 hours I was reasonably optimistic that, through the rebuilding on my entire system from scratch, I had been able to eliminate that one responsiveness issue when clicking on UI controls that bring up menus.

And then yesterday afternoon I noticed it again. And again.

It might be deemed subtle and minor by some, but to me it’s obvious and extremely annoying. It is very simple to describe: I do a simple click (without holding the mouse button down) on a menu heading or a button in a window, and then nothing happens for two or three seconds, and then all of a sudden the menu that the click was supposed to cause to appear right away finally appears, but then immediately disappears again, before I have even had a chance to select a menu item in it.

And then of course I click on the same UI control again, and everything works fine.

I just do not understand how I can be the only one noticing this and finding it intolerable. I realize that we live in the age of mobile devices, where people “tap” instead of clicking, and are much more tolerant of unresponsiveness, because, with a finger tap, there is always a reasonable possibility that the tap was not accurate enough and that the system didn’t detect it.

But this is not the same. Clearly the system detects my click, since it does display the menu (albeit very briefly) after a couple of seconds. So the problem cannot be blamed on imperfect clicking skills on my part.

To me, it looks as if the UI control in question has been somehow “put to sleep” by the OS and take a couple of seconds to “wake up”.

Is that what is really going on here? If it is, there is no excuse for such a behaviour. On a desktop machine with an unlimited supply of power (unlike a battery-powered laptop), power-saving “features” that come at the expense of basic responsiveness are simply not acceptable, or should at the very least be optional.

Then again, my interpretation of the situation might be wrong. This particular problem might have nothing to do with power-saving features in OS X, and might be simply an unintentional bug of some kind. But if so, how come I seem to be the only one noticing it, and making a fuss about it? All I am doing is using readily available software on my system to do real-world work. If the problem was caused by a specific piece of software, I should be able to eliminate it by quitting that piece of software. But that does not seem to be the case. It seems that it is the cumulative effect of having multiple pieces of software running, even if they are not using significant amounts of CPU power, that is causing the responsiveness problem to surface.

After doing a clean install and completely rebuilding my OS X environment from scratch, how can any kind of specific software incompatibility be blamed as the source of the problem?

I also do not see how this could be a hardware issue. My Mac Pro works fine otherwise, and there are no responsiveness issues when typing text or doing other stuff that does not involve clicking on UI controls to bring up menus.

I just do not understand. And I don’t know what to do. Ben won’t respond to my emails and phone calls. Maybe he feels that, if he ignores me long enough, I will stop complaining and learn to accept the inevitability of this issue.

But I won’t. I will never find such a lack of responsiveness on my expensive 2014 Mac Pro acceptable. What recourse do I have, though? I don’t see how giving up on Apple products or boycotting them will help. I know enough about the alternatives to know that they would drive me even crazier on a daily basis. I already have to suffer through the obligation of having to use Microsoft Word for my work, for goodness’s sake. This complete piece of shit has an enormous number of responsiveness problems, even on a superfast 2014 Mac Pro, and here again nobody seems to care but me. What can I do? I have to use Word for my work. I do as much as I can to avoid it, but there is a limit.

So now I am supposed to accept that Apple is going down that same route and stuffing unresponsive software down our throats and that there’s nothing that I can do about it?

I will never, ever accept this. It is simply not right. But I do not know what else to do.

Now, if you’ll excuse me, I have work to do, and my rebuiding of my system is still far from complete and will still take me several more hours. I don’t know if you can tell, but I am pissed.

Numbers 3.5: Keeps displaying time in date cells with no time

Posted by Pierre Igot in: Macintosh
November 27th, 2014 • 4:56 pm

At the same time I upgraded my Mac Pro to Yosemite last week, I decided to upgrade to the latest versions of Pages and Numbers. Because of the disastrous changes made by Apple in Pages 5 compared to Pages ’09, I have permanently switched to Nisus Writer Pro as my default word processor, and I have no intention of going back.

However, I still have a fairly large number of existing documents in Pages format and I still have a couple of custom templates that I developed myself over the years and will need more time to rebuild using another word processor.

Also, I still positively loathe anything Microsoft, including Excel 2011, and so I need an alternative for crunching numbers. I have been using Numbers ’09 for years and do all my manual bookkeeping in Numbers ’09 spreadsheets. However, my needs remain fairly basic and I figure that support for Numbers ’09 will not continue forever. In addition, Numbers ’09 has some outstanding issues on my machine that will clearly never get fixed, including the inability to resume properly (i.e. to reopen all spreadsheets that were still open when the application was quit) after a machine restart.

(In light of its history, particularly with AppleWorks, I also don’t trust Apple to maintain backward file format compatibility forever, so I am fairly convinced that one day, it’ll be impossible to read iWork ’09 files on any current computer.)

All this to say that I have now switched to Pages 5 and Numbers 3.5. I still don’t like the fundamental changes that Apple has made to the interface. (I much preferred the flexible stand-alone inspectors to this extra column on the side.) But I guess I’ll have to live with them.

There are several new annoyances in those applications, however, and I feel that I should document the most egregious ones here.

One particular annoyance in Numbers 3.5 involves table cells that are formatted using the data format called “Date & Time”:


I often use the data format for dates illustrated in the picture above. It clearly indicates that I want to display the date in the YYYY/MM/DD format and with no time indication at all.

And yet, every time I enter a table cell in Numbers 3.5 that contains a date and is formatted using this particular data format, here’s what I get:


Numbers 3.5 correctly makes the contents of the cell editable, but, in addition to the date, it displays a value of “00:00:00” for the time, even though my data format clearly indicates that “None” for the time. (Numbers also displays the date with “00:00:00” appended to it in the “Actual” area in the status bar at the bottom of the window.)

This only affects the table cell when it’s editable, and it’s a new problem that didn’t exist in Numbers ’09. When the cell is not editable, Numbers 3.5 correctly displays the date only, with no indication of time.

But it’s a very big annoyance when editing table cells containing dates!

There are two ways to make cells editable: one is to double-click on the cell with the mouse and one is to press option-Return. Also, depending on whether the “Wrap text in cell” option (under the “Text” tab) is checked for the cell in question and depending on how wide the cell is, the “00:00:00” might be displayed next to the date on the same line or on a separate line below.

This makes it very hard to predict where the insertion point is going to end up after double-clicking on the cell. More often than not, it will end up somewhere in the “00:00:00”, and therefore force me to use extra keystrokes with the cursor keys to go to the date part in order to edit it.

When making the cell editable with the keyboard (with option-Return), things are even worse, since this shortcut automatically put the insertion point at the very end of the cell, i.e. after the “00:00:00” part. If I want to edit the date, I have to track all the way back with cursor keys or switch to the mouse.

Again, I find myself wondering: What on earth were Apple’s software engineers thinking? Or are they become so sloppy that annoyances like these are now going to be regular occurrences and take years to fix each time, like they do in Microsoft products? What on earth happened to quality control? What on earth happened to proper software testing? What on earth happened to listening to user feedback?

Like I said in a recent tweet, I am really starting to feel as if we are returning to some kind of Dark Ages of Computing. No attention to detail. Innumberable bugs. Poor performance. Etc.

The bad news for Apple is that we Mac users are acutely aware of how useful and efficient computers could and should be. The general masses of iOS users might be more tolerant and more blasé about the whole thing, but I sure hope that there still is a strong core of OS X users who care about those things and will continue to put pressure on Apple to rediscover the demanding attitude that once made it a great computing company.

Mail 8 (Yosemite): Now includes attribution at same quote level as quotation itself

Posted by Pierre Igot in: Macintosh
November 27th, 2014 • 3:37 pm

Every so often (albeit with worryingly increasing frequency these days), Apple’s software engineers make changes that make you shake your head in disbelief.

Now that I have upgraded to Yosemite (a not-too-pleasant experience), I have a fresh new batch of such changes to describe.

Here’s one that has to do with the new version of Mail included in Yosemite. As far as I can tell, when Mail is set to quote the text of the original message in replies (and also to increase the quote level of the original text that is quoted), the attribution of the quote, i.e. the top line that reads “On [date] [time], XXX wrote:” is now no longer at the root level of your reply, but at the same quote level as the quoted text that follows:


This makes no sense whatsoever. Why would the attribution look like it is part of the quoted text? It is not part of the quoted text! It is something that Mail adds automatically as a way to introduce the quoted text, and the insertion of this attribution is just a way to save you time by not requiring you to type out this attribution yourself in your reply. It is meant to read like something that you wrote, not like something that the sender of the original message wrote!

I just don’t understand how this could happen. Are Apple’s software engineers becoming blind? Don’t they care about such details at all? Do they consider that the majority of OS X users don’t care about such details either?

I do realize that the lack of universal, flexible standards for quoting text in replies has created pervasive problems in email correspondence over the years. Even in my own correspondence, I still get replies from people where there is no quote level whatsoever and the respondent has manually used a different text colour (in rich text, of course) to insert his/her reply manually next to the original text, without so much as a line break between the original text and his/her reply.

But that does not mean that I don’t care about the appropriate use of quote levels, and that does not mean that Apple should add to the confusion by misusing quote levels itself in its Mail application!

OS X 10.10 (Yosemite): Unacceptable levels of responsiveness

Posted by Pierre Igot in: Macintosh
November 27th, 2014 • 10:32 am

In the summer, I bought a new Mac Pro. My previous machine (a 2009 Mac Pro) was getting long in the tooth. It would have lasted a while longer, but then one of my screens broke and I had to replace that, so I figured that, the 2013 Mac Pro having been out for a while, it was as good a time as any to proceed with the upgrade that I had been planning to do eventually.

When I purchased the expensive new Mac Pro (along with a new screen, and Thunderbolt storage), I figured that I was making an investment for the next few years and paying for the guarantee of a high-performance machine that would be able to take full advantage of the upcoming software releases, including OS X 10.10 (Yosemite). I certainly did not expect to have to deal with a sluggish operating system any time soon.

Then along came Yosemite. I didn’t upgrade until the official 10.10.1 version came out. Last Thursday, I downloaded the OS X 10.10.1 package from the App Store and installed it. As system upgrades go, it was relatively painless. I had made sure that all my applications were up to date, and that known issues were properly dealt with. (I use Snapz Pro X for screen captures, but I can live without audio support for a little while, although the slow release of software updates by Ambrosia is getting irritating.)

After installing Yosemite, however, I immediately started noticing significant responsiveness issues. Most notably, I would regularly encounter a situation where clicking on a menu heading in the menu bar would fail to highlight the menu heading and bring down the menu itself right away. It would take a second or two, by which time my muscle memory had already taken me elsewhere, and so I would lose the focus and have to start all over again.

This was just one particular, obvious manifestation of the responsiveness problem. But it certainly wasn’t the only one. There were pervasive issues throughout the user interface and in various applications.

I did what an experienced troubleshooter would do, i.e. I tried to determine whether there were obvious culprits. I stopped using a couple of things that I didn’t absolutely need, such as Flux (which seemed to be making the problem even worse in the evenings). I cleared caches. I deleted preference files. I went through extensions, launch agents and launch daemons. I checked the system logs in the Console. I noticed a number of suspicious-looking error messages in the Console, with no indication of what I could do to stop them.

In particular, I noticed that I would occasionally get this message:

14-11-27 09:50:39,746 sandboxd[283]: ([241]) deleted(241) deny mach-lookup

along with the creation of a new log file in /private/var/log/asl/, inside a folder called “AUX” followed by the date. The log files thus created all had similar contents, always starting with:

Process:         deleted [265]
Path:            /System/Library/PrivateFrameworks/CacheDelete.framework/deleted
Load Address:    0x102062000
Identifier:      deleted
Version:         ??? (???)
Code Type:       x86_64 (Native)
Parent Process:  launchd [1]

This was still going on a week later. After some house cleaning, I thought I had eliminated the problem. And then this morning, another similar one started. This time, I still get something from sandboxd, but it involves a different “mach-lookup”:

14-11-29 14:41:10,278 sandboxd[295]: ([378]) softwareupdated(378) deny mach-lookup

Here again, each time the message appears,a new log file is created inside a folder called “AUX” followed by the date, in /private/var/log/asl/. The full logs all have similar contents, always starting with:

Process:         softwareupdated [378]
Path:            /System/Library/CoreServices/Software
Load Address:    0x107289000
Identifier:      softwareupdated
Version:         ??? (???)
Code Type:       x86_64 (Native)
Parent Process:  launchd [1]

I have no idea what it means. I was able to reproduce this problem on a clean install of OS X 10.10.1 on a separate partition, although the actual error message in the Console was, again, different in that system, and the number of logs thus created was much smaller. So there’s something going on here. However, I have no idea whether it has anything to do with the responsiveness issue.

Responsiveness issues are hard to describe. But over the past 24 hours, I have been able to identify one obvious symptom, which is 100% reproducible on my 2014 Mac Pro with a clean install of OS X 10.10.1 on a separate partition. Whenever I click on the “Help” menu, in any OS X app, the drawing of the blue highlighting behind the blue heading is so slow that I can actually see it happen in real time.

I have even been able to record the problem with QuickTime Player’s screen recording feature. Here’s the movie that I created:

And here’s a frame of the movie that illustrates the very problem I am describing:


This is a picture of Yosemite caught in flagrante delicto drawing the blue highlighting for the “Help” menu heading as a snail’s pace.

Now, I don’t know about you. But I have spent thousands of dollars on this new Mac Pro, and I certainly didn’t expect to find myself, in late 2014, repeatedly staring at such sluggishness.

Again, I can reproduce this particular problem on a clean install of OS X 10.10.1 on a separate partition. This is not something that is due to some third-party software conflict.

How can Apple’s engineers justify this? Do they really think we won’t notice? Do they really think we won’t care?

Well, I am sorry, but after having paid that kind of money for this machine, I do notice, and I do care.

Granted, this particular behaviour with the “Help” menu heading appears to be unique. I cannot reproduce the same extremely slow (relatively speaking) “filling down” of the blue background with other menu headings. But it’s just one of the most obvious symptoms of a pervasive lack of responsiveness in Yosemite, even on a brand new 2014 Mac Pro with tons of RAM and a large SSD startup disk.

Other menu headings behave somewhat better, but they still don’t feel normal to me. I quite often notice that the menu itself is drawn by OS X before the blue highlighting of the menu heading comes on. And, as I said, sometimes there is even a delay of a second or two before anything happens after I click on the menu heading.

How on earth did we get to this? How on earth can such sluggishness be deemed acceptable on such a powerful machine? I really feel that I have been had.

I might be in a minority that actually notices such things and cares about them. I know that other people are reporting even more egregious responsiveness issues. These are positively awful. My issues are not that bad. But they are still bad enough to be deemed unacceptable after having spent so much money on new hardware.

Yesterday I decided that I had had enough and picked up the phone to call Apple Care. After all, my new Mac Pro is under warranty. I was fortunate enough to get through to a nice fellow named Justin, who immediately grasped that I was an experienced troubleshooter myself and didn’t make me go through the most obvious steps, which I had already done.

He readily agreed that the type of performance issues I was describing was not acceptable for a user of a fully-decked 2014 Mac Pro. And he also fully acknowledged that having to spend hours trying to troubleshoot such issues was a waste of my time and that it was important that we came to some kind of resolution.

We tried a few things, and then we came to the conclusion that I definitely would have to try and reproduce my issues on a clean install of OS X on a separate partition. He asked me to proceed with that and set up an appointment for Apple to call me back Friday morning.

So that is what I did last night. I cursed OS X’s default behaviour, which erases the OS X installer after it’s done installing the software, and proceeded to re-download Yosemite from the App Store, which of course took a couple of hours with my 7 Mbps connection. I created a separate partition on my SSD and installed the software, which was reasonably fast. (Still, I don’t understand why the OS X installer cannot install OS X on another volume in the background while letting the user continue to use his current system on his current startup volume.)

I didn’t spend enough time on that clean partition with nothing installed to try and reproduce all kinds of responsiveness issues. But the slow drawing of the “Help” menu heading highlighting is definitely there, and that in itself is unacceptable.

I fully intend to use this particular example (and refer to this blog post) when Apple (Justin or someone else) calls me back tomorrow morning to find out what happened with my clean install of OS X 10.10.1 on a separate partition.

Will they acknowledge that there is a responsiveness issue with Yosemite? Will they try to argue that it’s “normal” for a .1 release and will be addressed eventually? I guess we’ll see. Justin promised me that he would escalate the issue if we couldn’t resolve it. I’d be really curious to have the point of view of an engineer on this situation.

That said, I want to stress that the problem with the “Help” menu heading is just one of the tips of the iceberg as far as I am concerned. I have chosen to single it out because, in my view, it’s so egregious and outrageous, and also fairly easy to reproduce (at least on my machine).

Since Mavericks was running fine on this Mac Pro (except for some more minor issues), it is really hard to imagine that there is any basis for blaming the hardware for any of this. It is so obviously a problem with Yosemite that I sure hope to be able to convince someone that something is seriously wrong and that something really need to be done about it really soon. Otherwise, I am going to start talking about asking for my money back!

OS X Tip: Better than ‘Paste and Match Style’

Posted by Pierre Igot in: Macintosh, Microsoft, Pages
November 15th, 2014 • 11:48 am

Yesterday, Jason Snell’s Six Colors web site posted a tip about using OS X’s built-in keyboard customization features to create a universal shortcut for a command for pasting as plain text.

While the tip is not useless, it neglected to mention the fact that the menu command labelled “Paste and Match Style” is not nearly as universal as it should be. For instance, Adobe’s InDesign has a similar command, but it’s called “Paste without Formatting”. In Nisus Writer Pro, the command is a subitem in the submenu “Paste” in the “Edit” menu, and it is called “Paste Text Only”.

Secondly, even when in applications where the command exists and is called “Paste and Match Style”, it does not always work as expected.

For instance, for the particular purpose that the Six Colors article mentions (converting rich-text hyperlinks to plain-text URLs), the command only works if you initially used the “Copy Link” command to copy the hyperlink in the first place. If you used the regular “Copy” command, “Paste and Match Style” is unable to convert the link into its URL. In several applications, including Microsoft Word 2011 and OS X’s own TextEdit, when my Clipboard contains a rich-text hyperlink copied using the regular “Copy” command, the “Paste and Match Style” command does not convert the hyperlink into a plain-text URL and inserts it. It simply inserts the rich-text hyperlink with the font face, size, etc. of the underlying paragraph where it is pasted.

Nisus Writer Pro’s “Paste Text Only” strips the hyperlink and simply pastes the text of the hyperlink label (not the URL) as plain text.

In fact, I am not aware of a single OS X application where using the “Paste and Match Style” command (or its equivalent) when the Clipboard contains a rich-text hyperlink copied using the regular “Copy” command manages to paste the URL of the hyperlink as plain text. The only time it works is when the hyperlink label (i.e. the text of the link, as opposed to its underlying URL) matches the URL itself.

And, as anyone who has ever received phishing spam knows, the text label of a hyperlink not always matches its underlying URL. It can actually even be a different URL!

So, outside of the situation where the hyperlink is originally copied using the “Copy Link” command, I am not quite sure how useful Six Colors’s tip actually is.

It does highlight, however, the need for some kind of universal “Paste without Formatting” command that has a consistent behaviour across all OS X applications.

After years of using various options, I now have a solution that meets most of my needs. But it relies on a couple of third-party tools: Keyboard Maestro and BBEdit.

Here it is:


As you can see, it does not rely on any application’s built-in command for pasting without formatting. Instead, it uses a couple of Clipboard filters included in Keyboard Maestro, a few find/replace operations with regular expressions, and a text factory included in BBEdit.

The first step is based on Keyboard Maestro’s built-in “Remove Styles” Clipboard filter. This removes bold, italics, font size, font face, and a variety of other rich-text attributes.

Then the macro uses Keyboard Maestro’s built-in “Trim Styles” Clipboard filter. This is primarily because of Microsoft Word’s idiotic word-by-word selection behaviour, which automatically selects the trailing space after the last selected word (unless there is a punctuation sign). Since I use word-by-word selection all the time when copying text from within Word documents, I constantly end up with an undesirable trailing space at the end of my Clipboard text. The Keyboard Maestro filter takes care of that. (It also trims spaces at the beginning of the Clipboard text if there are any, and also tabs and other types of “whitespace”.)

Then the next two steps are designed to work around another problem in which Microsoft Word’s idiotic design plays a significant role. If the text you are copying happens to be inside a paragraph formatted with bullets or automatic numbering, and if your selection includes the very first word in the paragraph, then Word also includes the bullet or automatic number formatting with the copied text.

Of course, because Microsoft’s engineers are narrow-minded and like to pretend (subconsciously at least) that Word users only ever use Word and have no need for compatibility and user-friendliness across applications, when you paste the copied text that includes the bullet or automatic number formatting in the middle of another paragraph without bullets or automatic numbering or even in an empty paragraph in a Word document, Word does not include the bullet or automatic numbering with the pasted text.

And if you use Word’s own “Paste and Match Formatting” command with such a Clipboard (which includes both the text and bullet or automatic number formatting), Word does not include the bullet or automatic numbering with the pasted plain text.

If, however, you try and paste this particular Clipboard into another application as plain text (for example, in BBEdit, or in a search field on a web page), then the bullet or automatic number will be included in its plain text form (i.e. as actual bullet or number characters, plus whatever separates them from the following text) at the beginning of the pasted text. This is extremely irritating, and I have talked about it before.

The macro above takes care of this. The find/replace operations with regular expressions remove various kinds of bullets and automatic numbering (with actual numbers or letters), as well as the extra tab character (or period plus tab character, or closing parenthesis plus tab character) between the bullet/number and the beginning of the text. (I should note that I am far from being an expert at writing regular expressions, and these might not be the most efficient way to achieve this. But they seem to be working for me.)

I have another step in the macro for removing tab characters by themselves, which I find useful in situations where the previous steps didn’t remove all the tab characters. You might consider it optional or undesirable.

And finally I have a step that uses one of BBEdit’s built-in text factories to change straight apostrophes and quotation marks to curly ones. This is because text copied from web pages and other sources often contains straight quotes and apostrophes, and the contexts where I want to use the pasted plain text usually require curly ones.

I could have used Keyboard Maestro’s own Clipboard filter for smart quotes, but it does not deal with apostrophes at all. Peter Lewis once told me, “Keyboard Maestro does not attempt to figure out apostrophes because it is almost impossible to do right.” But that’s because he’s trying to deal with the use of single quotes, which is an English-specific problem. (We don’t use single quotes in French at all, so all our apostrophes are curled to the left.)

I find that BBEdit’s text factory handles the situation quite well for me, both in English and in French.

And that’s all, folks!

Because this is a Keyboard Maestro and it’s inside my “Global” group of macros that are enabled everywhere, in all applications, I can use it in all the applications that I work with, including the ones that have their own built-in “Paste without Formatting” or “Paste and Match Styles” command. And I have now become completely dependent on it.

In fact, I even use this macro inside other Keyboard Maestro macros that I have for looking up stuff in various on-line databases. This way, I can just select whatever I want to look up in my current document, without having to worry about the cruft that might be included with the selection when it’s copied to the Clipboard, and then invoke the macro that I have to look up stuff in a particular database, which in turn uses my “Paste plain and trimmed” macro when it needs to paste the selection into the database’s search field.

Of course, my macro is not perfect. There are a few situations where it strips stuff that I didn’t really want it to strip. If I really cared, I could create another macro, with fewer steps, that only strips some of the stuff, and try and remember to use that macro in such cases. But I cannot really be bothered. I’d rather have one universal macro, with an easy one-hand shortcut, that works well most of the time, and then fix whatever needs to be fixed manually in those few cases when I need to do so.

My macro also does not address the issue raised by Six Colors, which is the extraction of the URL as plain text from a rich-text hyperlink. For that, I am afraid I don’t have an easy solution (unless the hyperlink was originally copied using the “Copy Link” command, which is not universal). I tend to do it “manually” whenever I need to. Unfortunately, in Microsoft Word, that involves taking repeated trips to the “Edit Hyperlink” modal dialog box. If I really needed to do this all the time, I would probably try to find an easier way to do it. And it would probably involve Keyboard Maestro again.

But that might be for another post, when I finally get around to it.

OS X 10.9 (Mavericks): Bug with ‘Secure Keyboard Mode’

Posted by Pierre Igot in: Macintosh
November 12th, 2014 • 10:26 am

OS X has a special keyboard mode that it switches to whenever the cursor is in a password field (in an OS X dialog, in a web page in Safari, Firefox, in apps that require password input, etc.). This mode, called ‘Secure Keyboard Mode’, is intended to protect your password input from any kind of snooping by other apps, so that your password remains secure.

In a normal configuration, you don’t really notice when OS X switches from regular keyboard input mode to secure keyboard mode or vice versa, because it’s something that takes place behind the scenes.

However, there are a number of OS X utilities that rely on the ability to monitor your keyboard typing and are therefore affected when OS X switches keyboard input modes like this. I use at least two of these apps myself: Keyboard Maestro and Typinator. The usability of these fantastic apps is totally dependent on their ability to monitor keyboard input, so secure keyboard mode definitely affects them.

Recently, I have noticed a new problem on my Mac Pro running OS X 10.9.5. Sometimes — usually in the morning, after I wake my machine from sleep and start working — I notice that my Keyboard Maestro macros and Typinator features do not work properly. Upon careful examination of my user interface, I notice this on the right-hand side of my menu bar:


The Typinator icon in the menu bar normally looks like this:


What does this alternate icon with the dots mean? Well, a click on the Typinator menu provides the answer:


The dots indicate that OS X is stuck in Secure Keyboard Mode (SKM). Normally, the switching in and out of SKM is handled automatically by OS X. As soon as you enter your password and press Return to exit the password field, OS X switches out of SKM. But sometimes it does not. As the Typinator dialog box explains, the normal trick to fix this situation is to quit the parent app of the password field that switched SKM on in the first place.

Typinator tries to help by telling you who the culprit likely is. In this particular case, it tells me it’s Safari.

The problem is that, after I quit Safari, the problem does not go away. So I try quitting other likely culprits, including Firefox, 1Password, etc. Still nothing. I try quitting and relaunching Typinator itself, to no avail. Nothing helps but a complete restart of the machine, which clears the problem.

After this happened to me a few times over the course of a couple of weeks, I decided that I had to try and do something about it. So I contacted the tech support service at Ergonis, the software company that produces Typinator. They were quite helpful, but still insisted that there was some other app causing this problem. I explained that I had not been able to identify a culprit.

Typically, I would wake my machine in the morning, start working, and then notice that something was wrong when I tried to use one of my Keyboard Maestro macros or Typinator features. The different icon that Typinator uses in the menu bar is not that noticeable, and I was not in the habit of keeping an eye on it constantly to determine exactly when it would change.

Since Ergonis thought that 1Password was a prime candidate, they even contacted the Agile Software developers themselves in order to discuss the situation. They also ended up adding a bit of code to Typinator for me that would cause it to play a special sound whenever SKM was turned on, and a different sound whenever it was turned off.

This worked great, in that it clearly indicated to me whenever SKM was turned on and then back off. But it also made me realize that there was one other context where SKM was turned on that I had not thought of: the login window when I woke my computer from sleep. (It’s configured to ask for my password after it’s been put to sleep.)

When I woke my machine in the morning, the special sound would play immediately. And then as soon as I entered my password, the sound indicating that SKM was off would play as well.

Except that sometimes it did not. Sometimes, on my machine at least, after I enter the password requested by OS X upon waking the machine, and OS X logs me in, it fails to switch back out of SKM. And sure enough, if I go to the Typinator alert about SKM right after this happens, the dialog actually correctly identifies the background process called loginwindow as the culprit. For some reason, if I don’t check the dialog right away, Typinator ends up losing track of who the culprit app is, and becomes unhelpful by blaming another app that has nothing to do with it.

Of course, I cannot remember exactly when the problem started, but it’s definitely been in the past couple of months, so I suspect one of the more recent OS X updates.

Now, the problem is that, unlike standalone apps like Safari, 1Password, etc., you cannot quit the background process called loginwindow. It’s constantly running once you log in, and the only way to force it to restart is to restart the entire computer (or possibly log out completely and then back in, which is almost as time-consuming).

I thought about it for a moment and then wondered if maybe, since it was obviously a glitch in loginwindow, I could force it to snap out of it by going through the login window again. I tried using the Fast User Switching menu to switch to another user environment and back to my regular user environment in OS X, but that didn’t help.

Finally, I simply put the computer back to sleep and then woke it up again. It asked me for my password, and voilà: as soon as I entered my password, it logged me back in and this time it switched out of SKM.

So I had, if not a fix, at least a workaround! I gleefully fired an email to Ergonis outlining my findings and thanking them for helping me identify the source of the problem with the addition of the special sounds (which I will definitely keep on). And I confirmed that 1Password was not involved at all in the problem, that it was clearly a problem with OS X itself.

Since then (that was several weeks ago), I have only experienced the problem a couple of times, and the workaround worked each time.

This morning, however, after waking my computer, I experienced the glitch again. I put my display back to sleep (using a hot corner) and woke it back up, but this time it didn’t play the special sound that indicates that SKM is on. I entered my password and was able to log back in, but SKM stayed on. (I also noticed a couple of other glitches in the user interface, but I don’t know if they were related at all.)

I tried again, but this time putting the entire system to sleep (using the Apple menu).

But when I tried to wake the system up, the screen stayed dark, and I saw a few tiny streaks of dancing pixels across it, as well as the ominous Spinning Beach Ball of Death. This time, I had obviously hit a more severe manifestation of the same bug, and I had no choice but to do a hard reboot of the machine, cursing Apple for their inability to produce glitch-free software and wasting my time with length reboots. (Even with an SSD startup volume, it takes time to relaunch everything and especially to reload every open web page off the Internet.)

I am afraid that this is where I am at now. The bug with SKM is still there, unaddressed. There’s little point in submitting a bug report to Apple, as the problem is very intermittent, and there is no 100% reliable way of reproducing it. It just happens from time to time.

Hopefully, if it happens again in the future, the workaround described above will continue to work and will enable me to avoid having to reboot. But, as I have just experienced this morning, there might be something more sinister at work here, a more serious bug of which the SKM glitch is just the milder manifestation.

I will probably upgrade to Yosemite in the coming months, and we’ll see if the problem still exists in the new OS. The best that I can hope for at this point is that Apple has somehow accidentally, unwittingly fixed it in Yosemite by updating the loginwindow process code. Who knows?

Fixing ‘Find Previous’ in Adobe InDesign CC 2014

Posted by Pierre Igot in: Macintosh
July 22nd, 2014 • 8:51 am

Following my blog post from last week (‘Find Previous’ in Adobe InDesign), I actually got some feedback from Vipul-Bansal, an InDesign engineer, on the Adobe Forums:

We had tried really hard to just provide two buttons “Find Previous” and “Find Next” but there were quiet [sic] a few design limitations because of which we can not implement it.

1) We have introduced a new search scope “To Beginning of Story” and we wanted the search scope drop down to populate on the basis of “Search Direction” i.e. we wanted to have either “To End of Story” or “To Beginning of Story” depending upon the whether the user wants to search in “Forward” or “Backward” direction. So it becomes mandatory for the user to select one particular direction and then perform the search operation.

2) Similar to the above reason it also becomes mandatory for the user to “select a direction” before performing “Change/Find” operation. And it would have been impossible if we would have provided two diff. buttons for “Find”

It has been mentioned in the shared blog post that there is no shortcut to change the Search Direction, but we have implemented it. You can use the default shortcut : Ctrl+Alt+Enter(for Win) or Cmd+Opt+return(for MAC) or you can also edit the same by going to Keyboard Shortcut>Edit Menu(Product Area in the KBSC dialog)>Toggle search Direction.

I won’t discuss the validity of the justifications given here. But it is true that InDesign CC 2014 also includes a command called “Toggle search direction” in the “Edit” menu section of the “Keyboard Shortcuts” dialog box:


I’ve assigned the command-shift-option-G shortcut to it. (It’s already assigned to a command, but it’s a baseline grid-related command that I rarely use.)

With command-G assigned to the “Find Next” command, I now use the following Keyboard Maestro macro:


Et voilà! This macro effectively switches the search direction, jumps to the previous occurrence, and then switches the search direction again. It’s simple, but it pretty much works as a way to make InDesign behave like a normal OS X application when it comes to “Find Next” and “Find Previous” keyboard shortcuts.

‘Find Previous’ in Adobe InDesign

Posted by Pierre Igot in: Macintosh
July 16th, 2014 • 8:56 am

Here’s a real-world scenario. (It’s very real in my world anyway.)

I have a 200-page document in InDesign with lots of text in various frames. I need to review all occurrences of the word “department” in this document and change some of them — but only some — to “Department”.

I cannot use a batch “Change All” command for this, even with a fancy grep pattern, because the reasons for capitalizing some of the occurrences (but not all) are too complex. I really need to review each and every occurrence individually to decide whether to capitalize the word or not.

Before InDesign CC 2014, the “Find/Change” window in InDesign looked like this:


I would start at the beginning of the document and start clicking on the “Find” button. I would examine the occurrence and, if it needed to be capitalized, I would simply click on the “Change/Find” button. This would change that particular occurrence and jump to the next one. If the occurrence didn’t need to be capitalized, I would just click on the “Find” button again (which now actually read “Find Next”).

As you can imagine, when a document contains dozens of occurrences of the same word and you have to review them all and only change some of them, the task soon becomes tedious. If the occurrences that actually need to be changed are few and far between, you naturally start clicking on “Find Next” semi-automatically, and inevitably you end up clicking too soon at times, and only realize that the found occurrence did need to be changed after you’ve clicked on the “Find Next” button and already jumped to the next one.

So what do you do then? Well, prior to InDesign CC 2014, there was no option to reverse course and jump back to the previous occurrence. The only solution was as follows:

  1. leaving the “Find/Change” window open, click back on the document window;
  2. make a generous assumption about how many pages behind the previous occurrence of the found text was, and browse back by that number of pages;
  3. click somewhere in a text frame on the page to move the cursor back on that page;
  4. switch back to the “Find/Change” window;
  5. start clicking on “Find” or “Find Next” again, going through a whole bunch of occurrences that you have already reviewed, simply because your generous assumption was too generous and you went back too far;
  6. try to recognize the found occurrence that you actually skipped over so that you won’t skip over it again;
  7. change it properly this time by clicking on “Change/Find” rather than “Find Next”;
  8. resume your review of the next occurrences.

I don’t need to tell you that this technique was completely ridiculous and highly unreliable. And yet, this was the reality in InDesign up until about a month ago, when Adobe finally released a version of InDesign (the so-called InDesign CC 2014) that featured some kind of “Find Previous” command:


Now, as you can see, there still isn’t a “Find Previous” button in there. Instead, there is a new section labelled “Direction” with two radio buttons, for changing the direction of the search. If you click on the “Backward” radio button, the “Find Next” button changes to “Find Previous”:


In other words, in the scenario outlined above, if you accidentally click one time too many and need to reverse course to jump to the previous occurrence, you can now do this:

  1. click on the “Backward” radio button to change searching direction;
  2. click on the button now labelled “Find Previous” to jump to the previous occurrence;
  3. change the occurrence properly by clicking on “Change” — Don’t click on “Change/Find”, as this will change the found occurrence, but it will also continue the search backwards and will take you to the next previous occurrence, which you have already reviewed!
  4. click on the “Forward” radio button to change searching direction again;
  5. click on the button now labelled “Find Next” again to resume your review of the next occurrences.

I don’t know about you, but I only find this marginally less ridiculous than the situation prior to InDesign CC 2014. It still involves far too many steps. It is still far too clumsy for the user to be able to develop any kind of rhythm. Yes, it is better than the situation before, but it is still far from ideal.

Why on earth did Adobe not follow the example of all the other software applications out there that have settled on the most obvious and most intuitive solution, which is simply to also include a “Find Previous” button in their dialogs that is available at all times? Who the hell gave Adobe’s engineers the idea that asking the user to manually change search direction every time he or she needs to track back was the best option?

It gets worse.

Now imagine that, instead of having to change some occurrences of “department” to “Department”, you actually have to review all occurrences of a specific text string and make edits in some of the occurrences that cannot be done through a simple “Change” operation. This is, again, a perfectly realistic scenario in my world. Natural language is such that, sometimes, edits can only be done manually on a case-by-case basis. Even a fancy grep pattern (assuming you’ve mastered the art of composing grep patterns) will not do.

In such a scenario, in order to work as efficiently as possible, you want to be able to keep your hands on the keyboard, instead of having to constantly switch back and forth between the mouse (to control the buttons in the “Find/Change” window) and the keyboard (to make the actual edits).

So what’s the natural solution here? Well, you bring up the “Find/Change” window, you enter your search string, and you start your search with the mouse. But then you close (or relegate to the background) the “Find/Change” window and you start jumping from occurrence to occurrence in the document itself with a keyboard shortcut, namely command-G, the standard keyboard shortcut for “Find Next”.

This does work in InDesign. But what if, once again, after a while the task of reviewing all the found occurrences starts becoming tedious and you accidentally press command-G one time too many, skipping an occurrence that you actually needed to edit?

Well, in versions of InDesign prior to CC 2014, there was no “Find Previous” option whatsoever, so you were stuck with having to follow the steps I described above, i.e. make a generous assumption about how many pages behind the previous occurrence of the found text was and browse back by that number of pages, and so on and so forth.

But now that we do have a “Find Previous” command of sorts in InDesign CC 2014, surely there is an easier way? I am afraid not. The only way to access this “Find Previous” command is through the graphic interface, with the “Direction” section in the new and improved “Find/Change” window. There is simply no option to do this with the keyboard.There is no “Find Previous” command in the list of commands under “Edit › Keyboard Shortcuts…” that you might be able to assign a keyboard shortcut to.

Well, let me correct this. There is a “Find Previous” command in the “Keyboard Shorcuts” dialog box:


But it’s actually the same entry as the “Find Next” command! Yes, if you leave the “Find/Change” window in InDesign in “Backward” mode, then in the “Keyboard Shorcuts” dialog box, the “Find Next” command is listed as “Find Previous”.

Needless to say, there’s no point in trying to assign a different keyboard shortcut to it, like, say, shift-command-G, which is the standard shortcut for “Find Previous” in most other OS X apps.

First of all, the shift-command-G shortcut is already assigned to the “Ungroup” command, and given Adobe’s long history of enforcing non-standard keyboard shortcuts in OS X (try typing a non-breaking space in InDesign!), I doubt very much that Adobe will ever reconsider and assign a different shortcut to the “Ungroup” command.

Most important, however, whatever shortcut you might assign to “Find Previous” in the “Keyboard Shortcuts” dialog will also be assigned to “Find Next”, since it is, in effect, the same command. It won’t help you avoid having to switch from the keyboard back to the mouse in order to change the direction of your search when you want to backtrack.

At this point, as far as I can tell, there is no option to assign a keyboard shortcut to the command for changing the search direction itself.

The way things are going, I wouldn’t be surprised if Adobe, in response to feedback about this new feature like mine (should they choose to respond), decided to simply add the option to assign a keyboard shortcut to the command for changing the search direction itself. It would still be ridiculously complicated, but at this point, I have pretty much given up on Adobe ever understanding what users in the real world face with real-world scenarios such as the ones described here actually need from InDesign — which is what most other text editors offer, i.e. a simple “Find Previous” command accessible at all times using a simple, direct keyboard shortcut, preferrably the standard shift-command-G.

Apparently, Adobe’s engineers suffer from the “Not Invented Here” syndrome and have decided that they have invented a better solution. Ahem.

Disappearing cursor in Microsoft Word 2011: Affects .doc documents only?

Posted by Pierre Igot in: Microsoft
April 16th, 2014 • 10:31 am

For years, I have been complaining about the I-beam cursor disappearing in Microsoft Word during text navigation:

Here we are, in April 2014, and the problem is still going on.

So what else can I say about it that I haven’t said before?

Well, yesterday, quite out of the blue, I decided to try a little experiment. I created a new blank document in Word 2011, inserted a text box in it, typed some text in the text box, and then tried to move the cursor around with the cursor keys. This, in my experience, would normally trigger the problem (which was happening in another existing document with text boxes that I was working on at the same time). Only it didn’t.

Why? Well, I decided to try and find out. Since the other document I was working on was a .doc document, rather than a .docx document, I repeated the exact same process, but this time saving the new document as a .doc document first. And guess what? In that document I was able to reproduce the problem by moving the cursor around in the text box with the cursor keys.

Try it yourself: In Word 2011, create a new document. Save it as a .doc document (using the Word 97-2004 document file format). Insert a text box, type some text in the text box, then press the Left cursor key to move the I-beam cursor around.

When I do this on my machine, the cursor disappears while I hold the cursor key, and only reappears and starts blinking again when I release the key.

Now, this is only one particular situation where the cursor disappears temporarily like this when moving it around with the cursor keys. There are other situations (without text boxes) where the cursor can also disappearing temporarily while typing or navigating text. But this one is a start. It’s a pretty obvious one, and it’s 100% reproducible in a brand new document, at least on my machine.

If other users can reproduce it on their machine, we now have a 100% reproducible issue and Microsoft has no excuse not to fix it. (Although I don’t expect it to make it any difference, I’ve already submitted a report using Microsoft’s feedback page. If you can reproduce the problem, please do the same. You never know.)

OS X 10.9 (Mavericks): Video corruption in Safari

Posted by Pierre Igot in: Macintosh
February 28th, 2014 • 5:47 pm

For me, the problem started as soon as I upgraded to OS X 10.9 (Mavericks). I started seeing all kinds of unsightly video corruption artefacts on web pages in Safari, like this one (click to enlarge):


The video corruption artefacts are static or sometimes “dynamic”, with actual flickering taking place in real time. (Needless to say, the problem only occurs in Safari. Chrome and Firefox are unaffected.)

At the same time, I see the following type of message in the system log:

Feb 28 16:39:26 Mac-Pro-2009 kernel[0]: Warning: IOSurface 0000002a seed changed while owned by an accelerator 00000002: 00000003 -> 00000004

The actual values after IOSurface and after the colon vary, but the message itself always follows the same model, and while the corruption is occurring, a new message appears in the log every few seconds. I might have hundreds, if not thousands of such messages in my system log on a daily basis.

I can make the corruption disappear by simply resizing the Safari window that contains. But there is no guarantee that it will not reoccur eventually in the same window or in a different window. (And that does not necessarily make the warning messages stop in the system log either, at least not right away.)

As far as I can tell (from weeks and weeks of monitoring the situation), some sites tend to trigger the problem more than others, but I get the problem with all kinds of different sites, from YouTube to Amazon to my on-line banking site. One site that seems to trigger the problem on a regular basis is the site, especially in the header area of the page:


But even on such a corruption-prone web site, I cannot reproduce the problem reliably by simply loading a page from the site. Typically, I need to load a page and then do other stuff in Safari and elsewhere. Eventually, the video corruption starts happening. It’s the same for other sites where the corruption occurs. It just seems to happen more readily with the web site.

Needless to say, such a “scenario” for reproducing the bug is not particularly bug-report-friendly. My experience with Apple is that they only really pay attention to bugs that they can easily reproduce. This bug apparently does not qualify.

A while ago, I noticed that one page in particular on the web site with an embedded Vine video triggers the video corruption systematically:


On my machine at least, in my regular user environment, it is still happening as we speak. The video corruption is limited to the side bars on both sides of the video, but I definitely get it every time I load the page.

Resizing the Safari window clears the video corruption (most of the time). But reloading the page makes it reappear.

I posted about this both on the AppleSeed forums that I contribute to as part of my AppleSeed membership and on my Twitter feed.

No one else in the AppleSeed forum seems to be able to reproduce the problem at all, which would seem to suggest that it is limited to certain hardware/software configurations.

The main thing that I can think of when I review my own configuration is that it might be related to my use of an ATI Radeon 5770 video card to drive my main display (a 30” Apple Cinema Display). I have a second 30” Apple Cinema Display driven by a separate GeForce GT 120 (one of the two OEM cards that came with my custom-order 2009 Mac Pro), and I haven’t noticed the corruption in Safari windows located on that second screen.

I’ve tried all kinds of things to eliminate possible software incompatibilities. The most conclusive thing that I have been able to do so far is that I can definitely reproduce the same video corruption on that page in Safari 7.0.2 in a separate user environment that I use for testing purposes, which has very few customizations and background applications running. It has no Safari extensions and no plug-ins other than the ones included in OS X.

On the other hand, I cannot reproduce the video corruption on other sites (such as the web site) as easily in that separate user environment. Admittedly, I haven’t spent hours trying to do so, but the video corruption definitely appears to be easier to reproduce in my regular user environment, with all kinds of Safari extensions and also all kinds of other applications running in the background.

I have also noticed that trashing the preference file and relaunching Safari appears to help alleviate the problem, at least temporarily. But it’s definitely not a permanent fix. (The corruption comes back eventually.)

One fellow Twitter user has responded that he sees the video corruption on the web page on his machine as well, which is not a Mac Pro — it’s a Retina MacBook Pro — and does not have an ATI Radeon 5770 card, so the problem does not appear to be strictly limited to the Mac Pro and to the ATI Radeon 5770 card. But clearly, since it does not seem to have come on Apple’s radar yet (in spite of my detailed bug reports), it is not a very common problem.

The irony here is that the main reason that I have an ATI Radeon 5770 card in my Mac Pro instead of the second GeForce GT 120 that I originally used to drive the 30” Apple Cinema Display is that there is (was?) a serious bug in OS X 10.8 (Mountain Lion) that would cause frequent and uncontrollable kernel panics on my 2009 Mac Pro with two GeForce GT 120 driving two displays. Now, that particular problem was definitely not limited to me, and many other Mac Pro users with dual monitors had the same issue. There again, it took so long for Apple to even acknowledge the issue, and the kernel panics were so disruptive, that I ended up purchasing and using the ATI Radeon 5770 card as an expensive fix for the problem.

Based on what I have heard since, it appears that Apple did finally fix the problem in a OS X 10.8 update (and presumably the bug did not persist in 10.9), but I have not bothered to dismantle my Mac Pro in order to uninstall the ATI Radeon 5770 card and reinstall the second GeForce GT 120 (which I have kept), in order to confirm myself that the kernel panics are a thing of the past and that OS X 10.9 runs fine on a 2009 Mac Pro with two GeForce GT 120 cards driving two 30” Apple Cinema Displays.

There are a couple of reasons that I have not done this. First of all, while annoying, the video corruption problem is not bad enough to make me give up. It is definitely not in the same league as the very disruptive kernel panics I used to have with the two GeForce GT 120 cards. And the ATI Radeon 5770 card has twice as much video RAM (1 GB) and provides a small, but not insignificant performance boost in OS X. Now that I am used to it, I don’t really want to switch back to the GeForce GT 120 and experience a noticeable degradation in performance in OS X 10.9. It’s already bad enough that OS X 10.9 has significant responsiveness issues on my 2009 Mac Pro (probably due to its power-saving features, which are fairly irrelevant on a Mac Pro, but cannot be completely turned off) compared to OS X 10.8. I don’t want to see my machine’s performance even further diminished by a video card downgrade.

But clearly the problem is limited to one or several specific video cards and does not affect the vast majority of Mac users running OS 10.9. Once again, it appears that I find myself in an unfortunate minority of users affected by a real problem that is not big enough for Apple to address it in a timely fashion. (It started as soon as I installed Mavericks, back in October 2013, so I have already lived with it for more than four months.)

So, what to do about all this? I have already done all I can do to try and provide Apple with reproducible scenarios. If they cannot be bothered to procure a 2009 Mac Pro customized with an ATI Radeon 5770 card (which used to be sold by Apple itself as an Apple-blessed upgrade for the Mac Pro; the Apple Store no longer carries it, but you can still find it at Amazon, for example) to reproduce the problem that I describe in my bug reports, then what else can I do?

All I can think of is some kind of attempt to find fellow Mac users affected by the same problem. There is more strength in numbers… So this blog post is an attempt to do just that. If you are experiencing similar problems (video corruption in Safari in Mavericks, not application crashes), I’d love to hear about it. Feel free to contact me using the contact information in the sidebar on the right.

OS X 10.9’s Finder: Wrong text colour in selection highlighting in list view

Posted by Pierre Igot in: Macintosh
February 15th, 2014 • 3:02 pm

Ever since I installed Mavericks last fall, I’ve been trying to find a way to reproduce a problem that I was seeing with the Finder using the wrong text colour for the highlighted item in a Finder window in list view:


The dark green is my custom selection colour (instead of the lighter sky blue that OS X uses by default). But the text colour itself is definitely wrong. Normally, the text colour for a selected item should not be black, but white:


So clearly something is wrong here. But how does it happen?

Well, I have now come up with at least one scenario that enables me to reproduce this bug on my system reliably:

  1. Open a Finder window in list view and select one item in the list, so that its background colour is the selection highlighting colour and its text colour is white. Make sure the Tab Bar is visible.
  2. Open a new Finder window. Make sure the Tab Bar is visible.
  3. Drag the tab from the new window onto the Tab Bar of the window that contains the list view, and drop it. This will add the new window as a second tab in that same window.
  4. Now click on the small “x” button in the new tab to close it.

The result? Mavericks’s Finder reverts to show the window with a single tab containing the list view. But now the text colour for the selected item is black!

There might be other ways to reproduce this problem, but this definitely works for me. And this particular problem illustrates a long-standing issue in OS X, which is that list view tends to be treated as a second-class citizen. I’ve written about this in the past, referring to various bugs in OS X’s Finder that are list-view-specific.

Just last month, I wrote about an inconsistent and nonsensical selection behaviour when deleting files — and guess what? It affects Finder windows in list view.

This also illustrates Apple’s increasingly poor record when it comes to paying attention to details. The Tab Bar is a new feature in Mavericks, so of course, like any new feature, it was bound to introduce new bugs. But this particular one is pretty obvious if you use the Tab Bar in combination with list view windows. I myself noticed the problem in the first few days after I installed Mavericks. What took me time is to find a 100% reproducible scenario, so that I could submit it as a bug report to Apple.

What I would have expected from Apple is that their own engineers would use the new Tab Bar in Mavericks on a regular basis, including with Finder windows in list view. Then surely they would notice the inconsistent text colour and wonder what was going on. Apple shouldn’t rely on end users to figure out what the scenario is that triggers the problem.

Yet as far as I can tell, it’s exactly what’s going on. Either that, or they are aware of the bug and its cause and just think that there are other, more important things to fix first. But Mavericks has been out for a while now. Surely someone can devote a few man-hours to fixing this now.

Bug report filed.

Mail: Unable to update thread heading automatically

Posted by Pierre Igot in: Mail
January 25th, 2014 • 4:45 pm

Generally speaking, I don’t loathe OS X’s Mail as an email client like other people do. Yes, it does have a number of issues, including several that I have talked about myself on this blog. And I sure do wish that Apple would do something about them.

But on the whole I find that Mail is a decent application. I’d like to use a more robust third-party email client, but I have yet to encounter one that really meets all my email needs. (I absolutely need the ability to apply rules to messages, especially for text or background colouring, and I also rely on the third-party MsgFiler tool for filing messages away, so I would need something similar.)

That being said, there are bugs and flaws in Mail that really make you feel like Apple’s engineers are not really paying attention (or don’t really care).

For instance, I like to keep messages in my inbox organized by thread. This means that, as soon as I have more than one message that are part of the same exchange in my inbox, Mail displays a thread heading with a small number indicating the number of messages in the thread and a triangle that lets me expand/collapse the list of the actual messages in that thread:


When you select the thread heading itself, in the main area of the mail viewer window, Mail displays the entire conversation, including not only the messages received in your inbox, but also your own replies in the Sent mailbox (or in other mailboxes if you have filed them away). This is quite useful to get an overall view of the conversation. (Your replies are not included in the message count, however, and are also not moved automatically when you move the thread itself.)

The tricky part is that, except for the number and arrow, a thread heading looks like any other email message. It has a sender and a subject line. And there are problems associated with both of those. But today my focus is on the sender. If the thread consists of a series of messages between you and a single other individual, there is no problem. The sender is always the other person and does not need to be updated as new messages in this thread arrive in your inbox.

But what if the conversation is between several people? Mail keeps those organized by thread as well, but of course the sender line in the thread heading cannot display all the senders in the conversation. So what does it do? Normally, it displays the sender of the most recent message.

Consider this situation, however (names truncated for privacy):


Here, we have a thread with multiple participants, i.e. multiple senders. The thread heading at the top has the bullet that clearly indicates that there is a new, unread message in the thread. And yet, the sender is clearly not the sender of that latest, unread message (“Christ…”). It is the sender of the previous message in the thread (“Jeff and…”).

I don’t know about you, but I find this highly problematic and misleading. The thread heading clearly gives the impression that there is a new, unread message from “Jeff and…” when there is not.

Eventually, once you select something else and then come back to the thread, Mail does sort itself out and updates the thread heading to reflect the sender of the most recent addition to the thread. But it clearly does not do that automatically when receiving the new message — whereas it does automatically add the unread bullet to the thread heading.

It’s a rather irritating bug, which has, on more than one occasion, caused me to fail to notice some new messages, especially since the automatic selection of the next message when deleting or moving a message often causes the unread bullet to be removed even when you don’t want it to be.

And I believe that it is quite clearly a bug in Mail. I’ve reported it to Apple, but I have yet to receive a reply.

Finder: Inconsistent and nonsensical selection behaviour when deleting file

Posted by Pierre Igot in: Macintosh, Mail
January 25th, 2014 • 4:09 pm

In OS X 10.9 (Mavericks), take a Finder window in list view and select a file in the list:


Now press command-Delete to delete the selected file. Here’s what happens:


The Finder automatically selects the next file in the list. This is important.

Now undo what you just did and, instead of pressing command-Delete to delete the selected file, just drag it to the Trash icon in the Dock.

Since dragging a file to the Trash is equivalent to deleting it, the selection behaviour in the Finder window should be the same, shouldn’t it?

Well, it’s not. If you drag the selected file to the Trash, OS X deletes it and plays the sound effect for deleting a file, but it fails to select the next file in the list.

This seems inconsistent to me. So I submitted a bug report to Apple about it. And after a few days, I got the following response:

After reviewing your submission engineering has determined that the behavior you reported is currently functioning as designed.

In other words, according to Apple, this inconsistency is “by design”.

This does not make much sense to me. First of all, deleting a file is deleting a file. It shouldn’t matter whether it’s done with the keyboard or with the mouse.

For completeness’s sake, I also tried with the “Move to Trash” menu command in the “File” menu (or in the contextual menu when right-clicking on the selected file) for which command-Delete is the shortcut, and using the menu command triggers the same selection behaviour as the keyboard shortcut, i.e. OS X’s Finder automatically selects the next file.

Now, one could argue that drag-and-drop with the mouse is not strictly equivalent to using a menu command or a keyboard shortcut. After all, the mouse pointer is moving in a 2D space and the user might have a different focus, where list order and selection is less important and spatial location on the screen is more important. I suppose that is how Apple’s engineers rationalize this.

How do they explain, however, that the situation is markedly different in OS X’s Mail?

In Mail, when you select a message in the message list, you can delete it by pressing the Delete key, you can right-click on the selected message and select the “Delete” menu command in the contextual menu, or you can also drag the selected message to the Trash mailbox in the list of mailboxes on the left:


And get this: no matter which method you use to delete the selected message (menu command, keyboard shortcut or drag-and-drop), Mail automatically selects the next message in the list.

Why the difference? What justifies selecting the next message in Mail in the list when dragging and dropping a message to the Trash, and not selecting the next file in the list when dragging and dropping a message to the Trash in the Finder?

I suppose — this is pure speculation, of course — that Apple’s engineers might argue that, in Mail, even when dragging-and-dropping messages, you are not really in a completely spatial environment, since the only possible destination of the dragging in the list of mailboxes, which is a restricted 2D destination space. And there is nothing that you might want to do other than select the next message, whereas in the Finder there are all kinds of things that you might want to do.

But really? Is that enough to justify such an inconsistency?

To make matters worse, try the same thing in the Finder with a Finder window in list view sorted by Date Added. To me, the addition of the “Date Added” column in Lion’s Finder back in the day was a terrific improvement. It’s particularly useful for the “Downloads” folder, but also for all kinds of other folders where you keep adding more files every day.

So I use this column and this sort order quite often in Finder windows in list view. Now, if you have a Finder window in list view with tons of files in it sorted by Date Added, the Finder can only display a limited number of items in the list at any given time. Say your list is sorted with the most recently added items at the top. Select one of these items at the top and drag it to the Trash.

What does the Finder do? Not only does it not select the next item in the list (by Date Added order), but also, for some strange reason, it scrolls all the way down to the bottom of the list, i.e. to a file that you might have added a very long time ago.

This is an extremely irritating bug (surely there is no rational explanation for this scrolling), and I included it in my bug report. Yet, once again, the only answer I got was that the behaviour was “as designed”.

This is very frustrating. It’s all the more frustrating that everything that I have said so far applies not only to trashing files, but also to moving files around. Just like moving a file to the Trash, moving a file to a different folder (in another window) with drag-and-drop fails to trigger the automatic selection of the next item in the list and, if your list is sorted by Date Added, OS X automatically scrolls down all the way to the bottom.

It is completely nonsensical and, based on the response I got from Apple, we might have to live with this inconsistent and absurd behaviour for many years to come. It’s hard not to be discouraged by this.

To be honest, it is the spurious scrolling in lists sorted by Date Added that initially prompted me to submit a bug report to Apple. So maybe I should have restricted my bug report exclusively to this aspect of the problem, and not questioned the inconsistency between drag-and-drop and the other methods as well. I might just submit a new bug report exclusively on the spurious scrolling, and see what happens. But really, I expect a bit more understanding on the part of Apple’s response team, and I expect them to be able to distinguish between the two issues (the general inconsistency, and the scrolling behaviour in lists sorted by Date Added) themselves, without requiring me to submit a new bug report.