Red Hat Bugzilla – Bug 202655
message pane always scrolls to bottom of message
Last modified: 2007-11-30 17:11:40 EST
starting somewhere around FC6 testing the view of the selected message in the
message pane always scrolls to the bottom of the message. There are two times
the message is automatically scolled to the bottom without user intervention,
both are quite annoying.
When the message is first displayed it is scrolled all the way to the bottom,
this forces one to scroll the message back to the top where where most people
prefer to begin reading :-)
In the second case, if there is any html objects (images??) the message will
scroll to the bottom even after the user scrolls the message back to the top, it
simply forces only the bottom of the message to be viewed. If one holds the
scroll bar down you can force the display to stay at the top, but as soon as the
scroll bar is released back it goes to the bottom.
That's bizarre, I'm not seeing that here.
Can you please list your versions of evolution and gtkhtml3? I have:
$ rpm -q evolution gtkhtml3
I had this installed:
I just upgraded to this:
The behavior is still the same. FWIW, my boxes do not have clean installs, I
just keep upgrading via yum, I wonder if its possible there is some cruft
hanging around, maybe an old gconf key? Anyway the problem is very reproducible.
Are you in Westford? If it helps you could swing by my cube, but today I'm WFH.
Yes, I'm in Westford. I'll try to catch you next week.
Someone on evolution-list reported what sounds like the same problem.
May be worth watching this thread .
I've got this problem too...
had the problem for about 2 or 3 weeks, with evo 2.7.x too before the 2.8.0 upgrade.
John; do you have "Caret Mode" on in the message views? Open message and check
the View menu for Caret Mode. I think if you've got Caret Mode on, gtkhtml puts
a cursor into the message view and initially that cursor is the _entire_ left
side of the message. gtkhtml must jump to the bottom of the cursor. If you
turn off Caret Mode, this problem goes away for me. I never knew there _was_ a
caret mode, but it makes sense :)
Arguably gtkhtml shouldn't put the caret at the beginning of the message
_container_, but at the beginning of the text of the message itself. Who knows.
The problem occurs on my home machine, not on my work machine and I'm currently
at work. But I did ssh into my home machine and check my gconf keys and caret
mode is enabled on that box, but not here at work (why the difference I don't
know). Until I can sit down in front of the box again I can't say for sure, but
it sure does seem like caret mode would be the culprit.
I have no clue what caret mode is, nor is there any description in the evolution
help. FWIW I have noticed the entire left side of the message has a line which
blinks. I never understood what that was and had just assumed it was some
rendering bug that didn't bother me enough to report but now I'm guessing that
blinking line is the caret. But why is the caret mapped to the entire message?
We may now have an explanation for why the message scrolls to the bottom, but I
don't think we have an explanation for what the intended behavior of caret mode
is, at the moment it seems more like a bug than a feature.
Thanks Dan for figuring this out! It's been driving me up a wall.
jrb cleared that up a bit; Caret Mode is an accessibility thing that's tied to
the standard F7 keybinding for some reason. I accidentally enabled it in
Epiphany at some point too and couldn't figure out why scrolling and arrow-keys
were all messed up, but hitting F7 turns that off too. All to easy to enable it
and have things magically change; would be better to have it Alt+F7 or Ctrl+F7
or something, but that's unlikely to change I guess.
Hmm... if merely hitting F7 by accident can enable this very annoying behavior
in a silent and mysterious way then this seems to be a UI component worth
However, having said that what I'm not clear on is the behavior annoying because
it's supposed to work that way when the feature is enabled, or is the
implementation of the feature broken and it wouldn't be confusing and annoying
for normal users who hit F7 by accident if it was implemented differently? If
the feature is broken that has implications for considering the consequences of
unintended F7 toggling, if its supposed to work that way then there needs to be
some positive confirmation to the user they have toggled on a radically
Changing the component to gtkhtml3.
It seems like Evolution ought to give some visual indication that Caret Mode is
turned on. In Epiphany, for example, hitting F7 displays "Caret" in the status
bar. I'll file upstream bug reports about both the cursor and scrolling
behavior, and the UI not indicating that the mode is turned on.
*** Bug 217977 has been marked as a duplicate of this bug. ***
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.
[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
Although the latest Evolution release in Rawhide still does not have a good
visual indication of when Caret Mode is activated, the scrolling behavior has
been fixed. So I'm closing this.