6.0.0-git
2021-01-18

[#1410] Message with 8 bit characters incorrectly shown, if message display refreshed
Summary Message with 8 bit characters incorrectly shown, if message display refreshed
Queue IMP
Queue Version 4.0.2
Type Bug
State Resolved
Priority 1. Low
Owners Horde Developers (at)
Requester G.Gersdorf (at) tu-bs (dot) de
Created 2005-02-18 (5813 days ago)
Due
Updated 2006-03-08 (5430 days ago)
Assigned 2006-03-08 (5430 days ago)
Resolved 2006-03-08 (5430 days ago)
Milestone
Patch No

History
2006-03-08 22:56:37 Chuck Hagenbuch State ⇒ Resolved
 
2006-03-08 21:42:57 Jan Schneider Comment #27 Reply to this comment
Actually, why would including __clone() methods break BC? PHP 4 will
ignore them happily...
Because it only works if we use __clone() everywhere (framework and 
application).
2006-03-08 18:57:45 Chuck Hagenbuch State ⇒ Feedback
 
2006-03-08 18:52:09 Chuck Hagenbuch Comment #26 Reply to this comment
We should close this bug then and just worry about this issue when we
next release a version of Horde that can break BC.
Actually, why would including __clone() methods break BC? PHP 4 will 
ignore them happily...
2005-09-27 20:27:46 Michael Slusarz Comment #25
State ⇒ Resolved
Reply to this comment
We should close this bug then and just worry about this issue when we 
next release a version of Horde that can break BC.
2005-09-15 18:59:08 Jan Schneider Comment #24 Reply to this comment
According to http://www.php.net/manual/en/language.oop5.cloning.php 
this is the expected behaviour. If you want to make a deep clone, you 
have to implement __clone() methods in the classes that contain 
references. Unfortunately this is not possible without breaking bc, so 
we probably need to keep this workaround.
2005-07-28 10:34:34 Jan Schneider State ⇒ Assigned
 
2005-07-28 10:13:14 Jan Schneider Comment #23 Reply to this comment
According to http://bugs.php.net/bug.php?id=27268
http://bugs.php.net/bug.php?id=24485, and 
http://bugs.php.net/bug.php?id=3226, this might be fixed in PHP 4.4 
and 5.1.



If we can confirm this, we should add a version_compare() test to the 
cloneObject() method.
2005-05-28 05:56:29 Michael Slusarz Comment #22
State ⇒ Resolved
Reply to this comment
All right, I finally verified this as a problem with multipart 
messages.  It turns out that PHP 5's clone() doesn't seem to work the 
way I expect it to.  Namely, the outermost part of the object is 
cloned but inner variables in the object may remain linked outside of 
the cloned object.  To me, clone means to create a new copy of the 
object that is completely independent of the old object.  Seems like 
the PHP folk agree with me since there are multiple bugs on this issue 
- See, e.g.:

http://bugs.php.net/bug.php?id=27268

So, for now, hack around this issue using serialize/unserialize combo 
which does create a truly independent object.



This should fix the issue with seeing un-encoded characters when 
replying/forwarding to mesages (that's the only place where i was 
seeing this weirdness).
2005-05-08 05:13:46 Michael Slusarz Comment #21
Priority ⇒ 1. Low
Reply to this comment
Committed to Horde 3.0.5.  This fix is working for at least some 
people (i.e. me) and will not cause bc problems so it is going in for 
now.
2005-05-07 17:33:44 Michael Slusarz Comment #20
State ⇒ Feedback
Reply to this comment
You need to provide the message source of a message that is giving you 
problems.
2005-05-06 09:16:06 Jan Schneider Summary ⇒ Message with 8 bit characters incorrectly shown, if message display refreshed
 
2005-05-04 09:07:47 jiri (dot) reischig (at) ecn (dot) cz Comment #19 Reply to this comment
I look at the problem and I find than problem is not in text-plain 
message with some charset, but problem is now with multipart message.



When I can view html and plain text multipart message with ISO-8859-2 
charset for the first time the message is OK and for second view is bad.
2005-05-03 16:42:59 Michael Slusarz Comment #18
Priority ⇒ 2. Medium
Reply to this comment
I don't know what else to say.  All the sample messages work perfectly 
for me.  I can switch between limited/all headers all day long on a 
q-p or base64 message with iso-8859-1 charset and it renders perfectly 
now.  I can reply to this message and the body text appears without 
error in the reply window.  Removing the code from my patch reverts 
the behavior to the old (broken) way.  Everyone has logged out, 
applied the patch, cleared the Horde cache, and updated the framework? 
  Also, if using a PHP cache, this cache needs to be cleaned out also/ 
  Because (obviously) I can't do anymore work on this bug since it 
isn't broken for me.



If someone else wants to play around, I can tell you this much 
information.  The cached object must contain the pristine, original 
MIME_Message object.  Previously, in PHP5, the MIME-Message object 
that was being cached contained body text that had been converted, 
etc. during the previous pageload.  Thus, when the body parts were 
being reloaded into the MIME_Message object the next page load, these 
MIME_Parts are already marked as being converted from the original 
content-encoding so no additional decoding was done.  The solution - 
keep a copy of the original MIME_Message object in the MIME_Contents 
object until the MIME_Contents object is ready to be cached, then 
replace the "dirty" MIME_Message object with the pristine object .



You don't want to keep MIME_Message cached across page loads because 
it is possible that the body text will be changed (i.e. if you want to 
view images in an HTML part) so the MIME_Message object must be 
rebuilt every page load.
2005-05-03 12:22:18 jiri (dot) reischig (at) ecn (dot) cz Comment #17 Reply to this comment
Too bad, it still didn't fix it.
2005-05-02 03:59:12 Michael Slusarz Comment #16 Reply to this comment
Huh.  This patch fixed everything for me - even stuff that wasn't 
orginally listed as broken in this (and related) tickets but involves 
message caching also (specifically, clicking on viewing images in HTML 
parts would not do anything previously (since it was using the 
incorrect cached, non-image viewing body text) - now it works correctly.



3 days of testing and this patch has yet to stop working for me.  Anyone else?
2005-04-30 22:37:07 Jan Schneider Comment #15 Reply to this comment
Too bad, it still didn't fix it.
2005-04-27 08:22:52 Jan Schneider Comment #13
State ⇒ Assigned
Reply to this comment
I can confirm that the patch didn't fix this issue. But I can't 
confirm that it has been fixed with upgrading PHP.
2005-04-27 07:30:15 G (dot) Gersdorf (at) tu-bs (dot) de Comment #12 Reply to this comment
Sorry, can't reproduce my own bugreport :-))

Probably because i recently updated PHP to 5.0.4
2005-04-27 06:48:39 michael (at) rollis (dot) ch Comment #11 Reply to this comment
Thanks for the patch. Tried it against current horde-3.0.4 and it 
didn't work there, the bug is still showing. Maybe it's interacting 
with other changes made in HEAD.

With the ze1_compat-flag I can wait until 3.0.5.
2005-04-27 05:56:21 Michael Slusarz Comment #10
State ⇒ Feedback
Priority ⇒ 3. High
Reply to this comment
For those using PHP 5 - did this patch (to HEAD... but this one-line 
patch is easily done with other versions as well) fix your problem?

http://lists.horde.org/archives/cvs/Week-of-Mon-20050425/043908.html
2005-04-27 05:52:44 Michael Slusarz Comment #9 Reply to this comment
Marking Bug 1776 and Bug 1792 as duplicates of this bug.
2005-04-15 07:32:02 Jan Schneider Comment #8 Reply to this comment
Bug 1792 has an initial analysis.
2005-04-15 07:28:54 Jan Schneider Assigned to Horde DevelopersHorde Developers
 
2005-04-15 07:28:39 Jan Schneider Comment #7
State ⇒ Assigned
Reply to this comment
That was the important bit of information. I am now able to reproduce 
this too on a PHP5 server.
2005-04-15 04:54:25 michael (at) rollis (dot) ch Comment #6 Reply to this comment
As a result of a test in Bug 1776 I have a new comment to this:



Switching ze1-compatibility-mode to "On" in php.ini (had to switch 
from mysqli to mysql too) the bug disappears. So this may be related 
to object handlich in PHP5 too.
2005-04-14 15:14:34 michael (at) rollis (dot) ch Comment #5
New Attachment: mail_views.zip Download
Reply to this comment
A really big sorry for opening a new bug report. Missed this bug on 
searching for any entry related to my problem.



It's exactly the same problem here (Server setup as in Bug 1776).



Uploaded some screenshots from my testmail from bug 1776:

first_view_utf-8.pdf  (First view of the mail with Firefox 1.0 with 
utf-8 charset set)

second_view_utf-8.pdf  (Second view, still utf-8 set in Browser with 
quirked umlauts)

second_view_iso-8859-1.pdf  (Second view, changed browser manually to 
show in ISO-8859-1, even worse)



One very astonishing thing to notice: On both utf-8 Screenshots, the 
Subject is always correct, only the body gets quirky with a second, 
third, forth... view. On changing to iso-8859-1 not only the message 
but the imp-gui too gets quirky. So I think it's really Browser and OS 
independet from the clients point of view.



And last but not least I compared (show source in browser) the sent 
source of the first and second view and they show the same differnce: 
correct umlauts on first and the same quirk on second view.



Regards

Michael
2005-03-22 16:37:40 Jan Schneider Comment #4
State ⇒ Not A Bug
Reply to this comment
There is nothing I can tell you right now, beside that this didn't 
happen to anyone else before. So it probably is a local issue with 
your system. Feel free to add further comments to this ticket if you 
find out more, we can re-open it if there is something to work with.
2005-03-08 12:33:15 G (dot) Gersdorf (at) tu-bs (dot) de Comment #3 Reply to this comment
For both pages, Opera says:

   Encoding from server: UTF-8

   used by Opera: utf-8

  And it happens with IE 6SP2, Firefox 1.0, Opera 6.0 and it also 
happens on other computers as well.
2005-03-06 13:51:15 Jan Schneider Comment #2
State ⇒ Feedback
Priority ⇒ 1. Low
Reply to this comment
The message works fine here, and what you describe doesn't make much 
sense either.

Looking at your screenshots I guess that the browser doesn't recognize 
at the second page that the rendered page is in UTF-8. Can you confirm 
this, and does this happen with all browsers?
2005-02-18 13:35:43 G (dot) Gersdorf (at) tu-bs (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ Message with 8 bit charcters incorrectly shown, if message display refreshed
Queue ⇒ IMP
New Attachment: message.zip Download
Reply to this comment
A Message with charset="iso-8859-1" and content-transfer-encoding="8 
bit" (see attachment) or content-transfer-encoding="quoted-printable" 
is first shown correctly (see MessageFirst.jpg) but if it is redrawn 
via the refresh-button of the browser or by clicking 'Headers: all' 
the characters are incorrectly shown (see MessageSecond.jpg).



If charset='utf-8', its all ok.

Saved Queries