Sidebar, Problem with umlaut (�,�,..) in IE

The tree in the sidebar ends at the point, where an umlaut

Sun, 02 Jan 2005 11:38:20 +0000

The tree in the sidebar ends at the point, where an umlaut (like ä,ö,ü) in a foldername (eg. imp -> imap foldername) appears. This problem appears only in IE (v. 6), Firefox 1.0 and Opera 7 show the correct tree. Screenshot IE: http://www.flobauer.net/screenshot_ie.jpg Screenshot Firefox: http://www.flobauer.net/screenshot_firefox.jpg

Might be a duplicate of bug 809. Please confirm, and if so,

Sun, 02 Jan 2005 11:57:43 +0000

Might be a duplicate of bug 809. Please confirm, and if so, find some common points of both your systems.

No, I think bug 809 is something else. I found something

Sun, 02 Jan 2005 12:10:17 +0000

No, I think bug 809 is something else. I found something interesting: if i create a imap folder in IMP with an umlaut, it is displayed correctly in the sidebar and the umlaut "ä" (ae) is encoded in "g&5A-" if i create the folder in Thunderbird or Outlook, the error occures and the "ä" is encoded with "&AOQ-" (seems that IE do not like this encoding)

Found the Problem: The label of the Node with the umlaut

Sun, 02 Jan 2005 14:49:01 +0000

