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)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: axton.grams, Assigned: mkanat)
References
()
Details
Attachments
(2 files, 1 obsolete file)
7.25 KB,
text/plain
|
Details | |
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.
Comment 1•17 years ago
|
||
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
Reporter | ||
Comment 2•17 years ago
|
||
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
Reporter | ||
Comment 3•17 years ago
|
||
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 → ---
Comment 4•17 years ago
|
||
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).
Reporter | ||
Comment 5•17 years ago
|
||
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.
Reporter | ||
Comment 6•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Also, your installation generates unknown column_foo fields, probably related to cookies.
Reporter | ||
Comment 9•17 years ago
|
||
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•17 years ago
|
||
Max, Dave, the reporter says he is using mod_perl. Any idea what the problem could be?
Version: unspecified → 3.0
Assignee | ||
Comment 11•17 years ago
|
||
Can this be reproduced on http://landfill.bugzilla.org/mod_perl/ ?
Comment 12•17 years ago
|
||
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
Comment 14•16 years ago
|
||
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?
Assignee | ||
Comment 15•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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 → ---
Comment 18•16 years ago
|
||
OK, let's confirm it for now to have it in our radar. We need investigation, though.
Updated•16 years ago
|
Keywords: helpwanted
Comment 19•16 years ago
|
||
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•16 years ago
|
||
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 22•16 years ago
|
||
Happens to me when logged in, as well as several others. Suggest changing summary of bug.
Comment 23•16 years ago
|
||
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 27•16 years ago
|
||
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
Comment 28•16 years ago
|
||
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•16 years 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
Comment 30•15 years ago
|
||
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
Comment 31•15 years ago
|
||
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
Assignee | ||
Updated•15 years ago
|
Priority: -- → P1
Assignee | ||
Comment 33•15 years ago
|
||
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
Assignee | ||
Comment 34•15 years ago
|
||
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)
Comment 35•15 years ago
|
||
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.
Assignee | ||
Comment 36•15 years ago
|
||
(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•15 years ago
|
||
(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.
Assignee | ||
Comment 38•15 years ago
|
||
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•15 years ago
|
||
(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_>
Updated•15 years ago
|
Attachment #360027 -
Flags: review?(LpSolit) → review?(justdave)
Comment 40•15 years ago
|
||
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.
Updated•15 years ago
|
Flags: blocking3.4?
Assignee | ||
Updated•15 years ago
|
Flags: blocking3.4? → blocking3.4+
Comment 41•15 years ago
|
||
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•15 years ago
|
||
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
Comment 43•15 years ago
|
||
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•15 years ago
|
||
(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.
Assignee | ||
Updated•15 years ago
|
Attachment #360027 -
Flags: review?(justdave) → review?(ghendricks)
Updated•15 years ago
|
Attachment #360027 -
Flags: review?(ghendricks)
Comment 45•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #360027 -
Flags: review?
Assignee | ||
Comment 46•15 years ago
|
||
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)
Comment 47•15 years ago
|
||
sorry max, i don't know enough about mod_perl to review this one :(
Comment 48•15 years ago
|
||
(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.
Assignee | ||
Comment 50•15 years ago
|
||
(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.
Assignee | ||
Comment 51•15 years ago
|
||
I once again cannot reproduce this at all, on HEAD. Perhaps recent changes to colchange.cgi magically fixed something.
Flags: blocking3.4+ → blocking3.4-
Assignee | ||
Updated•15 years ago
|
Attachment #360027 -
Flags: review?(bugzilla)
Comment 52•15 years ago
|
||
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
Assignee | ||
Comment 53•15 years ago
|
||
(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•15 years ago
|
||
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•15 years 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).
Comment 56•15 years ago
|
||
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•15 years ago
|
||
(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
Assignee | ||
Comment 58•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
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•14 years ago
|
||
I see this happening when accessing bugzilla.mozilla.org. I am logged in. Occurs with both safari and firefox.
Assignee | ||
Comment 62•14 years ago
|
||
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
Comment 64•14 years ago
|
||
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".
Assignee | ||
Updated•14 years ago
|
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
Assignee | ||
Comment 66•14 years ago
|
||
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)
Assignee | ||
Updated•14 years ago
|
Flags: blocking3.6.1+
Target Milestone: --- → Bugzilla 3.6
Updated•14 years ago
|
Attachment #444617 -
Flags: review?(LpSolit) → review+
Comment 67•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Flags: approval3.6+
Flags: approval+
Assignee | ||
Comment 68•14 years ago
|
||
See also bug 565240.
Comment 69•14 years ago
|
||
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
Assignee | ||
Comment 70•14 years ago
|
||
Hey Rob. Could you tell me the exact steps you use to reproduce the problem, and anything peculiar about your environment?
Assignee | ||
Updated•14 years ago
|
Keywords: helpwanted
Assignee | ||
Comment 71•14 years ago
|
||
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
Comment 72•14 years ago
|
||
(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
Assignee | ||
Comment 73•14 years ago
|
||
(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•14 years ago
|
||
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
Comment 75•14 years ago
|
||
(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
Updated•14 years ago
|
Flags: blocking3.6.1?
Flags: approval?
Flags: approval3.6?
Updated•14 years ago
|
Flags: blocking3.6.1?
Flags: blocking3.6.1+
Flags: approval?
Flags: approval3.6?
Flags: approval3.6+
Flags: approval+
Comment 76•14 years ago
|
||
Thanks one and all, was there an outstanding question for me to answer? Rob
Comment 77•14 years ago
|
||
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.
Description
•