Last Comment Bug 376044 - When using mod_perl "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi sometimes return HTML as text
: When using mod_perl "Change Columns" and "Reset to Bugzilla Default" buttons ...
Status: RESOLVED FIXED
:
Product: Bugzilla
Classification: Server Software
Component: Query/Bug List (show other bugs)
: 3.0
: All All
: P1 major (vote)
: Bugzilla 3.6
Assigned To: Max Kanat-Alexander
: default-qa
Mentors:
http://arswiki.org/bugs/
: 413948 437555 444140 466064 476388 488324 553060 561067 (view as bug list)
Depends on: 24896
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-30 14:33 PDT by Axton Grams
Modified: 2010-07-21 18:54 PDT (History)
23 users (show)
LpSolit: approval+
LpSolit: approval3.6+
LpSolit: blocking3.6.1+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
result of colchange.cgi on bmo while logged in (7.25 KB, text/plain)
2008-04-15 09:30 PDT, Thomas K. (:tom)
no flags Details
v1 (784 bytes, patch)
2009-02-01 16:26 PST, Max Kanat-Alexander
no flags Details | Diff | Splinter Review
v2 (973 bytes, patch)
2010-05-11 01:53 PDT, Max Kanat-Alexander
justdave: review+
Details | Diff | Splinter Review

Description Axton Grams 2007-03-30 14:33:35 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11
Build Identifier: Bugzilla 3.0rc1; Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11

As a user that is not logged in, when viewing a list of bugs on buglist.cgi, if user opts to change columns (colchange.cgi), then selects "Reset to Bugzilla Default", the page is returned as plain text (html code).  It looks like the content/encoding is not being set properly in the response, but I have not looked this far.  Here is a snippet of the head of the returned text:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
                      "http://www.w3.org/TR/html4/loose.dtd">
<html>
  <head>
    <title>Change columns</title>
<link rel="Top" href="http://arswiki.org/bugs/">
    <script type="text/javascript">


The url that the user is redirected to as a non-logged in user is:
http://arswiki.org/bugs/colchange.cgi?rememberedquery=bug_status%3DUNCONFIRMED%3Bbug_status%3DNEW%3Bbug_status%3DASSIGNED%3Bbug_status%3DREOPENED%3Bcontent%3D%3Bfield-1-0-0%3Dbug_status%3Bfield-1-1-0%3Dproduct%3Bfield-1-2-0%3Dcontent%3Bproduct%3D%3Bquery_format%3Dspecific%3Bremaction%3D%3Btype-1-0-0%3Danyexact%3Btype-1-1-0%3Danyexact%3Btype-1-2-0%3Dmatches%3Bvalue-1-0-0%3DUNCONFIRMED%252CNEW%252CASSIGNED%252CREOPENED%3Bvalue-1-1-0%3D%3Bvalue-1-2-0%3D%3Bquery_based_on%3D&resetit=1


This does not happen if the user is logged in to the bugzilla app.  If the user is logged in to the Bugzilla app, this is the url that the logged-in user is redirected to:

http://arswiki.org/bugs/buglist.cgi?Bugzilla_remember=on;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;content=;field-1-0-0=bug_status;field-1-1-0=product;field-1-2-0=content;product=;query_format=specific;remaction=;type-1-0-0=anyexact;type-1-1-0=anyexact;type-1-2-0=matches;value-1-0-0=UNCONFIRMED%2CNEW%2CASSIGNED%2CREOPENED;value-1-1-0=;value-1-2-0=;query_based_on=;GoAheadAndLogIn=1;GoAheadAndLogIn=Log%20in

Reproducible: Always

Steps to Reproduce:
1. Open http://arswiki.org/bugs
2. Click the Search link at the top of the page
3. Click the Search form button
4. Scroll to the bottom, click Change Columns
5. At the bottom of the Change Column page, click the 'Reset to Bugzilla default' form button
Actual Results:  
html code is returned as plain text

Expected Results:  
user should be redirected to search results

Server Info:

[root@arswiki ~]# uname -a
Linux arswiki.org 2.6.9-023stab041.3-enterprise #1 SMP Wed Feb 14 13:36:44 MSK 2007 i686 i686 i386 GNU/Linux

[root@arswiki ~]# httpd -v
Server version: Apache/2.2.4 (Unix)
Server built:   Jan 13 2007 22:04:31

[root@arswiki ~]# httpd -t -D DUMP_MODULES
Loaded Modules:
 core_module (static)
 authn_file_module (static)
 authn_anon_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 auth_digest_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 unique_id_module (static)
 setenvif_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 dav_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 cgi_module (static)
 dav_fs_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 dav_svn_module (shared)
 authz_svn_module (shared)
 python_module (shared)
 php5_module (shared)
 perl_module (shared)
Syntax OK

Bugzilla uses the mod_perl instead of the perl cgi.
Comment 1 Frédéric Buclin 2007-03-30 14:38:43 PDT
This is due to your local customization. I cannot reproduce on an unpatched 3.0 RC1 installation.
Comment 2 Axton Grams 2007-03-30 14:58:18 PDT
The only local customizations are through the Parameters section of the bugzilla front-end.  I am using mod_perl2 to serve the pages.

When logged in with Firefox 1.5.0.11, the content type is text/html
When logged in/not logged in with IE 7.0.5730, the content type is text/html
When not logged in with Firefox 1.5.0.11, the content type is text/plain

Maybe there is an issue in Firefox 1.5.0.11?

Axton Grams
Comment 3 Axton Grams 2007-03-30 15:02:13 PDT
I just upgraded to Firefox 2.0.0.3.  The results with Firefox 2.0.0.3 are consistent with the results from Firefox 1.5.0.11; both of which return the results as plain text using the steps provided.

Can you retest this with Firefox?
Comment 4 Frédéric Buclin 2007-03-30 15:10:49 PDT
I'm using Firefox 2.0.0.3 and I tested:
1) your own installation at http://arswiki.org/bugs where I can reproduce the bug;
2) http://landfill.bugzilla.org/mod_perl/ which is also running mod_perl, where I cannot reproduce the bug;
3) my local 3.0 RC1 installation, where I also cannot reproduce the bug;
4) our QA installation at http://landfill.bugzilla.org/qa30pg/ where I also cannot reproduce the bug.

You added "Vendor Bug ID" to your default column list so you did more than only editing parameters. Retest yourself on the installations given in 2) and 4).
Comment 5 Axton Grams 2007-03-30 15:29:22 PDT
You are correct, but this is one of the reasons I am using 3.0rc1; the ability to add custom fields.  This is managed through editfields.cgi by using the 'custom fields' link available in the bottom banner when logged in as an admin.  I did not modify any of the pl/cgi files directly, I just exercised a new feature.

The new feature is covered in the 3.0rc1 release notes:
http://www.bugzilla.org/releases/3.0/new-features.html#v30_feat_cf

Maybe there is a conflict between the new 'Custom Fields' feature and the existing functionality, 'Change Columns'?

I do not see the problem on the landfill.bugzilla.org site.
Comment 6 Axton Grams 2007-03-30 15:38:13 PDT
To elaborate on the custom columns I've added:

Edit custom field...  	Description  	Sortkey  	Type  	Editable on Bug Creation  	In Bugmail on Bug Creation  	Is Obsolete
cf_database 	Database 	351 	Drop Down 	1 	0 	1
cf_db 	Database/Version 	351 	Free Text 	1 	1 	0
cf_databaseos 	Database OS 	451 	Free Text 	1 	1 	0
cf_clientos 	Client OS 	551 	Free Text 	1 	1 	0
cf_VendorBugID 	Vendor Bug ID 	651 	Free Text 	1 	1 	0

The obsoleted column may or may not play into this.
Comment 7 Frédéric Buclin 2007-03-31 05:18:19 PDT
There is something wrong with your installation. When you click the "Change Columns" button in colchange.cgi, you should be redirected to buglist.cgi, which doesn't occur. After clicking the button, I manually edited the URL and replaced colchange.cgi by buglist.cgi and I then got the expected page.

    $vars->{'redirect_url'} = "buglist.cgi?".$cgi->param('rememberedquery');
    print $cgi->redirect($vars->{'redirect_url'});

