Firefox/Iceweasel high CPU usage when idle

Firefox is called Iceweasel in the Debian SO because of trademark issues. I’ll use the name Iceweasel since that’s what I tested but everything here’s applicable to Firefox.

This came to my attention thanks to user SynrG in the #debian IRC channel. When Iceweasel is just idling in some sites it will eat an unreasonable amount of CPU time even when nothing is being updated on the screen. This was tested browsing Facebook but it’s not specific to this site. The high CPU usage went away just switching to another tab with an unaffected site open. It’s more noticeable on old hardware, like my netbook, with a fake dual-core Intel Atom CPU, it was around 100% all the time and made the computer lag. More powerful multi-core CPUs will see an inferior usage and maybe no lag but still some CPU time is wasted by Iceweasel when idle. Disabling Javascript will do nothing so it isn’t some Javascript running in the background.

The problem lies in CSS3 animations. There’s a bug in Iceweasel that makes it refresh the page even when nothing is changing whenever there’s a animation property set to an element even when the element is hidden. See https://bugzilla.mozilla.org/show_bug.cgi?id=962594.

The easy fix is disabling animations but since this can’t be done with any preference setting we need to use user styles as a workaround. This can be useful to solve the problem until this bug gets a proper fix.

You just need to put a userContent.css file in a chrome folder inside your profile folder. If you want to disable the animation property for all sites you can use these lines:

* {
  -moz-animation: none !important;
  animation: none !important;
 }

In case you don’t want to disable animations for all sites but just a few look at the following example for Facebook:

@-moz-document domain(facebook.com) {
* {
  -moz-animation: none !important;
  animation: none !important;
 }
}

More information about matching options in the MDN.

Wrong keyboard layout in RDP session over Debian GNU/Linux

I’ve started using XRDP so that my girlfriend can connect her Windows netbook to my Debian GNU/Linux box and do her work. It works pretty well, no 3D acceleration, no remote sound, but everything else is fine. I just had to fix the keyboard layout since we use the Spanish one and XRDP insisted that we should use the U.S. one.

I found this post explaining what I need to do. Basically, XRDP needs a keyboard layout map and Debian doesn’t provide one. Fortunately, creating one is easy with the following command:

# xrdp-genkeymap /etc/xrdp/km-040a.ini

The 040a code can be looked up in this page,  it’s the hexadecimal code preceding every layout name. This has to be done in a local session since it just takes the currently active layout in your X session and writes to a file.

If you’re forced to do it through RDP you have to set the right layout before writing it to the file. Try the following command adjusting parameters to your keyboard layout:

# setxkbmap -layout 'es,es' -model pc105

Next, run xrdp-genkeymap.

Done, restart XRDP.

Duplicated icons with Gnome3 and XDG menus

I’ve been using Gnome3 on Debian SID for some time now and I’ve been always bothered by the overlay view showing duplicated application icons in low-res. I’ve learnt not everyone has this problem so I had to find out the reason.

Some forum posts recommended removing the contents of the ./local/share/applications/ directory but they would come up again. Some solved it by removing the packages apparently responsible of the duplication, menu-xdg and/or menu, but that wasn’t possible in my case without removing other important packages.

What’s happening is that menu-xdg provides menu methods in /etc/menu-methods/ that convert the Debian menu to a XDG menu. These methods get executed whenever the update-menus command is run, and when it’s run by a normal user it dumps all the Debian menu into ~/.local/share/applications/menu-xdg/, not just the contents of ~/.menu.

So you shouldn’t execute update-menus as a normal user, but if you or some script already did you can solve it with:
update-menus --remove

This will remove anything created by a previous run.

You can avoid this to happen accidentally. Removing the following line in /etc/menu-methods/xdg-desktop-entry-spec-apps will make update-menus a dummy command for normal users:
userprefix = ".local/share/applications/menu-xdg";

UPDATE: I’ve reported this problem as bug 696530. Gnome packagers have already reacted by dropping the menu-xdg dependency in python-xdg so now I can remove it and everything is well. New Wheezy installations shouldn’t even get it installed.