The "Ticket OnlineEvents" search widget has problems with extended characters. I performed a search for "Münchener Freiheit" and got"Münchener Freiheit" as the search result.

It appears that the problem has to do with how the extended characters are converted into results, because if I enter the word with the extended character directly into the search box on the third party page, the results are fine.

lynn, please assign fr and de bugs to daniel mcgowan. thanks!

are the search results being returned as rdf? is this similar to http://bugzilla.mozilla.org/show_bug.cgi?id=35630

When I perform the search using extended characters (such as the "u" with the Umlaut in Münchener Freiheit, which incidentally doesn't appear correctly in Bugzilla) from the sidebar tab for TicketOnline, the result in the location bar is "http://www.ticketonline.de/cgi-bin/prlist.pl?C=1&MENU=NO&SB=M%C3%83%C2%BCnchene r%20Freiheit". When I perform the search directly from the TicketOnline site, the location bar result is "http://www.ticketonline.de/cgi-bin/prlist.pl". It doesn't show me any more information than that.

This is a problem with how the Ticket online search engine is recieving (encoding) the extended characters from their rendered page in the sidebar panel. The problem is here: <FORM ACTION="javascript:click('http://www.ticketonline.de/cgi-bin/prlist.pl?C=1&MENU= NO&SB=');" NAME="Formular" METHOD="POST" ENCTYPE="x-www-form-urlencoded"> I think that the ENCTYPE="x-www-form-urlencoded" should be different but I do not know what this should be.... This needs a serverside fix. Does anyone know who we should assign this to at TicketOnline? I will mail Linda baliman about it...

Reassigning to Linda Baliman as she's managing the 3rd party sidebar partners

*** Bug 35876 has been marked as a duplicate of this bug. ***

Karl-Heinz Dahlmann, ticketonline.de, added to cc-list Marked Not "Netscape Confidential"

This looks like an issue with client search functionality.

Related to bug 32324. Reassigned to Skrenta.

Added nsbeta2 keyword

Putting on [nsbeta2+] radar for beta2 fix.

Assiging to JLinley as he's fixing similar bugs

This bug should be fixed with the launch of UTF-8 encoded search on 6/1

why is this resolved as LATER? Shouldn't it be marked fixed but pending verification after 6/1?

reopening

This bug is still open. The sidebar search is currently working properly, so it is not clear that the problem lies with ODP. It appears to be either a problem with what query the NS6 client sends to TicketOnline or the way TicketOnline interprets extended characters in unicode format.

See if these attachments narrow-down the source of the problem for this tab. Search from the search widget in the Ticket Online tab fails in the same way as (2) search from the Ticket Online web page. Tab source code is at the above URL. Note that it was created using Adobe Page Mill, then modified. Adding Chau Dau and Frank Tang to cc-list. Marking NS confidential for now. Sorry for the multiple-attachements spam.

Linda, please ask the customer if they use UTF-8 (or unicode) encoding for their searches or if they use ISO-8859-1. It appears that the problem lies in the fact that the new browser is based on UTF-8 and that the customer uses a different type of encoding. If this is the case, there are two possible solutions that need to be discussed: either the customer changes their search system to comply with UTF-8 encoding (which is the universal encoding for all languages), or NS6 will need to be able to convert from UTF-8 to whatever encoding any possible future customer would require. I am reassigning this to you because Jared only handles ODP issues, and this issue is not related to him. If you feel that NS6 should handle all possible encodings, then please reassign to the appropriate US client engineer. Thank you.

With the 5/30 fix to bug 40199: Search files need to default to "ISO-8859-1", not "UTF-8" I'm surprised this is still happening. From the 6/12 screenshot, "(2) Ticket Online web page failing with ext chars using PR2" http://bugzilla.mozilla.org/showattachment.cgi?attach_id=10003 the problem is still occuring with the 6/9 (2000060808) build. Can someone verify if the search string being sent to www.ticketonline.de is utf-8 or iso-8859-1. FYI, to clarify, this previous comment is NOT true: It appears that the problem lies in the fact that the new browser is based on UTF-8 and that the customer uses a different type of encoding. If this is the case, there are two possible solutions that need to be discussed: either the customer changes their search system to comply with UTF-8 encoding (which is the universal encoding for all languages), or NS6 will need to be able to convert from UTF-8 to whatever encoding any possible future customer would require. The encoding used for the search string is determined by the definition in the *.src (aka sherlock) file in the searchplugins directory. Prior to the fix to bug 40199, if no encoding was specified in the *.src file, the default was utf-8. Now the default should be iso-8859-1.

The comment from the above message: "Can someone verify if the search string being sent to www.ticketonline.de is utf-8 or iso-8859-1." Is exactly what I was trying to point out. Sorry if it wasn't clear enough.

Adding myself to cc.

Reassigning to Frank Tang based on meeting June 16th

Changing QA contact to international QA at Laura Yecies request. blee@netscape.com at Teruko's suggestion. Adding Teruko@netscape.com to cc-list. Steps to reproduce: * Load Ticket Online My Sidebar Tab * Enter a search string in the Ticket Online search widget with some German characters, like Mu (with umlat) nich * Search fails and search string is corrupted (see attachments)

remove "DE:PR1 ". This is an internationalization feature, not tight to English build.

here is the fix Index: dom/src/base/nsGlobalWindow.cpp =================================================================== RCS file: /m/pub/mozilla/dom/src/base/nsGlobalWindow.cpp,v retrieving revision 1.303 diff -u -r1.303 nsGlobalWindow.cpp --- nsGlobalWindow.cpp 2000/06/22 01:39:40 1.303 +++ nsGlobalWindow.cpp 2000/06/22 17:28:07 @@ -2674,9 +2674,11 @@ JSString *mJSStrURL = JS_ValueToString(cx, argv[0]); NS_ENSURE_TRUE(mJSStrURL, NS_ERROR_FAILURE); - nsAutoString mURL; - mURL.Assign(NS_REINTERPRET_CAST(const PRUnichar*, JS_GetStringChars(mJSStrURL))); + nsAutoString unescapedURL; + unescapedURL.Assign(NS_REINTERPRET_CAST(const PRUnichar*, JS_GetStringChars(mJSStrURL))); + nsAutoString mURL; + Escape(unescapedURL, mURL); if(!mURL.IsEmpty()) { nsAutoString mAbsURL; Index: netwerk/base/public/nsNetUtil.h =================================================================== RCS file: /m/pub/mozilla/netwerk/base/public/nsNetUtil.h,v retrieving revision 1.18 diff -u -r1.18 nsNetUtil.h --- nsNetUtil.h 2000/06/03 09:45:23 1.18 +++ nsNetUtil.h 2000/06/22 17:28:07 @@ -216,7 +216,8 @@ nsMemory::Free(specStr); if (NS_FAILED(rv)) return rv; - result.AssignWithConversion(resultStr); + result.Assign(NS_ConvertUTF8toUCS2(resultStr)); + nsMemory::Free(resultStr); return rv; }

I check in the necko fix. The nsGlobalWindow.cpp fix is not good. I need more time to work on it.

ok, I check in the new nsGlobalWindow.cpp patch. The HTML form should work now.

"münchen" showed up correctly in search result when tried in Win32 070508 bld. Marking verified

Verified fixed. Closing.

*** Bug 35876 has been marked as a duplicate of this bug. ***