does not hang if the user have only web link as status message. If the status message contains some text and the weblink then empathy hangs

originally reported at: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/532947

If a contact has "Visit http://www.google.be yeah" has status, opening his information dialog hangs Empathy.

If text comes after web address empathy wont hang. In case of "Visit http://www.google.be yeah" empathy hangs

This is most probably GTK bug. I'm trying to write simple test case, but can't find one yet.

The infinite loop is when the dialog is searching for the focus widget, in gtk_dialog_map() there is a while(TRUE) with obscure exit condition that never happens in our case.

Reassign to GTK, they probably know better that code.

Created attachment 155550 [details]
Simple test case

Ok, here is a test case that freeze. That's the proof the bug is on GTK+.

Note that If I mode the gtk_widget_show (dialog); before packing labels, then it works.

Created attachment 155551 [details] [review]
Little GTK patch to add debug info

Those debug prints shows the infinite loop inside gtk_dialog_map().

Here is the output of the test case with the above patch applied:

1: first (nil) window (nil)
grab focus on 0x1a3c000
and has info 0x1a3c000
2: first (nil) window 0x1a3c000
3: is label 1
1: first 0x1a3c000 window 0x1a3c000
grab focus on 0x1a3c0d0
and has info 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
1: first 0x1a3c000 window 0x1a3c0d0
select link for 0x1a3c0d0
2: first 0x1a3c000 window 0x1a3c0d0
3: is label 1
**
Gtk:ERROR:gtkdialog.c:413:gtk_dialog_map: assertion failed: (++count < 10)
Abandon

Adding Mathias Clasen in CC, he seems to be the one who wrote that code, according to git-blame.

Also note that if I change the link label to be only "<a href=\"http://www.test.com\">www.test.com</a>" then I can't reproduce the infinite loop, but the first label is selected. I remember we had issues like that in Empathy where label gets selected.

So I see 2 issues:

1) The focus does not forward in label that have links
2) If there are only labels in the dialog that can get the focus, it should not select the first, but fallback to no focus.

3) In testcase, if I show the dialog before packing labels to avoid the freeze, then taping "tab" to move focus will only select the whole label that contains the link, it won't select just the link. If I don't set that label as selectable, then only the link will be selected.

So it really looks like gtk_label_focus() has issues.

I've found what's going on with the infinite loop:

In gtk_dialog_map() if the focus goes to a label, then it select [0, 0] area. That means that in the label, info->selection_anchor == info->selection_end. In that case, when taking the next focus, it stay in the label and search for next link... but since the area is always reset to [0,0] it will always take first link as next focus.

So the loop in gtk_dialog_map() will never come back to the first_focus, and it will loop infinitely.

Raising severity to critical since it can easily freeze any GTK app.

I backported the patch to GTK 2.18 and it fixed the issue. Thank!