All users were logged out of Bugzilla on October 13th, 2018
STEPS TO REPRODUCE 1. Go to http://☺.damowmow.com/. (Or, go to http://damowmow.com/portal/ and click the header at the top.) 2. Click Help | Report Broken Web Site. 3. Choose Problem Type: Other Problem. 4. Click Next. 5. Look up the report in http://reporter.mozilla.org/. ACTUAL RESULTS URI on site is "http://?.damowmow.com/". http://reporter-test.mozilla.org/app/report/?report_id=RMO11184143084248 EXPECTED RESULTS URI should be "http://☺.damowmow.com/".
Whiteboard: This bug report is filed in UTF-8. Please check your encoding.
It's being dropped somewhere before the database server. That leaves: Mozilla, or the server to blame. Anyone willing to sniff packets and see how mozilla sends the request? Is it UTF-8 when it's sent to the server? you can use reporter-dev.mozilla.org for testing purposes. set extensions.reporter.serviceURL to http://reporter-dev.mozilla.org/service/ the dev server has some updated libraries, so it may be worth checking there just to see if it's resolved on it's own.
I could use some help diagnosing this.
Created attachment 185978 [details] Dump Looks like it's client side somewhere: <url xmlns:ns1="http://www.w3.org/1999/XMLSchema" xsi:type="ns1:string">http://....damowmow.com/</url> should be sending it as utf-8.
Ok, it doesn't appear to be the service. I'm looking elsewhere.
Uh, look closer (at the hex). What you're being sent is e2 98 ba, which looks to me like the UTF-8 encoded form of a ☺. (It appears as "."s in the ASCII side because those are high-bit characters.) So I would say that the client is doing the right thing.
Yes, I (in the past few hours) agree. I think it's database related. I'll look into it closer in coming days.
Perhaps php (or whatever the sever side script is written in) is not decoding it correctly? But yeah, the soap/web service code is fully utf-8 aware :) I assume you are using a mysql db? http://www.shawnolson.net/a/946/ might help.
Thanks Doron. Unfortuantely we are on PHP 4.3.x and mySQL 4.0.x. I'm still researching what's going on, and where we are dropping the ball. I started client side, just in case something was broken there (so we could get it fixed quick before 1.1). Since it's server side, we can deploy after release. Were not bound to the restraints of the release cycle.
(In reply to comment #8) > Unfortuantely we are on PHP 4.3.x and mySQL 4.0.x. I'm still researching PHP 4.3.x can support multibyte encodings including UTF-8 fine with mbstring and iconv modules. In case of mySQL 4.0.x, I'm not sure, but you can just store UTF-8 strings. Sorting and character counting wouldn't work properly, but data 'loss' can be avoided with a little 'manual' fix-up.
jshin: correct. Though that's up to justdave and our super admin's to evaluate/fix. Were not going to be on the current server for too long. Not sure what the new servers will be running.
renaming to be a bit more accurate.
Summary: IDN not supported → IDN not supported (no UTF-8 support)
*** Bug 308598 has been marked as a duplicate of this bug. ***
*** Bug 322342 has been marked as a duplicate of this bug. ***
This is fixed in the new version of reporter. The problem was on the server side, so when the new server is deployed, all clients will be functioning correctly (no client side update needed) It's not deployed as of yet, but the bug is fixed. Someone can verify when we upgrade.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
When will the upgrade be deployed?
(In reply to comment #15) > When will the upgrade be deployed? > Hopefully sooner than later. I'm hoping to be feature complete by the end of the month, and perhaps do some testing in February. The other option is to back-port this patch to the production instance. I can talk to Dave Miller about that. I'd obviously prefer to wait at this point. We don't seem to have that many reports effected, and only a hand full of bugs after several months since reporter went into production. This might be a discussion worth having. Not sure.
*** Bug 325166 has been marked as a duplicate of this bug. ***
It's already March but actually not resolved yet. So, I reopen this bug. Here is test reports with multibyte string and IDN. http://reporter.mozilla.org/app/report/?report_id=RMO11444886628826&submit_reportID=Lookup+Report http://reporter.mozilla.org/app/report/?report_id=RMO11444885744102&submit_reportID=Lookup+Report
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oops, it's already April, not March.
Please don't re-open bugs without cause. The bug is resolved. The production instance has not been updated with this code. That's another topic, and another component. This bug is specific to the code, not instances hosted by mozilla.org. Reopening bugs like this makes it rather hard to track my todo list. The server will be upgraded when the code is stable. That still is a few weeks away. My current target is by the end of May. Yes it's slipped, and I apologize for that that. Thanks.
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → FIXED
It still reproduces though it tried today. http://reporter.mozilla.org/app/report/?report_id=RMO11577378288494&submit_reportID=Lookup+Report
Is there anyone working on this? "That still is a few weeks away," and 2 YEARs passed. People need this tool to report website, or please remove the menuitem in Help menu of builds other than English.
Test again, the description part in new reports successfully display UTF-8, but the old ones still shows "?".
You need to log in before you can comment on or make changes to this bug.