GNOME Bugzilla – Bug 89281
spacebar reading doesn't work when subject contains encoded characters
Last modified: 2006-06-18 04:56:40 UTC
Space-bar reading doesn't work when the selected article's subject contains
encoded characters like umlauts. 
To reproduce (this is reproducible 100%)
1) open a group like de.comp.office-pakete.staroffice (a german-speaking
group -> lots of umlauts
2) select an article with umlauts in its subject
3) hit <spacebar>
-> nothing happens (except when there is a vertical scrollbar: the
scrollbar-handle enlarges to fit the whole scrollbar and shrinks back to
its original size very fast)
the body pane doesn't scroll and no next article is selected
what do I expect?
the body pane should scroll down or, when the bottom of the article is
reached, sould select the next article. (I'd also like it, when space would
then select the next 'unread' message, but that's another issue..)
 When the umlauts aren't encoded at all (due to buggy newsreaders),
space reading works (e.g. when sunject contains 'ähnliches' instead of
PS: I was trying to submit this one using bug-buddy, but this didn't seem
to work. Maybe it will arrive sometime..
I couldn't believe it, but it's actually true. :)
I'll have a look at this when I get the chance.
more charset fun: text.c::text_read_more() does a pan_strcmp
(art_subject, cur_subject), where art_subject is retrieved from the
article headers (XOVER), and cur_subject is retrieved from the parsed
art_subject is now always in UTF-8 (as it should be), but GMime
returns the raw header. So, if it's quote-encoded, it's the raw,
unencoded, string. If it's 8bit, it's the raw 8bit string in article's
charset (whatever that is).
Not sure what do to about this: the quote-encoded case is trivial to
convert to UTF-8, but what to do about the 8bit case ?
*** Bug 92405 has been marked as a duplicate of this bug. ***
Bumped remaining bugs to 0.13.2.
*** Bug 98288 has been marked as a duplicate of this bug. ***
Bumped remaining bugs to 0.13.3.
Chris: a cheap fix for this would be to compare on message-id
rather than subject. Article and GMimeMessage both have an API
call to pump out the message-id...
Do you want to fix this, or should I, or do you want a different fix?
Fixed in HEAD for 0.13.3: