GNOME Bugzilla – Bug 700506
Random sizes of address autocompletion dropdown list
Last modified: 2018-04-15 00:23:29 UTC
I am auto-completing against my company's full Exchange address book (having fixed bug 699597). If I bring up a new composer window and type 'dwo' into the To: box, a second or so later a auto-complete list with matching addresses comes up. It is consistently two entries high, and has a scrollbar — which is necessary to show the full 23 matches. I delete the partially-typed (and auto-completed) address and type exactly the same thing again... and this time the auto-complete list that pops up is the *correct* size, and needs no scrollbar. This is entirely repeatable — each time I open a new composer, the first auto-complete list is far too small and has a scrollbar. If, after doing this, I just type 'dw' and pause, then I get a similarly-sized autocomplete window but it's *empty*. There are no addresses to select from. Which is hardly surprising, because it doesn't look like evolution-addressbook-factory is even being *asked* for a list. If I try 'dw' without previously trying something else, there's no drop-down box at all.
The size (and position) of the dropdown is led by gtk+, evolution uses a GtkEntryCompletion interface for it. The empty list of completions is a glitch on evolution's side.
I'm still seeing this in the latest versions. Could it be that you're trying to display the EntryCompletion before elements are all populated and size allocation has been calculated? Just a guess, I've no idea how it works/how it is currently implemented :)
I'm moving this to gtk+. Using gtk3-demo->Entry->Entry Completion, typing "g" shows the completion part 3 lines tall, while only one hit is shown there. I guess the entry completion doesn't behave right with dynamically filled models, which is the other part of the issue in the evolution's case. Tested with gtk3 3.18.2.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new