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 89281 - spacebar reading doesn't work when subject contains encoded characters
spacebar reading doesn't work when subject contains encoded characters
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-0.13.0 betas
Other Linux
: High normal
: 0.13.3
Assigned To: Christophe Lambin
Pan QA Team
: 92405 98288 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-07-28 21:11 UTC by Christian Lohmaier
Modified: 2006-06-18 04:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Lohmaier 2002-07-28 21:11:21 UTC
Space-bar reading doesn't work when the selected article's subject contains
encoded characters like umlauts. [1]
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..)

[1] When the umlauts aren't encoded at all (due to buggy newsreaders),
space reading works (e.g. when sunject contains 'ähnliches' instead of
'=?iso-8859-1?Q?=E4hnliches?='

PS: I was trying to submit this one using bug-buddy, but this didn't seem
to work. Maybe it will arrive sometime..
Comment 1 Christophe Lambin 2002-07-31 23:02:12 UTC
I couldn't believe it, but it's actually true. :)

I'll have a look at this when I get the chance.
Comment 2 Christophe Lambin 2002-08-19 20:45:27 UTC
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
message (GMime).

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 ?
Comment 3 Christophe Lambin 2002-09-09 18:30:43 UTC
*** Bug 92405 has been marked as a duplicate of this bug. ***
Comment 4 Christophe Lambin 2002-10-11 00:00:11 UTC
Bumped remaining bugs to 0.13.2.
Comment 5 DevilKin 2002-11-12 06:36:47 UTC
*** Bug 98288 has been marked as a duplicate of this bug. ***
Comment 6 Christophe Lambin 2002-11-13 20:53:21 UTC
Bumped remaining bugs to 0.13.3.
Comment 7 Charles Kerr 2002-11-18 02:00:08 UTC
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?