as referenced @ https://bugzilla.mozilla.org/show_bug.cgi?id=567746 with Firefox ver >= 3.6.x on OpenSUSE 11.3, either native (@mozilla) or from repos (@opensuse), menu actions (@ toolbar, at bookmarks, @context menu, @ submenu ...) have a delayed response/action of ~5 secs -- if libcanberra is installed, but pulseaudio is missing: (1) no canberra, no pulseaudio ---> NO menu delay (2) with canberra, no pulseaudio ---> 5+ second menu delay (3) with canberra, with pulseaudio ---> NO menu delay it's been suggested that this is not an issue with firefox code, but rather with libcanberra code, and misselection of the optional pulseaudio dep instead of available alsa. i've provided debug info, stepwise reproducibility, etc @ the original bug. will provide add'l info here as requested -- i'm not sure what'd needed. a possibly (?) relevant comment @ #opensuse-gnome, <wolfiR> dev001: the delay happens with every menu action? <dev001> wolfiR: yes. @ toolbar, at bookmarks, @context menu, @ submenu ... <wolfiR> dev001: I see the difference with FF 3.5 <-> 3.6 that there is EVENT_MENU_POPUP in 3.6 which wasn't in 3.5 <wolfiR> dev001: that might explain the difference between both version [09:00] <wolfiR> dev001: still doesn't explain why it happens at all
fyi, FF EVENT_MENU_POPUP code: http://mxr.mozilla.org/mozilla1.9.2/source/widget/src/gtk2/nsSound.cpp#441
Sounds like a brokeness in OpenSUSE. If PA is not running and autospawning is not enabled, then an immediate error is returned in libcanberra, nothing timeouts. If autospawning is enabled then a PA instance is attempted to be spawned, but that too doesn't really timeout. My guess is that this is some kind of DNS timeout, because for some reason the AF_UNIX transport is bypassed? But anyway, this is not really a problem of libcanberra, nor of PA, and I am pretty sure it's just misconfiguration of opensuse. (And on Fedora this works completely fine) Closing. Please bring this to the attention of your distributor, thanks.
Created attachment 37960 [details] output of: strace canberra-gtk-play --id=login
per request, repeat with add'l flags, strace -o tmp.txt -f -tt -T canberra-gtk-play --id=login i see a Timeout, and 5+ second 'delay': ... 27164 12:06:38.804717 poll([{fd=6, events=POLLIN}, {fd=8, events=POLLOUT}], 2, 5000) = 0 (Timeout) <5.005109> 27164 12:06:43.809956 close(8) = 0 <0.000039> ...
Created attachment 37961 [details] output of: strace -o tmp.txt -f -tt -T canberra-gtk-play --id=login +- ~100 lines around the 'delay'
27164 12:06:38.804645 connect(8, {sa_family=AF_INET6, sin6_port=htons(4713), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress) <0.000021> 27164 12:06:38.804717 poll([{fd=6, events=POLLIN}, {fd=8, events=POLLOUT}], 2, 5000) = 0 (Timeout) <5.005109> 27164 12:06:43.809956 close(8) = 0 <0.000039> Those are the three interesting lines: we try to connect to localhost on port 4713, and that times out. Normally this should immediately return with an ECONNREFUSED. There's some kind of fw running i'd guess that blocks IPv6 even for local communication. Try "iptables -L -v -n" to see if there is some kind of fw running, and fix your fw.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.