GtkRecentMenu always returns the most recent item, rather than the selected item, when calling gtk_recent_chooser_get_current_uri()

[Joshua Lock]

GtkRecentMenu always returns the most recent item, rather than the selected item, when calling gtk_recent_chooser_get_current_uri().

I noticed this in some code I was working on and after spending some time banging my head against it I decided to try and replicate the issue in some other programs.

To reproduce the problem in MyPaint I took the following actions
1) Open several files with File->Open, so that the File->Open Recent menu has more than 1 item in it
2) Select an item other than the first (0th) in the File->Open Recent menu

What happens:
The current item remains open.

What I expect to happen:
The selected item is opened.

Changing my code to use gtk_recent_chooser_get_current_item(), rather than _get_current_uri(), results in the same issue.

Ubuntu version:
Description: Ubuntu 12.10
Release: 12.10

libgtk-3.0 version:
libgtk-3-0-dbg:
  Installed: (none)
  Candidate: 3.6.0-0ubuntu3.2
  Version table:
     3.6.0-0ubuntu3.2 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal-updates/main amd64 Packages
     3.6.0-0ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
libgtk-3-0:
  Installed: 3.6.0-0ubuntu3.2
  Candidate: 3.6.0-0ubuntu3.2
  Version table:
 *** 3.6.0-0ubuntu3.2 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.6.0-0ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages

[Joshua Lock (incandescant)]

Here's a simple Python program which demonstrates the problem I've observed in both my own code and MyPaint.

[Joshua Lock (incandescant)]

To see the issue with the demo program follow these steps:

1) run the program with python gtk3recent.py and select File->Open Recent, this will show the 5 most recent entries in the users' GtkRecent history.
2) select the first item in the list, the label in the window will show the uri of the first item
3) select any item in the list other than the first, the label in the window will *still*/*again* show the uri of the first item

Expected behaviour on selecting item other than the first:

The uri of the selected item will be shown

Actual behaviour on selecting item other than the first:

The uri of the first item is shown

I've also run the sample code on an updated Fedora 18 Beta, with gtk+ 3.6.2, where the program runs as expected.

P.S: Please ignore the python3 shebang in the test program, Python3 is not required.

[Joshua Lock (incandescant)]

I was pretty confident when filing this bug that the problem wasn't restricted to the bindings, but to verify my initial assumption I ported the simple test to C.

Results are the same.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Joshua Lock (incandescant)]

HI Sebastien,

As mentioned in comment #2 this bug is not present on Fedora 18 (gtk+ 3.6.2) nor can I reproduce on Fedora 17 (gtk+ 3.3.4), I can certainly file the bug upstream but I'd like to at least reproduce the issue elsewhere first.

I did a bit of extra digging and nothing jumps out in a quick diff of upstream gtk+3.6.0 to upstream gtk+3.6.2.

Further there's not delta of gtkrecentchooser.c, gtkrecentchooserwidget.c, gtkrecentchoosermenu.c and gtkrecentmanager.c between the Quantal bzr branch and upstream.

[Sebastien Bacher (seb128)]

oh ok, it doesn't happen if you unset UBUNTU_MENUPROXY ... seems like an indicator-appmenu issue

[Lars Karlitski (larsu)]

This is a duplicate of bug #752674, which has already been fixed in trunk (r429). Apparently that was too late to make it into Q.

Joshua, I have verified the fix with both of your example programs.

Seb, this seems like a good candidate to backport? It's a rather annoying issue...