This has been fixed upstream ages ago, how come the fix never made it to Ubuntu? I’m using up-to-date Precise and this is still an issue: scrollwheel still browses between pictures instead of panning the current picture.

Steps to reproduce:
0. Set up Chromium/Firefox to prompt when it’s not the default browser (e.g. for FF, set browser.shell.checkDefaultBrowser to true)
1. Create/save a file with .html extension
2. From Nautilus, open the file’s properties
3. On the Open With tab, select gedit as default application to open html files with
4. In System settings, select Details and verify that in Default Applications the Default Web Browser hasn’t changed
5. Start Chromium/Firefox

What happens:
The browser thinks it’s not the default browser anymore and prompts you to set it as such.

What I expect to happen:
For the browser to know it still is the default browser and not ask about it.

Has this happened before:
Doesn’t seem to apply to Lucid, so the bug occurs somewhere between 10.04…12.04.

Further info:
I’ll attach a screenshot demonstrating the above result.

I’m not at all sure whether I filed this against the right package, feel free to correct it.

I linked Unity 2D where this problem still remains. As a workaround, Shift+PrtScrn can be used to approximately select the desired window area to grab.

Happened just now as I was reporting another bug. May or may not have been associated with my Internet connection temporarily going offline for some reason at about the same time. No other conspicuous associated details I have right now but will happily provide if more data is needed.

No longer reproducible on two different up-to-date Precise setups here.

From Bug #950645, here’s one somewhat reliable way to trigger this: after login, have some windows open (I have Chromium, Gnome Terminal and Transmission set to start on login, don’t know if this works if you start them manually), then use the workspace switcher. This causes the launcher to stick (i.e. autohide to fail). Interestingly, if I then killall unity-2d-shell, even this recipe then fails to trigger the issue until the next login. But it seems 100% reproducible right after login. (I’m just hoping that #950645 really is a duplicate of this one. For me the trigger’s always been something else in the launcher since I almost never use the workspace switcher.)

Alright, I think this is safe to rule as invalid because the cause is most likely hardware failure: Oneiric boot media now also fails to boot here despite being the one used to install this system initially. I even went so far back as installing Jaunty (didn’t have anything more recent at hand, before Oneiric) and it also segfaults when X should start (though the graphical installer did work). I’ll still do tests if @Joseph disagrees (and has new ideas to test), but for now I’ll just settle for using fbdev (which seems to not trigger the issue).

I initially posed this as Question #188982, but now decided to report it as it seems to persist and no definitive answers as to the cause were found. I was apprehensive about reporting at first mainly because this doesn’t seem to occur on my other (Precise-running) computers. It is however 100% reproducible on this one (i.e. the flood occurs on each creation of an Xorg log, though I don’t know what triggers individual lines).

My Xorg log is flooded with lines about reusing xkmfile:

jani@saegusa:~$ grep ”XKB: reuse xkmfile /var/lib/xkb/server-” /var/log/Xorg.0.log | tail
[ 391.894] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.901] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.906] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.909] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.914] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.919] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.922] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.926] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.929] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.933] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
jani@saegusa:~$ grep ”XKB: reuse xkmfile /var/lib/xkb/server-” /var/log/Xorg.0.log | wc -l
1507

(Interestingly I now notice that the number of those lines seems to be constant: the above was copy+paste from terminal just now, and when I posed Question #188982 on 2012-02-27, the result was 1507 also.)

Just to add that all the icons in Elements panel, not just arrowheads, are expanded, unlike text that ignores Page zoom. Other icons, ugly as they appear when zoomed, do seem to function though.

Steps to reproduce:
1. Start Chromium with new (temporary) profile
2. Go to chrome://settings/advanced
3. Set Page zoom to 500%
4. For any page with content, open the Elements panel
5. Try to expand/shrink elements

What happens:
With the expanding/shrinking arrowheads zoomed 500%, but with code still at default zoom, it’s extremely difficult to hit the arrowhead in the right spot to expand/shrink elements. Depending on the selected Page zoom level the actual hotspot may even fall completely outside the arrowhead graphic (to the left from it).

What I expect to happen:
For the arrowheads and the code to both follow the Page zoom setting or ignore it, and either way, for the arrowhead graphic to function as the actual hotspot for expanding/shrinking elements.