Closed Bug 376044 Opened 17 years ago Closed 14 years ago

When using mod_perl "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi sometimes return HTML as text

Categories

(Bugzilla :: Query/Bug List, defect, P1)

Product:
Bugzilla
Component:
Query/Bug List
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 3.6

People

(Reporter: axton.grams, Assigned: mkanat)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

result of colchange.cgi on bmo while logged in
7.25 KB, text/plain
Details
v2
973 bytes, patch
justdave
: review+
Details | Diff | Splinter Review 
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.
This is due to your local customization. I cannot reproduce on an unpatched 3.0 RC1 installation.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
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
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?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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).
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.
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.
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

Also, your installation generates unknown column_foo fields, probably related to cookies.
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.
Max, Dave, the reporter says he is using mod_perl. Any idea what the problem could be?
Version: unspecified → 3.0
Can this be reproduced on http://landfill.bugzilla.org/mod_perl/ ?
I just tried again on http://arswiki.org/bugs/ and I cannot reproduce the problem anymore. -> WFM
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → WORKSFORME
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?
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?
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?
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
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
OK, let's confirm it for now to have it in our radar. We need investigation, though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
OS: Linux → All
Hardware: PC → All
Keywords: helpwanted
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.
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
Happens to me when logged in, as well as several others.  Suggest changing summary of bug.
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 ?
Brian and David can reproduce the problem while being logged in. Updating the bug summary accordingly.
Summary: For non-logged in users, from buglist.cgi, change columns-> reset defaults, returns html as text → From buglist.cgi, change columns-> reset defaults returns html as text
I get the same with "Change columns", not only "Reset to Default".  Reloading page does not help, as it did(?) six months ago.
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.
Summary: From buglist.cgi, change columns-> reset defaults returns html as text → From buglist.cgi, "Change Columns" or "Reset to Bugzilla Default" returns HTML as text
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.
Severity: normal → major
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.
Summary: From buglist.cgi, "Change Columns" or "Reset to Bugzilla Default" returns HTML as text → When using mod_perl, "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi return HTML as text
Priority: -- → P1
Okay, on landfill, I can only reproduce this when I'm logged out.
Summary: When using mod_perl, "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi return HTML as text → When using mod_perl, for logged-out users, "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi return HTML as text
Attached patch v1 (obsolete) — — Splinter Review 
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.
Assignee: query-and-buglist → mkanat
Status: NEW → ASSIGNED
Attachment #360027 - Flags: review?(LpSolit)
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.
(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?
(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.
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. :-)
(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_>
Attachment #360027 - Flags: review?(LpSolit) → review?(justdave)
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.
Flags: blocking3.4?
Flags: blocking3.4? → blocking3.4+
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.
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).
Keywords: qawanted
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.
(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.
Attachment #360027 - Flags: review?(justdave) → review?(ghendricks)
Attachment #360027 - Flags: review?(ghendricks)
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.
Attachment #360027 - Flags: review?
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.
Attachment #360027 - Flags: review? → review?(bugzilla)
sorry max, i don't know enough about mod_perl to review this one :(
(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.
(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.
I once again cannot reproduce this at all, on HEAD. Perhaps recent changes to colchange.cgi magically fixed something.
Flags: blocking3.4+ → blocking3.4-
Attachment #360027 - Flags: review?(bugzilla)
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
(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/
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.
(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).
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.
(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
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
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.
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.
I see this happening when accessing bugzilla.mozilla.org. I am logged in. Occurs with both safari and firefox.
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.
Depends on: 24896
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".
Summary: When using mod_perl, for logged-out users, "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi return HTML as text → When using mod_perl "Change Columns" and "Reset to Bugzilla Default" buttons in colchange.cgi sometimes return HTML as text
Attached patch v2 — — Splinter Review 
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.
Attachment #360027 - Attachment is obsolete: true
Attachment #444617 - Flags: review?(LpSolit)
Flags: blocking3.6.1+
Target Milestone: --- → Bugzilla 3.6
Attachment #444617 - Flags: review?(LpSolit) → review+
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.
Flags: approval3.6+
Flags: approval+
See also bug 565240.
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
Hey Rob. Could you tell me the exact steps you use to reproduce the problem, and anything peculiar about your environment?
Keywords: helpwanted
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.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 14 years ago
Resolution: --- → FIXED
(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
(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.
Since Bugzilla itself has been fixed (per comment #73) but bugzilla.mozilla.org has not yet installed the fix, changing the product and component.
Assignee: mkanat → nobody
Component: Query/Bug List → other.mozilla.org
Flags: blocking3.6.1+
Flags: blocking3.4-
Flags: approval3.6+
Flags: approval+
Product: Bugzilla → Websites
QA Contact: default-qa → other-mozilla-org
Target Milestone: Bugzilla 3.6 → ---
Version: 3.0 → other
(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.
Assignee: nobody → mkanat
Component: other.mozilla.org → Query/Bug List
Product: Websites → Bugzilla
QA Contact: other-mozilla-org → default-qa
Target Milestone: --- → Bugzilla 3.6
Version: other → 3.0
Flags: blocking3.6.1?
Flags: approval?
Flags: approval3.6?
Flags: blocking3.6.1?
Flags: blocking3.6.1+
Flags: approval?
Flags: approval3.6?
Flags: approval3.6+
Flags: approval+
Thanks one and all, was there an outstanding question for me to answer?

Rob
I had a reason to use "Change Columns" today and remembered this BR.

Today, it works correctly.

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

Attachment

General

Creator:
Created:
Updated:
Size: