Thanks for a bug report. I tried to reproduce this, but I do not get the window expand, the window is showsn as expected. I beleive this depends on actual data in the contact in the destination book, same as contact data being in the source book. Could you provide these two test contacts with some fictional data, please?

Milan,

I saved contact info across two servers (google and ldap) for such a contact in two separate vcf files. Do you have an email address I can send these? I can remove some info but then this might also remove important debug stuff.

You can send it to my bugzilla email, only write a bug number/link into subject, thus I'll not overlook it in my spam folder

Thanks for the files. I would expect things not being related to addressbook source and destination type at all (in your case source Google, destination LDAP), thus I imported one contact to one local book, the other to another local book, and then right-clicked contact in one of them, choosing Copy, and moved to the other book and right-clicked and chose Paste. It showed me that the contact is already there, thus I clicked Merge, which brings another dialog which let's me choose which values I want to merge. In one way it's only email, in the other way it's many more items. Sadly, the dialog doesn't change its size, it stands as it was on open, with scrollbars in the second case. This was both with 3.8.3 and 3.8.5, same is with current development version. I even tried to update gtk3 to 3.8.4-1, but it still works as expected, even under gnome-shell.

oh, I forgot to mention, I also used "Copy to book option", instead of copy&paste through clipboard.

I re tested this and on my computer seem to make a difference what type of ab yoıu use.

I created a 2nd local ab and did not observe the bug! I can see bug in these types:

local -> local - no
local -> google - yes
local -> ldap - no

google -> local - yes
google -> ldap - yes

ldap -> local - no
ldap -> google - yes



so it seems it has something to do with google type ab! Didn't realize this before....

Hmm, that's pretty weird. All the dialog does is done locally, thus it might be that the contact on the google server contains something else/more than the local one. I still try the local->google, google->local, but no luck here, both with copying the "richer" contact on top of the smaller, and vice versa.

Thus it might be something with gtk+ version and the amount of data to be merged, I guess.

By the way, what I do:
a) right click a contact in a Google (or local) book
b) choose "Copy Contact to"
c) select the other of Google/local book than the one from step a)
d) on question of Cancel/Add/Merge I click Merge
e) now I see a dialog with list of changed values, which I simply cancel

I expect that at step e) you get the hang, right?

Could you install debuginfo packages for evolution, evolution-data-server, and gtk+ of the versions you've installed, restart evolution, reproduce the hang and get a backtrace for the time the application is hang, with this command, please?

   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt

and attach/paste the content of bt.txt here, please? Please, make sure the backtrace will not expose any private data, like passwords, email addresses and so on. I usually search for "pass" (quotes for clarity only) in it.

instead of step (b) I actually choose just "copy" but I tried your version and I still get the bug.

Moreover, I don't get a hang. I get an indefinitely expanding window after I select the google addressbook in step (c). Merge dialog expands to the right and after it reaches the border of the screeen expands to the left until it reaches to the left end of the screen and when it does it again continues to expand to the right and I don't see the buttons anymore etc.

I tried to get the bt when the bug appeared and I attached the bt.txt file.

Created attachment 255917 [details]
backtrace

BTW I'm using gtk+-3.8.2

I upgraded to gtk+-3.8.4 and recompiled Evolution. I still see this bug.

Any other ideas to figure out whats going on will be really appreciated!

Hmm, I think it's some event-driven resizing, because the backtrace you caught shows all threads idle, where I would expect at least thread 1 busy on the resize. Getting the backtrace slightly sooner, or later (really hard to know when the right time is, if it goes through event loop), should show some activity in the main thread. You can try to catch the backtrace, the command can be run multiple times with different files in output redirection, if you want. As a simple command feel free to use:
   $ for i in {1..10}; do gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt$i.txt; sleep 0.1; done

Mathias, by any chance, do you recall anything like this in gtk+, please?

Created attachment 256065 [details]
multiple backtraces

I run that command just before I paste a contact into google ab. It was still running when the problem appeared.

Hope it helps.

Thanks for the update. I see that:
- bt4 is in gtk's gtk_window_compute_configure_request()
- bt5 is in gdk_window_process_updates_with_mode()
- bt6 in XTranslateCoordinates()
- bt8 in WebKit drawing (WebKit::repaintEverythingSoonTimeout())
- bt9 in webkit_web_view_motion_event()

I'd still appreciate a comment from Matthias or any other gtk+ developer.

I tried this under gnome-shell, in Fedora 20, and I see that resize too there. My MATE in Fedora 19 is fine, which makes me wonder what the gnome-shell broke again.

