6.0.0-git
2021-01-18

Summary
Queue Horde Base
Queue Version 3.0
Type Bug
State Resolved
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester mail (at) flobauer (dot) net
Created 2005-01-02 (5860 days ago)
Due
Updated 2007-05-22 (4990 days ago)
Assigned 2007-05-21 (4991 days ago)
Resolved 2007-05-22 (4990 days ago)
Milestone
Patch No

History
2007-05-22 17:39:06 Chuck Hagenbuch Comment #25
State ⇒ Resolved
Reply to this comment
Committed, thanks.
2007-05-22 17:25:38 thomas (dot) jarosch (at) intra2net (dot) com Comment #24
New Attachment: horde-test-pcre-tests.patch Download
Reply to this comment
Patch: Add test for PCRE and PCRE utf-8 support in test.php


2007-05-22 16:56:52 Chuck Hagenbuch Comment #23 Reply to this comment

[Show Quoted Text - 12 lines]
I'm in favor of a test.php addition with this strategy.
2007-05-22 15:15:17 Michael Slusarz Comment #22 Reply to this comment
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.
2007-05-22 14:39:04 thomas (dot) jarosch (at) intra2net (dot) com Comment #21 Reply to this comment
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."


2007-05-22 14:24:32 Jan Schneider Comment #20 Reply to this comment
But it also returns false if it doesn't match, which is the whole 
purpose of preg_match().
2007-05-22 14:18:57 thomas (dot) jarosch (at) intra2net (dot) com Comment #19 Reply to this comment
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.
2007-05-22 14:01:09 Jan Schneider Comment #18 Reply to this comment
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?
2007-05-22 14:00:39 Jan Schneider Comment #17 Reply to this comment
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.
2007-05-22 13:44:06 thomas (dot) jarosch (at) intra2net (dot) com Comment #16 Reply to this comment
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.


2007-05-22 13:41:52 thomas (dot) jarosch (at) intra2net (dot) com Comment #15 Reply to this comment
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.
2007-05-22 10:45:40 Jan Schneider Comment #14 Reply to this comment
Which charset is your interface using?
2007-05-22 09:20:39 thomas (dot) jarosch (at) intra2net (dot) com Comment #13 Reply to this comment
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.


2007-05-22 08:54:53 Michael Slusarz Comment #12 Reply to this comment
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.
2007-05-22 08:51:01 thomas (dot) jarosch (at) intra2net (dot) com Comment #11 Reply to this comment
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


2007-05-21 22:01:53 Jan Schneider Comment #10 Reply to this comment
Not me.
2007-05-21 18:37:26 Chuck Hagenbuch Comment #9
State ⇒ Feedback
Reply to this comment
Can anyone else reproduce this?
2007-05-19 10:08:22 thomas (dot) jarosch (at) intra2net (dot) com Comment #8 Reply to this comment
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.


2005-01-05 14:48:47 Jan Schneider Comment #7
State ⇒ Resolved
Reply to this comment
Should be fixed in CVS now. Will be in Horde 3.0.2.
2005-01-05 14:28:15 Jan Schneider State ⇒ Assigned
 
2005-01-05 10:03:31 mail (at) flobauer (dot) net Comment #6 Reply to this comment
Both have ISO-8859-1 and refresh do not change anything.
2005-01-03 17:56:02 Jan Schneider Comment #5
State ⇒ Feedback
Reply to this comment
What charset do the "normal" pages have, what charset does the menu 
have, and does it change after the menu refreshed?
2005-01-03 00:35:02 Chuck Hagenbuch Assigned to Jan Schneider
State ⇒ Assigned
 
2005-01-02 14:49:01 mail (at) flobauer (dot) net Comment #4 Reply to this comment
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 '<a' + urlClass + ' href="' + this.nodes[nodeId]['url'] + '"' + 
target + onclick + '>' + label + '</a>';



Dirty hack, but it works .... would be good to find out, why this "\0" 
thing happens.


2005-01-02 12:10:17 mail (at) flobauer (dot) net Comment #3 Reply to this comment
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)
2005-01-02 11:57:57 Jan Schneider State ⇒ Feedback
 
2005-01-02 11:57:43 Jan Schneider Comment #2 Reply to this comment
Might be a duplicate of bug 809. Please confirm, and if so, find some 
common points of both your  systems.
2005-01-02 11:38:20 mail (at) flobauer (dot) net Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Sidebar, Problem with umlaut (ä,ö,..) in IE
Queue ⇒ Horde Base
Reply to this comment
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


Saved Queries