That's the part of the code in colchange.cgi which is ignored. Could it be that you configured your server to ignore such redirections? On the other hand, your server correctly redirects http://arswiki.org/bugs/long_list.cgi?id=1 to http://arswiki.org/bugs/show_bug.cgi?format=multiple&id=1
Comment 8 Frédéric Buclin 2007-03-31 05:23:19 PDT
Also, your installation generates unknown column_foo fields, probably related to cookies.
Comment 9 Axton Grams 2007-03-31 10:21:07 PDT
You are correct; I had modified the Bugzilla/Constants.pm to include an additional default column. I undid this change and verified there were no other changes to any of the Bugzilla files by downloading a fresh copy, unpacking it, then performing a diff -ur against the two directories (bugs is the dir in use, bug_nomod is the freshly unpacked dir):

[root@arswiki htdocs]# diff -ur ./bugs_nomod ./bugs
Only in ./bugs: .cvsignore
Only in ./bugs: .htaccess
Only in ./bugs/Bugzilla: .htaccess
Only in ./bugs: data
Only in ./bugs: extensions
Only in ./bugs: graphs
Only in ./bugs: localconfig
Only in ./bugs: old-params.txt
Only in ./bugs/skins: contrib
Only in ./bugs/skins: custom
Only in ./bugs/template: .htaccess

I do not see anything in the .htaccess of either the root of the server of the bugs directory that would interfere with redirects:

[root@arswiki htdocs]# cat .htaccess
Options FollowSymlinks
Options -Indexes
RewriteEngine on
IndexIgnore *
ErrorDocument 404 /errors/notfound.html
RewriteCond %{HTTP_HOST} ^www\.arswiki\.org$ [NC]
RewriteRule ^(.*)$ http://arswiki.org/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^www.inspirationaltechnologies\.com$ [NC]
RewriteRule ^(.*)$ http://arswiki.org/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^inspirationaltechnologies\.com$ [NC]
RewriteRule ^(.*)$ http://arswiki.org/$1 [R=301,L]
Redirect /index.html http://arswiki.org/wiki/Main_Page

[root@arswiki htdocs]# cat bugs/.htaccess
# Don't allow people to retrieve non-cgi executable files or our private data
<FilesMatch ^(.*\.pm|.*\.pl|.*localconfig.*)$>
  deny from all
</FilesMatch>

In httpd.conf, this is how I use mod_perl for bugzilla:
PerlSwitches -I/u02/htdocs/bugs -w -T
PerlConfigRequire /u02/htdocs/bugs/mod_perl.pl


You stated that I should be redirected to buglist.cgi.
- In IE (if not logged in), I am sent to colchange.cgi with the following page contents (in text/html):
Resubmitting your search with new columns... Click here if the page does not automatically refresh. 
OK
The document has moved here.
- In Firefox (if not logged in), I get the same, just in text/plain instead of text/html
- In Firefox (if logged in), I am redirected to buglist.cgi

I will keep looking to see if I can find why this is happening.  If you have any add'l pointers, please share them with me.
Comment 10 Frédéric Buclin 2007-06-02 07:29:13 PDT
Max, Dave, the reporter says he is using mod_perl. Any idea what the problem could be?
Comment 11 Max Kanat-Alexander 2007-06-02 22:08:50 PDT
Can this be reproduced on http://landfill.bugzilla.org/mod_perl/ ?
Comment 12 Frédéric Buclin 2007-11-12 06:33:28 PST
I just tried again on http://arswiki.org/bugs/ and I cannot reproduce the problem anymore. -> WFM
Comment 13 Frédéric Buclin 2008-01-25 07:28:21 PST
*** Bug 413948 has been marked as a duplicate of this bug. ***
Comment 14 Frédéric Buclin 2008-01-25 09:14:45 PST
For the record, this bug only happens with mod_perl enabled + Firefox 2 or 3 (IE 6 and 7 are not affected, maybe because they do sniff the page content and display them as HTML instead of plain text) + requires to be b.m.o or stage.m.o or stage-tip.m.o. So it seems to be a b.m.o specific bug to me, not a Bugzilla bug (nor a mod_perl one). Maybe we should reopen and move this bug to the mozilla.org product?
Comment 15 Max Kanat-Alexander 2008-01-25 14:05:13 PST
Well, I've seen it happen on my clients' systems as well, so there's something about this, somewhere. Maybe it has to do with Apache version?
Comment 16 Frédéric Buclin 2008-01-26 02:18:28 PST
Or it depends on the version of mod_perl. I cannot reproduce on landfill.m.o/mod_perl/ which has mod_perl/1.999.22 (from testagent.cgi) but I can reproduce on b.m.o which has mod_perl/2.0.3. Do they both have the same version of Apache?
Comment 17 Jesse Clark 2008-02-21 16:47:21 PST
I am experiencing this on bugzilla.mozilla.org using both Mac Firefox 2.0.0.12 and Safari 3.0.4, both logged in and logged out of bugzilla.

