Bug 112357 - Bugged own X-Face parsing
Summary: Bugged own X-Face parsing
Status: RESOLVED WORKSFORME
Alias: None
Product: knode
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-10 13:29 UTC by Davide Ferrari
Modified: 2006-10-28 13:43 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Davide Ferrari 2005-09-10 13:29:00 UTC
Version:            (using KDE KDE 3.4.90)

Well, this apply I suppose to any personal X-Header added. The bug is that if there is a semi-colon after the X-Header: one, they are considered as delimiters and then the following header part is cutted away when KNode is reloaded after the header is entered.

Example:

I have this X-Face header

shjjhjashj$&6-23:87987ff212fdfd

I put it into Knode, it works. Next time I load Knod the header content will result as:

shjjhjashj$&6-23
Comment 1 Davide Ferrari 2005-09-19 18:01:59 UTC
Ok, I found where the bug really lies. It's not a problem of parsing semi-colons but a problem while saving user inserted X-Headers. The saving routine wraps the x-header every 80 columns, and so when KNode loads it again, it reads more headers, corrupting the original one.

Or maybe the problem is in line 960 of knconfig.cpp with that \n, but it shouldn't...

Please give it a look
Comment 2 Volker Krause 2005-10-01 11:27:45 UTC
I wasn't able to reproduce this bug.

Does the change in the X-Face header happen to an already created message or to what you see in the config dialog (Posting News -> Technical -> XHeaders)?
Comment 3 Davide Ferrari 2005-10-02 19:34:14 UTC
Both config dialog and new message are broken. As I said the problem is in .kde/share/apps/knode/xheaders. When you add a custom X-Header, if the header data is longer than 80 chars, it's wrapped on 2 (or more) lines. And when KNode try to read it again, it reads correctly only the first line (the others do not have the "X-$HEADERNAME" at the beginning).
Hope that's more clear now... 
Comment 4 Volker Krause 2005-10-02 22:08:37 UTC
Thanks, I understand the problem now.

But still I can't reproduce this, I also haven't found anything in the code that might wrap lines at 80 chars for that file.

Have you maybe touched the file with any other program, e.g. a text editor?
Comment 5 Davide Ferrari 2005-10-02 22:32:25 UTC
This is really strange...maybe could be something QT related? I'm currently using 3.3.4 but I'm quite sure I have this problem from earlier KDE 3.4.0 days (I think it was QT 3.3.2 or 3.3.3).
As I said in comment #1 I took a look to the code and I don't see anything that could cause the wrapping. And no, I'm not touching it with a text editor...well, editing it it's the only workaround to the problem (joining lines manually)...but the problem rise even when no xheaders file is present.
I'm really wondering what's happening there.

Last side note: this problem is there for me since the first version of KNode with X-Face support, but at the time I didn't mind.
Comment 6 Volker Krause 2006-03-21 17:38:57 UTC
Are you pasting the X-Face value into the config dialog including newlines? Although the dialog doesn't show newlines, it still stores them (which is a bug of course).
Comment 7 Volker Krause 2006-03-21 18:16:44 UTC
SVN commit 521137 by vkrause:

Strip newlines out of extra headers in case someone pastes them into the
lineedit.

CCBUG: 112357


 M  +4 -1      knconfigwidgets.cpp  


--- branches/KDE/3.5/kdepim/knode/knconfigwidgets.cpp #521136:521137
@@ -2154,7 +2154,10 @@
 
 QString KNConfig::XHeaderConfDialog::result()
 {
-  return QString("X-%1: %2").arg(n_ame->text()).arg(v_alue->text());
+  QString value = v_alue->text();
+  // just in case someone pastes a newline
+  value.replace( '\n', ' ' );
+  return QString( "X-%1: %2" ).arg( n_ame->text() ).arg( value );
 }
 
 
Comment 8 Volker Krause 2006-10-28 13:43:22 UTC
No response from reporter, so I assume the fix worked.