Found the Problem: The label of the Node with the umlaut was encoded with: xxx\0äyyy .... for an "ä" xxx\0öyyy ... for an "ö" ... and so on, so the umlaut got a prefix "\0" (don't know why) I added to templates/javascript/tree.js on line 319 var re = new RegExp ('\0', 'gi') ; var label = label.replace(re, '') ; before: return '' + label + ''; Dirty hack, but it works .... would be good to find out, why this "\0" thing happens.

What charset do the "normal" pages have, what charset does t

Mon, 03 Jan 2005 17:56:02 +0000

What charset do the "normal" pages have, what charset does the menu have, and does it change after the menu refreshed?

Both have ISO-8859-1 and refresh do not change anything.

Wed, 05 Jan 2005 10:03:31 +0000

Both have ISO-8859-1 and refresh do not change anything.

Should be fixed in CVS now. Will be in Horde 3.0.2.

Wed, 05 Jan 2005 14:48:47 +0000

Should be fixed in CVS now. Will be in Horde 3.0.2.

I see this bug again with horde cvs-HEAD and imp cvs-HEAD. T

Sat, 19 May 2007 10:08:22 +0000

I see this bug again with horde cvs-HEAD and imp cvs-HEAD. The folder name is not displayed at all, but the icon is still clickable. Tested with Konqueror 3.5.6 and Firefox 1.5.

Can anyone else reproduce this?

Mon, 21 May 2007 18:37:26 +0000

Can anyone else reproduce this?

Not me.

Mon, 21 May 2007 22:01:53 +0000

Not me.

Thanks for reproducing, Jan. Gunnar can't reproduce it eith

Tue, 22 May 2007 08:51:01 +0000

Thanks for reproducing, Jan. Gunnar can't reproduce it either. If I switch the Horde_Tree renderer from javascript to HTML, the problem is gone. Maybe it's a charset issue, I use quite an old glibc. I'll try to investigate. Thomas

> I see this bug again with horde cvs-HEAD and imp cvs-HEAD.

Tue, 22 May 2007 08:54:53 +0000

> I see this bug again with horde cvs-HEAD and imp cvs-HEAD. The folder > name is not displayed at all, but the icon is still clickable. Tested > with Konqueror 3.5.6 and Firefox Are you sure this isn't a CSS issue? This same issue crops up time to time in DIMP and it always turns out to be an issue with overflow or something similar.

> Are you sure this isn't a CSS issue? As far as I have t

Tue, 22 May 2007 09:20:39 +0000

> Are you sure this isn't a CSS issue? As far as I have traced it yet, the folder name get's lost in Horde_Serialize::serialize(JSON). I'm currently debugging it.

Which charset is your interface using?

Tue, 22 May 2007 10:45:40 +0000

Which charset is your interface using?

> Which charset is your interface using? ISO-8559-1. H

Tue, 22 May 2007 13:41:52 +0000

> Which charset is your interface using? ISO-8559-1. Horde_Serialize::serialize(SERIALIZE_JSON) converts the input to UTF-8 anway. I was using a PCRE version without utf-8 support and so the following function call failed: preg_match_all("/(.{1})/su", $var, $m); This function is used to split a string into utf-8 characters. I've got it working now but maybe we need some kind of fallback code here.

> I was using a PCRE version without utf-8 support and so th

Tue, 22 May 2007 13:44:06 +0000

> I was using a PCRE version without utf-8 support and so the following > function call failed: We could also assume PCRE with utf-8 support is standard by now and we should add a test to test.php to display a warning if it's not compiled in.

>> Which charset is your interface using? > > ISO-8559-1.

Tue, 22 May 2007 14:00:39 +0000

>> Which charset is your interface using? > > ISO-8559-1. > > Horde_Serialize::serialize(SERIALIZE_JSON) converts the input to UTF-8 anway. Correct, JSON data must be UTF-8 encoded.

>> I was using a PCRE version without utf-8 support and so t

Tue, 22 May 2007 14:01:09 +0000

>> I was using a PCRE version without utf-8 support and so the following >> function call failed: > > We could also assume PCRE with utf-8 support is standard by now and > we should add a test to test.php to display a warning if it's not > compiled in. But how can you test this?

>> We could also assume PCRE with utf-8 support is standard

Tue, 22 May 2007 14:18:57 +0000

>> We could also assume PCRE with utf-8 support is standard by now and >> we should add a test to test.php to display a warning if it's not >> compiled in. > > But how can you test this? preg_match_all returns FALSE if you specify the "u" pattern modifier to enable utf-8 mode.

But it also returns false if it doesn't match, which is the

Tue, 22 May 2007 14:24:32 +0000

But it also returns false if it doesn't match, which is the whole purpose of preg_match().

> But it also returns false if it doesn't match, which is th

Tue, 22 May 2007 14:39:04 +0000

> But it also returns false if it doesn't match, which is the whole > purpose of preg_match(). It returns (int)0 if it doesn't match and (boolean)false if there's an error. Also we could use a pattern that always matches like this: echo "Result: ".preg_match("/.*/u", "test")."\n"; I just disabled utf-8 support again to test it. On the command line I have even seen an error message: "Warning: preg_match(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0."

BTW, this check: preg_match_all("/(.{1})/su", $var, $m); w

Tue, 22 May 2007 15:15:17 +0000

BTW, this check: preg_match_all("/(.{1})/su", $var, $m); was added precisely because the old code (using String functions) did not work in several cases. So a fallback function is most likely out of the question.

>> But it also returns false if it doesn't match, which is t

Tue, 22 May 2007 16:56:52 +0000

>> But it also returns false if it doesn't match, which is the whole >> purpose of preg_match(). > > It returns (int)0 if it doesn't match and (boolean)false if there's an error. > Also we could use a pattern that always matches like this: > > echo "Result: ".preg_match("/.*/u", "test")."\n"; > > I just disabled utf-8 support again to test it. On the command line I > have even seen an error message: > "Warning: preg_match(): Compilation failed: this version of PCRE is > not compiled with PCRE_UTF8 support at offset 0." I'm in favor of a test.php addition with this strategy.

Patch: Add test for PCRE and PCRE utf-8 support in test.php

Tue, 22 May 2007 17:25:38 +0000

Patch: Add test for PCRE and PCRE utf-8 support in test.php

Committed, thanks.

Tue, 22 May 2007 17:39:06 +0000

Committed, thanks.