https://bugzilla.mozilla.org/colchange.cgi?rememberedquery=&resetit=1
Bugzilla 3.0.3+
Apache/2.2.3 (Red Hat) Server at bugzilla.mozilla.org Port 80
Comment 18 Frédéric Buclin 2008-02-21 16:53:16 PST
OK, let's confirm it for now to have it in our radar. We need investigation, though.
Comment 19 Thomas K. (:tom) 2008-04-15 09:30:23 PDT
Created attachment 315791 [details]
result of colchange.cgi on bmo while logged in

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041304 Minefield/3.0pre

on bmo, a moment ago.  sp3000 directed me to this bug.
Comment 20 Miki 2008-06-12 07:10:07 PDT
I get this same problem with the following differences:

- User is logged in, cookies in place

- Happens only on saved searches


Running 3.1.4
Comment 21 Max Kanat-Alexander 2008-07-09 12:25:11 PDT
*** Bug 444140 has been marked as a duplicate of this bug. ***
Comment 22 Brian Krausz 2008-07-09 13:38:06 PDT
Happens to me when logged in, as well as several others.  Suggest changing summary of bug.
Comment 23 Dimitri 2008-09-30 02:18:36 PDT
1 : do a query ( on the fly ) and execute it 
2 : click change columns
3 : click change columns button
4 : it display raw HTML uninterpreted

For me reproducible always on https://bugzilla.mozilla.org 3.2RC ( I'm logged firefox 3.0 french ) but never on my personal bugzilla 3.0.1 ( windows same firefox )

maybe Bug 437555 is the same issue ?
Comment 24 Frédéric Buclin 2008-11-20 16:23:00 PST
*** Bug 466064 has been marked as a duplicate of this bug. ***
Comment 25 Frédéric Buclin 2008-11-20 16:27:29 PST
*** Bug 437555 has been marked as a duplicate of this bug. ***
Comment 26 Frédéric Buclin 2008-11-20 22:12:57 PST
*** Bug 466064 has been marked as a duplicate of this bug. ***
Comment 27 Frédéric Buclin 2008-11-20 22:14:26 PST
Brian and David can reproduce the problem while being logged in. Updating the bug summary accordingly.
Comment 28 Vitaly Fedrushkov 2008-11-21 01:18:13 PST
I get the same with "Change columns", not only "Reset to Default".  Reloading page does not help, as it did(?) six months ago.
Comment 29 David E. Ross 2008-11-21 10:43:43 PST
Updating Summary to indicate that the problem appears on either the "Change Columns" button or the "Reset to Bugzilla Default" button.  I get this problem, but I never use the "Reset to Bugzilla Default" button.
Comment 30 David E. Ross 2009-01-21 11:00:19 PST
This used to work okay.  Thus, this is a regression bug.  

I usually view my saved queries with the following columns: bug number, last date changed, severity, status, resolution, votes, and short summary.  If I want to find a in a query with many bug reports (e.g., one of my queries currently returns 177 bug reports), I can't get product or component columns.  

A significant capability is broken.  Changing priority from Normal to Major (per the definition of Major).  

