Category: Bug

Opera 12: new version, new esoteric bug

I’m taking the time to document the obscure bug that I often experience with Opera 12 (like every other day since I installed version 12 on the day it was released).

It is a surprising bug to say the least, not too annoying (as you’ll understand, Opera quickly recovers from it), but still, I reported it (DSK-367824).

[Update 2012-06-26: This is a duplicate of DSK-365797]

For no good reason that I can see or that console logs can explain, Opera actions are suddenly mapped to others, regardless that I use their keyboard shortcuts or that I click commands in the menus. When this happen, I feel like Opera is in play mode (like it’s a software thing to replace commands with other actions!).

For example, I want a new tab but get the window to “Open…”. The first time that occurred, I thought “aha! so I need to press cmd-o if I want to get a new tab.” Nope, all I got was the “Save As…” window. In play mode, it’s “Save As…”, or cmd-s, that will open a new tab. Consistently. Except that I don’t know what triggers play mode.

I played as long as I could, it was entertaining. The play-mode key-combos I found are:
cmd-t (for new tab) == open file
cmd-n (for new window) == save-as
cmd-s (to save) == new tab
cmd-c (to copy selection) == fullscreen
cmd-v (to paste selection) == right click
cmd-w (to close tab) == game over, it does cmd-q (to quit).

A couple tips, troubleshooting a bug in Opera menus

Before I forget and in case I need it later.
A bug in Opera 11.61 I submitted in February [DSK-357462] (that apparently others with similar configurations can not reproduce) still occurs in Opera 11.62. So I looked at other possible causes for that peculiar bug.

The bug is in any menu of Opera, any drop-down list and any right-click menu. When the menus appear, selecting through them is slow at best, and doesn’t apparently work at worse. I can click several times and sometimes forever on an item in the list, it’s as though the state doesn’t change, or takes a while to actually select. I click outside of it to make it disappear and it just stays there until I click either outside of the Opera window, or sometimes (not always) until I hover the mouse over it and then click outside of it, inside the Opera window.

I needed to find when I last performed software updates. Karl gave me this tip:

cat /Library/Receipts/InstallHistory.plist

This is much more accurate than my intuition to search in the console (there is entirely too much info there, and this would take much longer) or looking in the Applications folder and find a common date for “Date Modified”.

This allowed me to check that a few days prior to my noticing the bug, I had performed the “Mac OS X Update Combined” (10.7.3). This was later followed by a “Mac OS X 10.7.3 Supplemental Update”.

Then I needed to assess whether my usage of Opera could be a factor. I typically run it several days or weeks without quitting it. I operate with 1 or more windows and the number of tabs I keep open is around 90. Opera is also my Mail User Agent, has been for years and as such its mail database indexes more than 133K messages (I archived once in 2004, but then I became lazy).

I performed two tests.
The first on my other computer which has the same OS as my work laptop and the same Opera version (the processors are different but I don’t suppose the test is invalid). My opera session on that other computer has an empty mail database and I ran it with one tab. Menus were reactive as expected and selecting through them was smooth and gratifying. I opened several other tabs and I had the same positive experience.
I performed the second test on my work laptop and started a new Opera session with one tab and then a few. I was happy to experience smooth and reactive menu action. Happy and frustrated at the same time.

So maybe there is something in the early February Mac OS 10.7.3 update that impacts Opera to some extent. And if Opera couldn’t reproduce the bug to fix it in 11.62, it may be useful to give them extra info on that bug.

Another good tip, via Dean, was to run in the Terminal:

sample Opera

And perform any menu action for it to dump an “Analysis of sampling Opera (pid xxxxx) every 1 millisecond” in a text file. The blitz sampling, which lasted a fraction of time, analysed me right-clicking on a link in a Web page and clicking on “copy link address”, and wrote 21K lines, hardly any of them making sense to me. I sent it to Opera to accompany my February bug report.

Then I went back to my habitual session, bookmarked for good as many tabs as I could and tried with a 28-tab session. Same frustratingly slow menu actions. Oh well. I need them all (I need more of them in fact) to work, they’re my work flow. I hope this is fixed some day.

Opendirectoryd crashes

I was unlucky enough two months ago to start to experience loss of my (computer) identity, occasionally at wake froms sleep. My computer terminal would show “I have no name!” in the prompt instead of my user name, would claim that I am 501, when it should say I’m koalie. Of course, ssh would not want me, telling me to go away as I don’t exist. So I rebooted a couple time and grumbled a lot.

Vlad suggested something was wrong with LDAP and my colleague Thomas diagnosed that opendirectoryd was crashing. All true.

It happened again tonight and Vlad found a way to restart opendirectoryd (in Terminal.app): 

sudo launchctl
stop com.apple.opendirectoryd

Which restarts opendirectoryd.

I’m none the wiser on what triggers the opendirectoryd crash at wake from sleep. But I’m glad this works when the crash happens.

Update: The above doesn’t always work. Actually, it may have worked just once. Since then, I’ve experienced silent opendirectoryd crash, and no sudo worked, neither some kill -9. Only a restart can fix it.