Because it only works if we use __clone() everywhere (framework and 
application).

Actually, why would including __clone() methods break BC? PHP 4 will 
ignore them happily...

We should close this bug then and just worry about this issue when we 
next release a version of Horde that can break BC.

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.

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.

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).

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.

You need to provide the message source of a message that is giving you 
problems.

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.

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.

Too bad, it still didn't fix it.

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?

Too bad, it still didn't fix it.

Second try:

http://lists.horde.org/archives/cvs/Week-of-Mon-20050425/044059.html

I can confirm that the patch didn't fix this issue. But I can't 
confirm that it has been fixed with upgrading PHP.

Sorry, can't reproduce my own bugreport :-))

Probably because i recently updated PHP to 5.0.4

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.

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

Marking Bug 1776 and Bug 1792 as duplicates of this bug.

Bug 1792 has an initial analysis.

That was the important bit of information. I am now able to reproduce 
this too on a PHP5 server.

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.

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

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.

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.

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?

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.