After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335136 - Miscompilation of glib causes maillist scrollbar in Evolution 2.6.0 to be insensitive
Miscompilation of glib causes maillist scrollbar in Evolution 2.6.0 to be ins...
Status: RESOLVED NOTGNOME
Product: glib
Classification: Platform
Component: general
2.10.x
Other All
: Normal minor
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-03-19 16:46 UTC by Felix Braun
Modified: 2006-05-15 12:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Felix Braun 2006-03-19 16:46:16 UTC
Please describe the problem:
The scrollbar that is attached to the list of available mails can not be dragged
to adjust which messages are displayed. Pressing the scroll buttons either end
of this scrollbar also has no effect.

Workaround is to use cursor keys to navigate the list of available mails.

Steps to reproduce:
1. Start evolution
2. select a folder which has more mails than can be displayed in the mail list view
3. try to scroll using the scollbar


Actual results:
nothing

Expected results:
listview gets adjusted according to scrollbar

Does this happen every time?
yes, reproducible every time

Other information:
Comment 1 Karsten Bräckelmann 2006-03-19 18:12:15 UTC
Can not reproduce this, WORKSFORME.

Felix, what is your Desktop Environment and Theme used? GTK+ version, distro? Not sure what exactly could cause this, but I highly doubt this is an Evo issue.

NEEDINFO.
Comment 2 Felix Braun 2006-03-20 11:33:49 UTC
I'm using GNOME 2.14.0 with Clearlooks theme. GTK+ 2.8.16 Gentoo 2006.0

I still suspect this caused by some non standard code in Evolution because all other scroll bars on my desktop (including all scroll bars in Evolution) work flawlessly. Of course, Evolution 2.4.* worked without problems... If you don't have any hint about what might be going wrong, I'll randomly downgrade stuff to get some kind of clue for you.

I've filed a bug with my Distro: http://bugs.gentoo.org/show_bug.cgi?id=126921
Comment 3 Andreas Liebe 2006-03-27 13:04:15 UTC
I'm facing the same problem with Evolution 2.6 on a Sun Solaris 5.8 resp. 5.9. The packages are handmade and are on Gnome 2.12 level.

The problem is independant of the theme used. Other scrollbars within Evolution do work, too.

The workaround works for me, but it's quite uncomfortable.

Other Gnome apps works fine. Evolution 2.4 works, too.
Comment 4 Guillaume Maury 2006-04-27 07:04:59 UTC
I have exactly the same problem.

I'm also using gentoo with gnome 2.14.0, gtk+ 2.8.16 and the evolution ebuild install is marked as being 2.6.0-r1 (I had the same problem with 2.6.0)

There was no problems before with evolution 2.4
Comment 5 Felix Braun 2006-04-28 04:37:28 UTC
I have found a lead: after recompiling gtk+ and glib (not evolution) with more conservative optimisation flags the bug went away. I'll investigate further which flags cause this misbehaviour. (Strange that only this one scrollbar in the whole system is affected!)
Comment 6 Felix Braun 2006-04-28 05:51:01 UTC
OK, we have a winner :-)

I normally compile everything with these flags using GCC 3.4.6 (Gentoo 3.4.6-r1):
-Os -fweb -frename-registers -fomit-frame-pointer -march=pentium-m

Re-compiling only glib(!)version 2.10.2 without -fomit-frame-pointer fixes this bug for me. Can any of the other people experiencing this confirm? So this is probably either a bug in GCC or in glib. I'll rephrase the summary accordingly and change the affected product.

It's still strange why only this one scroll bar is affected...
Comment 7 Matthias Clasen 2006-04-29 04:01:13 UTC
The fact that only one scrollbar in evolution is affected may point to
ETable rather than glib. Anyway, there is not much we can do here, based
on the current information. You would have to dig into what is different
between the runs with the differently compiled glibs.
Comment 8 Andreas Liebe 2006-05-12 08:52:31 UTC
I've tried with and without -fomit-frame-pointer and with different libs on our SPARCS. It works with all evolution versions up to and including 2.4.2.1, it does not work with evolution 2.6.0 and 2.6.1. I would also think that the problem lies withing evolution ETable, but did not have the time yet to dig deeper.
Comment 9 Matthias Clasen 2006-05-12 16:07:51 UTC
In any case, not a glib problem, more of a gentoo problem.
Comment 10 Andreas Liebe 2006-05-15 12:38:03 UTC
Neither a glib nor a gentoo problem. I'm running it on some Sun Sparc-Servers with Solaris 5.8/5.9/5.10. Probably a bad interaction between some supporting libraries?