Even with that Fedora 20 I cannot reproduce it consistently, it sometimes does the "expand in size", but mostly not. It's the "Duplicate Contact Detected" dialog which does it. I see it goes through functions like gtk_window_move_resize() and gtk_container_start_idle_sizer(), though these might be too generic.

I also noticed that this window cannot be shrink, it can only expand (when dragging right edge of the window) for some reason. I do not know which widget prevents window shrink, even there are only few of them.

Nice, it just happened here on Fedora 19 too, but only once. I repeated the same steps, but it doesn't do it again. From that I see it's not about gnome-shell as such, it only might be easier to reproduce there than in MATE here.

Created attachment 256268 [details]
minimal reproducer

This is a minimal reproducer, with which I can reproduce the issue. It opens
   /usr/share/evolution/3.8/ui/eab-contact-duplicate-detected.ui
replaces there the evolution widgets with webkit web views (the evolution widgets are descendants of it), then removes one of them and finally shows the dialog. The dialog changes its size consistently this way, at least for me. If I remove both web views, then the dialog stands still.

From that I guess this has something to do with webkit. Its webkit_web_view_get_preferred_width() always sets minimum and natural widths the same, thus if the web view decides that the content is larger for whatever reason, then it also brings the window larger. This way the webview will never allow itself to be shrink, because the minimum size is the same as the natural/content size.

Reproduced on evolution-3.10.1-1.fc21.x86_64 on merge dialog for two contact lists on webdav source

*** Bug 699709 has been marked as a duplicate of this bug. ***

*** Bug 711579 has been marked as a duplicate of this bug. ***

I see the same effect on openSUSE 13.1 64 bit, Evolution 3.10.1

Steps:
1. right click on address in email message
2. click add to address book
3. dialog box pops up "duplicate address detected"
4. dialog box begins growing in in the +y direction pushing the buttons off the screen.

I don't know if this was present in openSUSE 12.3.

*** Bug 721578 has been marked as a duplicate of this bug. ***

I see this on evolution 3.10.3 on F20 using the MATE desktop.

Also seen on Evolution 3.10.3 on Arch Linux i386 under XFCE 4.10.

No Gnome services are running except goa-daemon, gnome-keyring-daemon, at-spi2-registryd .

There is a Youtube clip of the bug effect (3.10.1) at http://www.youtube.com/watch?v=_eLJ3RhvAAo

eab-contact-merging.c (c)  static void                       Row 255

static void
dialog_map (GtkWidget *window,
            GdkEvent *event, 
            GtkWidget *table)
{
        GtkAllocation allocation;
        gint h, w;

        gtk_widget_get_allocation (table, &allocation);

        /* Spacing around the table */
        w = allocation.width + 30;

It looks like this will resize the dialog widget if there's not adequate margin around a table. if the table dimensions are not constrained appropriately this would cause the width to increase in steps.

gtk_table_attach_defaults has been deprecated since version 3.4 and should not be
https://developer.gnome.org/gtk3/stable/GtkTable.html

gtk_table_attach_defaults (table, (GtkWidget *) hbox, 0, 1, row, row + 1);---

default options are FILL|EXPAND

The table expands and then the dialog window resizes over and over until a crash occurs.

Well, it sounds promising, but it doesn't explain why the minimal reproducer from comment #18 suffers of the same issue, but doesn't have your cited code. That's why I believe this is WebKitWebView's issue. By the way, the "map" signal is supposed to be called only once, not multiple times.

I managed to cook a fix for this, with help of msocorcim. I'm still unsure of the exact cause of the auto-expand behaviour, but it seems like an issue with a WebKitWebView not being packed in a GtkScrolledWindow directly, but indirectly, with more other widgets. That's at least one the differences between eab-contact-duplicate-detected.ui (suffers of the issue) and eab-contact-commit-duplicate-detected.ui (does not suffer of the issue), while otherwise these two dialogs are visually almost identical.

I did two different fixes, actually, one for 3.10 version, which only removes the top GtkScrolledWindow and packs WebKitWebView descendants to their own GtkScrolledWindow. It also, as a side effect, fixes dialog resizing. The second fix, for git master, goes further, and drops the both .ui files from the sources and creates the dialog on the fly within the C code. The packing is almost the same, only more modern widgets are used inside (GtkTable has been replaced with GtkGrid).

Created commit 90f956a in evo master (3.11.5+) [1]
Created commit 75938b5 in evo gnome-3-10 (3.10.4+)

[1] https://git.gnome.org/browse/evolution/commit/?id=90f956a

*** Bug 720354 has been marked as a duplicate of this bug. ***

*** Bug 711759 has been marked as a duplicate of this bug. ***

*** Bug 745775 has been marked as a duplicate of this bug. ***

*** Bug 728453 has been marked as a duplicate of this bug. ***