If this is a server problem (as suggested by several comments), then please fix the bugzilla.mozilla.org server.
Comment 31 Frédéric Buclin 2009-01-21 11:41:23 PST
I'm not even sure we can do anything about it. It seems to be the set-cookie + mod_perl combination which triggers the problem on some installations.
Comment 32 Max Kanat-Alexander 2009-02-01 14:44:56 PST
*** Bug 476388 has been marked as a duplicate of this bug. ***
Comment 33 Max Kanat-Alexander 2009-02-01 14:56:25 PST
Okay, on landfill, I can only reproduce this when I'm logged out.
Comment 34 Max Kanat-Alexander 2009-02-01 16:26:32 PST
Created attachment 360027 [details] [diff] [review]
v1

This makes CGI::redirect behave the same on mod_cgi and mod_perl. 

For some reason, when CGI.pm uses send_cgi_header to send a redirect header from colchange.cgi, it sends a 200 OK instead of a 302. Perhaps because colchange.cgi also has output? It might be a better fix to just remove the output, but I haven't tested that. 

I haven't tested this on all our other redirects, and I have no idea if this has any other consequences, yet. I just wanted to get the patch up.
Comment 35 Bradley Baetz (:bbaetz) 2009-02-01 19:59:46 PST
Theres something else odd, because I get the message.html.tmpl text and also the generic apache redirect (with <title>200 OK</title>) text at the bottom.
Comment 36 Max Kanat-Alexander 2009-02-01 20:17:59 PST
(In reply to comment #35)
> Theres something else odd, because I get the message.html.tmpl text and also
> the generic apache redirect (with <title>200 OK</title>) text at the bottom.

  With the patch?
Comment 37 Bradley Baetz (:bbaetz) 2009-02-01 20:25:15 PST
(In reply to comment #36)
> (In reply to comment #35)
> > Theres something else odd, because I get the message.html.tmpl text and also
> > the generic apache redirect (with <title>200 OK</title>) text at the bottom.
> 
>   With the patch?

No, without. I don't have MP set up locally yet to try and test.
Comment 38 Max Kanat-Alexander 2009-02-03 14:38:44 PST
gozer, if you have any insight on why patch v1 seems to fix this problem, I'd be really happy to know. But if you don't have the time or don't want to, that's totally fine. :-)
Comment 39 Philippe M. Chiasson (:gozer) 2009-02-04 08:14:29 PST
(In reply to comment #34)
> Created an attachment (id=360027) [details]
> v1
> 
> This makes CGI::redirect behave the same on mod_cgi and mod_perl. 
> 
> For some reason, when CGI.pm uses send_cgi_header to send a redirect header
> from colchange.cgi, it sends a 200 OK instead of a 302. Perhaps because
> colchange.cgi also has output? It might be a better fix to just remove the
> output, but I haven't tested that. 

That's going to happen if something (CGI.pm) calls the mod_perl headers api first, then something just prints "Content-type: bla" type headers, it's already too late.

Somethign really helpfull there would be to collect the exact response the webserver sent, it will most likely look like

200 OK
Content-type: text/plain
Set-Cookie: blabla

302 Redirect
Location: /foo/bar

<bunch of html>

Sounds to me like a possible CGI.pm bug, and also, it might be ParseHeaders related

see <http://perl.apache.org/docs/2.0/user/config/config.html#C_ParseHeaders_>
Comment 40 Frédéric Buclin 2009-02-09 11:02:41 PST
Comment on attachment 360027 [details] [diff] [review]
v1

I *absolutely* don't feel confident to review this patch. This looks like a big hack to me rather than a real fix of the root cause. Retargetting your request for review to someone else.
Comment 41 Ian Pottinger 2009-02-24 20:24:46 PST
This bug says "for logged-out users" but I'm logged-in and I'm seeing this.  If there is any helpful info a lay person like me can provide, please let me know and I will do my best.
Comment 42 Frédéric Buclin 2009-02-26 14:14:02 PST
What's the status of this bug? IMO not a hard blocker as the problem exists since Bugzilla 3.0. justdave, do you plan to review this patch? If not, retarget the request for review to someone else (gozer, or any other mod_perl/CGI expert).
Comment 43 David E. Ross 2009-02-26 16:28:20 PST
I don't know if this information might help resolve this bug, but I do not see this problem at bugzilla.mozdev.org, only at bugzilla.mozilla.org.
Comment 44 Frédéric Buclin 2009-02-26 16:30:22 PST
(In reply to comment #43)
> I don't know if this information might help resolve this bug, but I do not see
> this problem at bugzilla.mozdev.org

No, this doesn't help. Mozdev doesn't use mod_perl.
Comment 45 Greg Hendricks 2009-03-12 13:21:29 PDT
Comment on attachment 360027 [details] [diff] [review]
v1

I too lack experience in the wily ways of HTTP, and mod_perl especially to say whether this is a good thing or to offer an explanation as to why it works. I would be willing to approve it on the grounds that you have tested it in both environments, but I have to agree with LpSolit in that it seems rather hackish.  It also smacks of a bug further up the chain rather than in Bugzilla. It might be recommendable to raise this issue on the mod_perl boards or in the firefox dev channel and see if someone can offer an explanation. If they can do so to my satisfaction I will be willing to r+ it.
Comment 46 Max Kanat-Alexander 2009-03-12 17:23:21 PDT
Comment on attachment 360027 [details] [diff] [review]
v1

What I'd like primarily is some testing to make sure that I'm not breaking anything.
Comment 47 Byron Jones ‹:glob› 2009-03-12 17:28:18 PDT
sorry max, i don't know enough about mod_perl to review this one :(
Comment 48 Philippe M. Chiasson (:gozer) 2009-03-12 18:57:15 PDT
(In reply to comment #38)
> gozer, if you have any insight on why patch v1 seems to fix this problem, I'd
> be really happy to know. But if you don't have the time or don't want to,
> that's totally fine. :-)

Sounds like to me like something ends up calling CGI->header twice for the same request, for instance, something like

print $q->header('text/html');
print $q->redirect(...);

This would end up calling:

$r->send_cgi_header() twice, causing the problem you are seeing.

By setting $CGI::MOD_PERL = 0; you just avoid the 2nd call to it.

Sounds to me like Bugzilla is using the CGI APIs incorrectly, and I'd figure out why. In short, if you are going to redirect somebody somewhere, you don't call $q->header() and go for $q->redirect() only.
Comment 49 Frédéric Buclin 2009-04-14 12:54:02 PDT
*** Bug 488324 has been marked as a duplicate of this bug. ***
Comment 50 Max Kanat-Alexander 2009-04-30 13:05:03 PDT
(In reply to comment #48)
> Sounds like to me like something ends up calling CGI->header twice for the same
> request, for instance, something like

  No, nothing is calling CGI->header twice. The block we change in CGI.pm's header() code by my patch is this:

    if (($MOD_PERL >= 1) && !$nph) {
        $self->r->send_cgi_header($header);
        return '';
    }
    return $header;

  So by making "$MOD_PERL = 0" we "print" the header instead of directly calling send_cgi_header--that is the only difference.

  The difference between this part of the Bugzilla code and other parts is that we send cookies along with this redirect, whereas we don't send cookies along with other redirects.
Comment 51 Max Kanat-Alexander 2009-04-30 13:37:24 PDT
I once again cannot reproduce this at all, on HEAD. Perhaps recent changes to colchange.cgi magically fixed something.
Comment 52 David E. Ross 2009-05-02 10:29:55 PDT
I just now tried it, and the bug is still there.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090403 SeaMonkey/1.1.16
Comment 53 Max Kanat-Alexander 2009-05-02 14:05:09 PDT
(In reply to comment #52)
> I just now tried it, and the bug is still there.

  On this installation? http://landfill.bugzilla.org/bugzilla-tip/
Comment 54 David E. Ross 2009-05-06 10:56:22 PDT
No.  I saw this in <https://bugzilla.mozilla.org/buglist.cgi?xxx>, where xxx is my own saved query, where I got it again about 15 minutes ago.
Comment 55 Frédéric Buclin 2009-05-06 10:59:24 PDT
(In reply to comment #54)
> No.  I saw this in <https://bugzilla.mozilla.org/buglist.cgi?xxx>, where xxx is
> my own saved query, where I got it again about 15 minutes ago.

Which is not surprising as bmo runs Bugzilla 3.2, not even 3.4, and so is far from HEAD (3.5).
Comment 56 Dan Wierenga 2009-05-07 00:09:40 PDT
It happens still on my 3.5 installation.

https://dwierenga.homelinux.net/bugzilla/colchange.cgi?rememberedquery=GoAheadAndLogIn%3DLog%2520in%3Bbug_status%3DUNCONFIRMED%3Bbug_status%3DNEW%3Bbug_status%3DASSIGNED%3Bbug_status%3DREOPENED%3Bcolumnlist%3Dassigned_to%3Bquery_format%3Dspecific%3Bremaction%3D%3Bquery_based_on%3D&selected_columns=assigned_to&splitheader=0

If I comment out lines 166 and 167 of the head revision of colchange.cgi, which are:
$template->process("global/message.html.tmpl", $vars)
  || ThrowTemplateError($template->error());

then I don't get the error.  I'm uncertain what these lines are intending to do since, as far as I can tell, the previous chunk of logic is basically (in pseudo-code):
if (not Apache)
  meta-refresh redirect
else
  http-header redirect

which leaves me wondering why we'd want to process an HTML template following a logic tree that always results in a redirect.

I've left the lines noted above uncommented in case someone wants to follow the link I gave.
Comment 57 James May [:fowl] 2009-08-18 03:32:32 PDT
(In reply to comment #55)
>Which is not surprising as bmo runs Bugzilla 3.2, not even 3.4, and so is far
from HEAD (3.5).

So we should stop confirming that this still happens, because nothing has changed?

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) ID:20090729225027 Logged in
Comment 58 Max Kanat-Alexander 2009-08-20 15:11:02 PDT
Somebody has started agressively fixing bugs in CGI.pm, so I've reported this problem there:

  https://rt.cpan.org/Ticket/Display.html?id=48895
Comment 59 David E. Ross 2009-08-22 11:49:19 PDT
When attempting to view the rt.cpan.org bug report cited in comment #58, I got a "Website Certified by an Unknown Authority" error popup.  The site certificate was issued by Best Practical CA, which I don't think is in the Mozilla certificate database.  Alternatively, Best Practical CA is a third-party intermediate whose intermediate certificate must be installed on the rt.cpan.org server.  

Someone who is more familiar with rt.cpan.org should please contact them about this.
Comment 60 David E. Ross 2009-11-21 10:26:49 PST
With the recent upgrade to Bugzilla 3.4.4+ for buzilla.mozilla.org, this problem seems resolved.  

Note, however, that (contrary to the summary) this was also a problem with logged-in users, in which context I saw this bug.  I have not tried a test as a logged-out user.
Comment 61 Matt Evans 2010-01-19 14:24:04 PST
I see this happening when accessing bugzilla.mozilla.org. I am logged in. Occurs with both safari and firefox.
Comment 62 Max Kanat-Alexander 2010-02-25 15:42:34 PST
Okay, I have an idea of how to fix this, but I want to fix bug 24896 first, because I think the fix and that patch will conflict, and that bug already has a big patch on it.
Comment 63 Frédéric Buclin 2010-03-18 04:49:47 PDT
*** Bug 553060 has been marked as a duplicate of this bug. ***
Comment 64 krhohio 2010-04-19 07:45:55 PDT
FYI,
I just had this problem on https://bugzilla.mozilla.org
Help shows: "The Bugzilla Guide - 3.4.6 Release"
(Is this the best way to tell what version of Bugzilla you are using?)

How about changing the title of this bug to something like the duplicate:
bug 444140 "Change Columns" page dumps raw HTML to screen.

i.e. more general description and not specific to "for logged-out users".
Comment 65 Frédéric Buclin 2010-04-23 05:32:34 PDT
*** Bug 561067 has been marked as a duplicate of this bug. ***
Comment 66 Max Kanat-Alexander 2010-05-11 01:53:20 PDT
Created attachment 444617 [details] [diff] [review]
v2

Okay, here's a very simple solution. The problem is caused by trying to send cookies along with a redirect at the same time. We actually already have a workaround for problems with cookie+redirect in colchange.cgi, so let's just use that same for mod_perl.
Comment 67 Dave Miller [:justdave] (justdave@bugzilla.org) 2010-05-11 21:20:57 PDT
Comment on attachment 444617 [details] [diff] [review]
v2

I can't reproduce this anymore (and apparently mkanat can't either), but this looks like a good fix anyway, and since it always seems to be intermittent when anyone can reproduce it anyhow, why not? :)  This still works, doesn't break anything, and hopefully fixes the intermittent problem that people can only reproduce sometimes.
Comment 68 Max Kanat-Alexander 2010-05-11 21:46:40 PDT
See also bug 565240.
Comment 69 Rob 2010-05-14 17:17:33 PDT
Not Fixed, yet.


(In reply to comment #65)
> *** Bug 561067 has been marked as a duplicate of this bug. ***

(In reply to comment #65)
> I can't reproduce this anymore (and apparently mkanat can't either), but this
> looks like a good fix anyway, and since it always seems to be intermittent ...


I reported a Bug (561067) and it was marked as a Dupe to here:

Our 'List Results' "Change Columns" redirect results in un-rendered page
https://bugzilla.mozilla.org/show_bug.cgi?id=561067


That Bug is not intermittent and is still reproducible. Since it runs off of Mozilla's Server and uses Namoroka there is still something for us to fix.

Thanks,
Rob
Comment 70 Max Kanat-Alexander 2010-05-15 11:52:14 PDT
Hey Rob. Could you tell me the exact steps you use to reproduce the problem, and anything peculiar about your environment?
Comment 71 Max Kanat-Alexander 2010-05-19 09:27:03 PDT
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified colchange.cgi
Committed revision 7180.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.6/
modified colchange.cgi
Committed revision 7100.
Comment 72 Rob 2010-06-19 18:36:38 PDT
(In reply to comment #70)
> Hey Rob. Could you tell me the exact steps you use to reproduce the problem,
> and anything peculiar about your environment?

I re-read https://bugzilla.mozilla.org/show_bug.cgi?id=561067 and I believe it outlines the steps correctly. My environment is not particularly peculiar and this feature works on other "Bugzillas" (elsewhere).

It is NOT fixed (as of today).

Rob
Comment 73 Max Kanat-Alexander 2010-06-20 06:13:02 PDT
(In reply to comment #69)
> That Bug is not intermittent and is still reproducible. Since it runs off of
> Mozilla's Server and uses Namoroka there is still something for us to fix.

  Hey Rob. bugzilla.mozilla.org has not upgraded to a version of Bugzilla where this problem is fixed, yet. The Bugzilla Project (this product) and bugzilla.mozilla.org (this website) are separate things.
Comment 74 David E. Ross 2010-06-23 12:34:17 PDT
Since Bugzilla itself has been fixed (per comment #73) but bugzilla.mozilla.org has not yet installed the fix, changing the product and component.
Comment 75 Reed Loden [:reed] (use needinfo?) 2010-06-23 12:41:48 PDT
(In reply to comment #74)
> Since Bugzilla itself has been fixed (per comment #73) but bugzilla.mozilla.org
> has not yet installed the fix, changing the product and component.

Just because bugzilla.mozilla.org doesn't have a fix for this issue right now doesn't mean you should hijack this bug in order to move it somewhere else. Once there's a release available that includes this fix, I'm sure bugzilla.mozilla.org will update to it.
Comment 76 Rob 2010-07-14 10:44:31 PDT
Thanks one and all, was there an outstanding question for me to answer?

Rob
Comment 77 Rob 2010-07-21 18:54:26 PDT
I had a reason to use "Change Columns" today and remembered this BR.

Today, it works correctly.

Rob

Note You need to log in before you can comment on or make changes to this bug.