Closed
Bug 464992
Opened 16 years ago
Closed 15 years ago
Binary attachments, graphical reports and new charts are not displayed correctly on Windows
Categories
(Bugzilla :: Attachments & Requests, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.2
People
(Reporter: Eric.Olson, Assigned: LpSolit)
References
Details
(Keywords: regression)
Attachments
(6 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: 3.2rc2 Binary attachments are not displaying properly. After uploading an image attachment (tried with bmp, gif, png, jpg, and pdf), attempting to display the attachment usually gives an error "The image http://[my domain]/bugzilla-3.2rc2/attachment.cgi?id=5 cannot be displayed because it contains errors." This only seems to happen on my install of version 3.2rc2. I have been unable to replicate this problem with a brand-new install of 3.0.6. If I get the XML version of the bug, cut and paste the attachment information out of it, and manually decode the base64 text, the attachment comes out fine. I've also checked the contents of the attach_data table for the 3.2rc2 and 3.0.6 installs, and they appear to be identical. I've also been unable to replicate this at landfill.bugzilla.org. Reproducible: Always Steps to Reproduce: 1. Attach a binary attachment, auto-detecting the content type. 2. Attempt to display the attachment, either by clicking on the attachment name or the Details link. Actual Results: A corrupted binary file that doesn't display properly. I'm running on Windows XP, Apache 2.2, and mySQL 5.0.
Assignee | ||
Comment 1•16 years ago
|
||
I cannot reproduce the problem, neither on Linux nor Windows. I tested with BMP and JPG files, and both display correctly. Also, the fact that you cannot reproduce on landfill may indicate a problem with your installation, either your copy of Bugzilla or your web server.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 3.2
Comment 2•16 years ago
|
||
1. And what content-types were auto-detected? 2. Could you reproduce on the same instance with other browser (Firefox?)
Assignee | ||
Comment 3•16 years ago
|
||
(In reply to comment #2) > 1. And what content-types were auto-detected? Yeah, content-types are sent by the browser. If IE6 sends wrong content-types, that's a bug in IE6, not in Bugzilla. FYI, I tested with Firefox 3.1.
Reporter | ||
Comment 4•16 years ago
|
||
1. Content types were correctly auto-detected as image/gif, image/png, etc. I've also tried selecting the type from the drop down box when uploading an attachment and even by typing it in manually. 2. I can reproduce this on Firefox 3.0.4 and IE7 under Windows and Konqueror under Linux. 3. If this was a misconfiguration somewhere in the webserver, I'd expect the problem to happen under both 3.0 and 3.2, not just 3.2. I tried setting the default Apache content type as application/octet-stream, but that had no effect. I can't find any relevant Bugzilla configuration parameter to experiment with.
Comment 5•16 years ago
|
||
So one can tell it is _stored_ correctly, but somehow _served_ wrong? Test proposal: use 'wget -v' to save the link . Then compare original and served file, and also look for any pecularities in http reported by wget.
Reporter | ||
Comment 6•16 years ago
|
||
There were no differences in the http reported by wget. I'm now pretty sure this is some sort of character encoding issue. I created a binary file consisting only of the 255 bytes 0x00 0x01 ... 0xFF and used that as my attachment. When I view or download the attachment, bytes less that 0x80 are fine. Anything above 0x80 comes back as two bytes, with 0xC2 as the first byte. The file is also truncated to the same length as the original file. The attachment is intact in the attach_data table, because SELECT ... INTO OUTFILE binaryfile.txt gives me the original binary contents (with some special characters, e.g. 0x00, escaped). So it looks like the attachment is getting encoded as UTF-8 instead of left as plain binary. This still happens only with my install of 3.2rc2, not with my install of 3.0.6 or with the landfill.bugzilla.org 3.2 branch.
Comment 7•16 years ago
|
||
1. What MySQL charset is used by your database? 2. Kindly attach output of `checksetup.pl --check-modules`
Comment 8•16 years ago
|
||
3. Do not laugh, but: can you reproduce bug 457524 on your instance?
Reporter | ||
Comment 9•16 years ago
|
||
1. According to mySQL: character_set_client latin1 character_set_connection latin1 character_set_database utf8 character_set_filesystem binary character_set_results latin1 character_set_server latin1 2. See attached. 3. Yes I can. After installing the Russian localization (though I'm not sure how to start *using* it; everything's still in English), bugs made against a component with a Russian name do not show up in tabular reports.
Reporter | ||
Comment 10•16 years ago
|
||
Results of "perl checksetup.pl --check-modules"
Comment 11•16 years ago
|
||
I have exactly the same problem on Windows 2008 Server Standard x64 SP1 Russian with last installed updates, Apache 2.2.8 x86, Perl 5.8.8 x86, Bugzilla 3.2 english release (without localization). MySQL character sets: character_set_client utf8 character_set_connection utf8 character_set_database utf8 character_set_filesystem binary character_set_results utf8 character_set_server utf8 character_set_system utf8 collation_connection utf8_general_ci collation_database utf8_general_ci collation_server utf8_general_ci Results of checksetup.pl --check-modules: * This is Bugzilla 3.2 on perl 5.8.8 * Running on WinVista Build 6001 (Service Pack 1) Checking perl modules... Checking for CGI.pm (v3.21) ok: found v3.41 Checking for TimeDate (v2.21) ok: found v2.22 Checking for PathTools (v0.84) ok: found v3.2701 Checking for DBI (v1.41) ok: found v1.607 Checking for Template-Toolkit (v2.15) ok: found v2.20 Checking for Email-Send (v2.16) ok: found v2.192 Checking for Email-MIME (v1.861) ok: found v1.861 Checking for Email-MIME-Modifier (v1.442) ok: found v1.442 Checking available perl DBD modules... Checking for DBD-Pg (v1.45) not found Checking for DBD-mysql (v4.00) ok: found v4.005 Checking for DBD-Oracle (v1.19) ok: found v1.21 The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.41 Checking for Chart (v1.0) ok: found v2.3 Checking for Template-GD (any) ok: found v1.56 Checking for GDTextUtil (any) ok: found v0.86 Checking for GDGraph (any) ok: found v1.44 Checking for XML-Twig (any) ok: found v3.32 Checking for MIME-tools (v5.406) ok: found v5.427 Checking for libwww-perl (any) ok: found v5.814 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for PerlMagick (any) not found Checking for perl-ldap (any) ok: found v0.39 Checking for Authen-SASL (any) ok: found v2.12 Checking for RadiusPerl (any) ok: found v0.13 Checking for SOAP-Lite (any) ok: found v0.69 Checking for HTML-Parser (v3.40) ok: found v3.59 Checking for HTML-Scrubber (any) ok: found v0.08 Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.315 Checking for Email-Reply (any) ok: found v1.202 Checking for mod_perl (v1.999022) not found Checking for CGI.pm (v3.11) ok: found v3.41
Comment 12•16 years ago
|
||
Another symptom likely introduced by attachment 286357 [details] [diff] [review] You may try to revert this patch and check the result.
Comment 13•16 years ago
|
||
I've manually reverted this patch and now attachments displayed correctly. But now it's unable to use localization (Russian), because all non-ascii characters in form fields displayed incorrectly.
Comment 14•16 years ago
|
||
The problem has also solved by another way: on clean installation of Bugzilla 3.2 (release) I've changed file "Bugzilla/Util.pm": sub disable_utf8 { if (Bugzilla->params->{'utf8'}) { # binmode STDOUT, ':raw'; # Turn off UTF8 encoding. binmode STDOUT, ':bytes'; # Turn off UTF8 encoding (old method, but it's work!). } }
Comment 15•16 years ago
|
||
Could someone try :bytes on Unix? If harmless, it may not be a workaround but a solution...
Updated•16 years ago
|
Flags: blocking3.2.1?
Comment 16•16 years ago
|
||
I've seen a few people report this. I can't say whether or not it's a blocker, though, until we understand more about it. Is this a bug in ActiveState, or...?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 17•16 years ago
|
||
Could someone attach the broken binary attachiment file? Save from browsers or via 'wget'-liked program.
Comment 18•16 years ago
|
||
Yes, I could. The first file is original binary file named "x00-xFF_original.bin", containing 256 bytes from x00 to xFF in succession, when I was creating this attachment in Bugzilla, I manually defined the content-type as "application/octet-stream". The second file named "x00-xFF_downloaded.bin" is file downloaded from Bugzilla (from Opera 9.62).
Comment 19•16 years ago
|
||
Comment 20•16 years ago
|
||
Reporter | ||
Comment 21•16 years ago
|
||
This may affect graphical reports, as well. See http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/f86fec59c2fa99f5#
Comment 22•16 years ago
|
||
Hmmm, do you think it's possible that the underlying problem is the same as the one of bug 467920?
Comment 23•16 years ago
|
||
Yes, bug 469794, bug 467920 share the same root cause: patch from bug 363153. Noticed by himorin.
Comment 24•16 years ago
|
||
OK. I confirm this problem as an utf8 related one. But cannot confirm as bugzilla's one, now. b/c I've not read codes. As attached file, each raw byte are transcoded with utf-8's bit pattern. Like, \u80 to \u7FF (0000 0aaa bbbb cccc) => 110a aabb 10bb cccc And data 'might be' truncated to the original attachment size. I think we should confirm whether the data registoration procedure is wrong or the data retrieve procedure is wrong. Leonid, if you can access to the detabase, could you try the following SQL? SELECT BIT_LENGTH(thedata) FROM attach_data WHERE id = <attach-id>; (mysql)
Comment 25•16 years ago
|
||
(In reply to comment #24) > Leonid, if you can access to the detabase, could you try the following SQL? > SELECT BIT_LENGTH(thedata) FROM attach_data WHERE id = <attach-id>; (mysql) ah, of cource, the aim of this is to check WHERE the data is transcoded. If file size at attaching != size at database, we should check the attaching code. If not, i think we should focus on the downloading code.
Comment 26•16 years ago
|
||
That's it: mysql> SELECT BIT_LENGTH(thedata) FROM attach_data WHERE id = 1; +---------------------+ | BIT_LENGTH(thedata) | +---------------------+ | 2048 | +---------------------+ 1 row in set (0.00 sec)
Comment 28•16 years ago
|
||
Did some quick trial-and-error changes (as I needed to get attachments working again) and was able to fix it for me by removing the changes in Bugzilla.pm introduced in attachment 286357 [details] [diff] [review] - didn't do a full test (just added an attachment and opened it as well as a couple of old ones). Didn't touch the other files. Hope that helps.
Comment 29•16 years ago
|
||
Hi, On a clean install i managed to get my attachements working by following Comment #14 From Leonid Rogov. But Graphs (New chart and Graphical Reports) do not work.
Comment 30•16 years ago
|
||
I confirm the last comment from Mubashir, my bugzilla also has the broken chart and report images with or without having changes from comment #14.
Comment 31•16 years ago
|
||
It looks like to me as there are two problems which are independent of each other. One to do with the attachements and the second with the Graphiacl reports. So may be we should raise a new bug against component Reporting/Charting. Let me know if any one disagree with it else i will try to raise a bug as more and more people are complaining about it now. Regards, Mubashir
Comment 32•16 years ago
|
||
Confirmed for Bugzilla 3.2 on Windows Server 2003 x64, MySQL 5.1.30, Apache 2.0.63 Comment #14 solved this issue for attachments for me. Graphs etc. still do not work. Is there already a "new bug against component Reporting/Charting" ?!
Comment 33•16 years ago
|
||
Yes, i have recently raised a bug against Reporting/Charting component for graphical report and new charts problem. https://bugzilla.mozilla.org/show_bug.cgi?id=470486 (Bug number 470486).
Assignee | ||
Comment 34•15 years ago
|
||
As I said in bug 470486 comment 4, I cannot reproduce your problem on http://windows.bugzilla.org/qa32win/ which is running Windows 2003.
Comment 35•15 years ago
|
||
See bug 470486 comment 7 for details
Comment 36•15 years ago
|
||
(In reply to comment #34) > As I said in bug 470486 comment 4, I cannot reproduce your problem on > http://windows.bugzilla.org/qa32win/ which is running Windows 2003. What version of perl is this server using? Isn't it perl 5.10? I could reproduce with using perl 5.8.8 on Windows Server 2003. .bin.orig is the original file uploaded, .bin is the downloaded file from bugzilla 3.2 on Windows Server 2003. % ls -l x00-xFF_original.bin* 384 Dec 30 16:46 x00-xFF_original.bin 256 Dec 30 16:45 x00-xFF_original.bin.orig
Comment 37•15 years ago
|
||
(In reply to comment #36) > I could reproduce with using perl 5.8.8 on Windows Server 2003. Sorry. 5.8.9.
Comment 38•15 years ago
|
||
Same for perl 5.8.8 (824). # And i've failed and destroied my test environment :-D
Comment 39•15 years ago
|
||
One important update: The work around provided in comment # 14 will enable you to view or download the existing attachments but you wont be able to add new attachments to the bugs. i.e. without modifying the original file you can add attachments but can't view it. With modification, you can view them but not add new attachments. I've also got machine with Bugzilla 3.2 running on Windows XP. Let me know if you need anything which could help you with investigation for this problem.
Comment 40•15 years ago
|
||
Unable to reproduce on: * This is Bugzilla 3.2 on perl 5.10.0 * Running on WinXP/.Net Build 2600 (Service Pack 2) Checking perl modules... Checking for CGI.pm (v3.33) ok: found v3.41 Checking for TimeDate (v2.21) ok: found v2.22 Checking for PathTools (v0.84) ok: found v3.2501 Checking for DBI (v1.41) ok: found v1.607 Checking for Template-Toolkit (v2.15) ok: found v2.20 Checking for Email-Send (v2.16) ok: found v2.192 Checking for Email-MIME (v1.861) ok: found v1.861 Checking for Email-MIME-Modifier (v1.442) ok: found v1.442 Checking available perl DBD modules... Checking for DBD-Pg (v1.45) not found Checking for DBD-mysql (v4.00) ok: found v4.005 Checking for DBD-Oracle (v1.19) not found The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.41 Checking for Chart (v1.0) ok: found v2.4.1 Checking for Template-GD (any) ok: found v1.56 Checking for GDTextUtil (any) ok: found v0.86 Checking for GDGraph (any) ok: found v1.44 Checking for XML-Twig (any) ok: found v3.32 Checking for MIME-tools (v5.406) ok: found v5.427 Checking for libwww-perl (any) ok: found v5.814 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for PerlMagick (any) not found Checking for perl-ldap (any) ok: found v0.39 Checking for Authen-SASL (any) ok: found v2.12 Checking for RadiusPerl (any) ok: found v0.13 Checking for SOAP-Lite (any) ok: found v0.69 Checking for HTML-Parser (v3.40) ok: found v3.59 Checking for HTML-Scrubber (any) ok: found v0.08 Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.315 Checking for Email-Reply (any) ok: found v1.202 Checking for mod_perl (v1.999022) ok: found v2.000004
Comment 41•15 years ago
|
||
I had this problem with MS Word file attachments on Bugzilla 3.2/Windows Server 2003/Perl 5.8.8/MySQL 5.0.67. Charting was also broken. Saving the blob data to disk from the 'thedata' column of the 'attach_data' table in my 'bugs' database confirmed that the files had been uploaded properly, and that the problem lies in the download. Upgrading Perl to 5.10.0 fixed the attachment and charting problems for me.
Comment 42•15 years ago
|
||
> Upgrading Perl to 5.10.0 fixed the attachment and charting problems for me.
Could you compare Perl module versions before and after upgrade? Or at least post your current module versions?
Comment 43•15 years ago
|
||
> Could you compare Perl module versions before and after upgrade? Or at least > post your current module versions? Here's the after, didn't get a before unfortunately. * This is Bugzilla 3.2 on perl 5.10.0 * Running on Win2003 Build 3790 (Service Pack 2) Checking perl modules... Checking for CGI.pm (v3.33) ok: found v3.41 Checking for TimeDate (v2.21) ok: found v2.22 Checking for PathTools (v0.84) ok: found v3.2501 Checking for DBI (v1.41) ok: found v1.607 Checking for Template-Toolkit (v2.15) ok: found v2.20 Checking for Email-Send (v2.16) ok: found v2.194 Checking for Email-MIME (v1.861) ok: found v1.861 Checking for Email-MIME-Modifier (v1.442) ok: found v1.442 Checking available perl DBD modules... Checking for DBD-Pg (v1.45) not found Checking for DBD-mysql (v4.00) ok: found v4.005 Checking for DBD-Oracle (v1.19) ok: found v1.21 The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.41 Checking for Chart (v1.0) ok: found v2.4.1 Checking for Template-GD (any) ok: found v1.56 Checking for GDTextUtil (any) ok: found v0.86 Checking for GDGraph (any) ok: found v1.44 Checking for XML-Twig (any) ok: found v3.32 Checking for MIME-tools (v5.406) ok: found v5.427 Checking for libwww-perl (any) ok: found v5.814 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for PerlMagick (any) not found Checking for perl-ldap (any) ok: found v0.39 Checking for Authen-SASL (any) ok: found v2.12 Checking for RadiusPerl (any) ok: found v0.13 Checking for SOAP-Lite (any) ok: found v0.69 Checking for HTML-Parser (v3.40) ok: found v3.56 Checking for HTML-Scrubber (any) ok: found v0.08 Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.315 Checking for Email-Reply (any) ok: found v1.202 Checking for mod_perl (v1.999022) ok: found v2.000004 * NOTE: You must run any commands listed below as Administrator. *********************************************************************** * Note For Windows Users * *********************************************************************** * In order to install the modules listed below, you first have to run * * the following command as an Administrator: * * * * ppm repo add theory58S http://cpan.uwinnipeg.ca/PPMPackages/10xx/ * * *********************************************************************** ********************************************************************** * OPTIONAL MODULES * ********************************************************************** * Certain Perl modules are not required by Bugzilla, but by * * installing the latest version you gain access to additional * * features. * * * * The optional modules you do not have installed are listed below, * * with the name of the feature they enable. If you want to install * * one of these modules, just run the appropriate command in the * * "COMMANDS TO INSTALL" section. * ********************************************************************** *********************************************************************** * MODULE NAME * ENABLES FEATURE(S) * *********************************************************************** * PerlMagick * Optionally Convert BMP Attachments to PNGs * *********************************************************************** COMMANDS TO INSTALL: PerlMagick: ppm install PerlMagick
Comment 44•15 years ago
|
||
(In reply to comment #39) > One important update: The work around provided in comment # 14 will enable you > to view or download the existing attachments but you wont be able to add new > attachments to the bugs. I can upload and download attachments with this workaround.
Comment 45•15 years ago
|
||
There is a new development on this one. I have recently installed Bugzilla 3.2 with the latest MySQL, Perl on Windows Vista 32 bit machine with Apache webserver. The only difference this time is in the past i was using XP with IIS and installed bugzilla using Tar ball where attachments seem to fail. This time i installed it using CVS (fresh install) with Apache, and attachments seem to be working fine without any workaround.
Assignee | ||
Comment 47•15 years ago
|
||
Confirming the bug per the number of users complaining in the support newsgroup. I have a patch which has been successfully tested by a user affected by the problem. Please apply the patch to your installation too, and tell me if it also fixes the problem for you.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Binary attachments not displaying correctly → Binary attachments, graphical reports and new charts are not displayed correctly on Windows
Target Milestone: --- → Bugzilla 3.2
Assignee | ||
Comment 48•15 years ago
|
||
Test this. And if someone understands why ':bytes' fixes the problem on Windows, please explain to me, because I have absolutely no idea.
Comment 49•15 years ago
|
||
Comment on attachment 356063 [details] [diff] [review] patch, v1 :bytes is the opposite of :utf8. So it would be appropriate for it to be in disable_utf8. However, you'd still have to do "binmode STDOUT" in places where STDOUT is supposed to be spewing binary data. See http://perldoc.perl.org/PerlIO.html
Attachment #356063 -
Flags: review? → review-
Assignee | ||
Comment 50•15 years ago
|
||
(In reply to comment #49) > :bytes is the opposite of :utf8. So it would be appropriate for it to be in > disable_utf8. However, you'd still have to do "binmode STDOUT" in places where > STDOUT is supposed to be spewing binary data. Yeah, but this patch is more a workaround than a real fix. I didn't want to introduce other regressions.
Comment 51•15 years ago
|
||
Hi Frédéric, The patch has fixed the problem on my faulty XP machine running with IIS and Bugzilla 3.2. Both attachments and graphs / charts are working fine. Thanks, Mubashir
Assignee | ||
Comment 52•15 years ago
|
||
OK, now that we know my patch fixes problems on Windows, it makes sense to wait for it before releasing 3.2.1.
Flags: blocking3.2.1? → blocking3.2.1+
Keywords: qawanted → regression
Comment 53•15 years ago
|
||
(In reply to comment #50) > Yeah, but this patch is more a workaround than a real fix. I didn't want to > introduce other regressions. Okay. Let's come up with a solid fix for the tip and then see if we can do a hacky fix for the branch if necessary, then.
Comment 54•15 years ago
|
||
(In reply to comment #48) > Created an attachment (id=356063) [details] > patch, v1 > > Test this. And if someone understands why ':bytes' fixes the problem on > Windows, please explain to me, because I have absolutely no idea. Ok. I confirm this patch working well (for the attachment issue) on my windows test server. (perl 5.8.9 on Windows 2003 Server, modules are the same as the previous attachment.) And, doesn't harm on debian 4.0 test server. (below) * This is Bugzilla 3.2 on perl 5.8.8 * Running on Linux 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007
Comment 55•15 years ago
|
||
Confirm, this work for attachments, graph-reports and charts. Bugzilla 3.2 Perl 5.8.8 Windows 2008 Server Std Russian
Comment 56•15 years ago
|
||
I think this is something a bug on ActivePerl. With attached script, output should be >c:\Perl\bin\perl.exe perlio.pl 5.10.0 crlf utf8 crlf crlf But, with using 5.8.9 whose downloaded attachment is broken, >c:\perl\bin\perl.exe perlio.pl 5.8.9 crlf utf8 utf8 crlf
Comment 57•15 years ago
|
||
(In reply to comment #56) > I think this is something a bug on ActivePerl. Hmm. Are you saying this works in 5.10? In any case, now that you have that test script, we should probably report the bug to ActiveState. They have a Bugzilla here: http://bugs.activestate.com/
Assignee | ||
Comment 58•15 years ago
|
||
OK, here is a nicer patch. I checked, and only attachments use disable_utf8(), so there are much less places using it than expected, which limits the risk to regress something. :) To all of you who tested my previous patch, could you test this new one please, and tell me if it still works correctly for you? Many thanks! And thanks again to Rob Jackson who already tested my patch on his installation (successfully).
Attachment #356063 -
Attachment is obsolete: true
Attachment #356992 -
Flags: review?(mkanat)
Updated•15 years ago
|
Attachment #356992 -
Flags: review?(mkanat) → review+
Comment 59•15 years ago
|
||
Comment on attachment 356992 [details] [diff] [review] patch, v2 >Index: report.cgi >+disable_utf8() if ($format->{'ctype'} eq 'image/png'); We should probably just check if it starts with "image/" in case somebody has modified the types of report images their installation sends. Otherwise, in testing this works fine, so let's just fix the above thing on checkin.
Assignee | ||
Comment 60•15 years ago
|
||
(In reply to comment #59) > We should probably just check if it starts with "image/" in case somebody has > modified the types of report images their installation sends. OK, I will do that.
Flags: approval3.2+
Flags: approval+
Assignee | ||
Comment 61•15 years ago
|
||
tip: Checking in chart.cgi; /cvsroot/mozilla/webtools/bugzilla/chart.cgi,v <-- chart.cgi new revision: 1.28; previous revision: 1.27 done Checking in report.cgi; /cvsroot/mozilla/webtools/bugzilla/report.cgi,v <-- report.cgi new revision: 1.44; previous revision: 1.43 done Checking in Bugzilla/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v <-- Util.pm new revision: 1.80; previous revision: 1.79 done 3.2: Checking in chart.cgi; /cvsroot/mozilla/webtools/bugzilla/chart.cgi,v <-- chart.cgi new revision: 1.26.2.1; previous revision: 1.26 done Checking in report.cgi; /cvsroot/mozilla/webtools/bugzilla/report.cgi,v <-- report.cgi new revision: 1.41.2.1; previous revision: 1.41 done Checking in Bugzilla/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v <-- Util.pm new revision: 1.69.2.7; previous revision: 1.69.2.6 done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → FIXED
Comment 62•15 years ago
|
||
OK, the patch v2 is worked, thanks. Also thanks that you have used my idea (from comment #14) for a basis of this patch =)
Comment 63•15 years ago
|
||
(In reply to comment #57) > > I think this is something a bug on ActivePerl. > > Hmm. Are you saying this works in 5.10? Yes. Works in ActivePerl/5.10 and perl on cygwin or linux box etc. This is consistent with the reports to us about this bug. # If it possible, and i think it's possible with some util function (used in checksetup.pl to get ActivePerl revision), might it be better to filter whether to use :raw or :bytes in disable_utf8()? > In any case, now that you have that test script, we should probably report > the bug to ActiveState. They have a Bugzilla here: > > http://bugs.activestate.com/ filed. http://bugs.activestate.com/show_bug.cgi?id=81631
You need to log in
before you can comment on or make changes to this bug.
Description
•