Open
Bug 389820
Opened 18 years ago
Updated 5 years ago
&debug=1 should work on buglist.cgi even if the query crashes
Categories
(Bugzilla :: Query/Bug List, enhancement, P3)
Tracking
()
NEW
People
(Reporter: timeless, Unassigned)
References
()
Details
Attachments
(1 file, 1 obsolete file)
8.29 KB,
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
I'm tired of not being able to debug broken queries.
https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=bugs%20with%20my%20patches2&sharer_id=127400&debug=1
Is a shared query, but I can't figure out what it queries.
steps:
1. construct and save a bad query (it's easier to find someone else willing to share, paul and I both have such queries)
2. use the tried and true method of adding &debug=1 to the query to find out what it's thinking
3. stare at a useless red box that doesn't explain what's really going wrong.
expected results:
*honor* debug=1
Attachment #274142 -
Flags: review?(wicked)
Updated•18 years ago
|
Status: NEW → ASSIGNED
OS: Mac OS X → All
Priority: -- → P3
Hardware: Macintosh → All
Summary: can't debug invalid field names → &debug=1 should work on buglist.cgi even if the query crashes
![]() |
||
Comment 1•18 years ago
|
||
joel, do you agree with changes made in Search.pm?
![]() |
||
Comment 2•18 years ago
|
||
Comment on attachment 274142 [details] [diff] [review]
let me find out
bitrotten
Attachment #274142 -
Flags: review?(wicked) → review-
Attachment #274142 -
Attachment is obsolete: true
Attachment #302997 -
Flags: review?
![]() |
||
Comment 4•18 years ago
|
||
Comment on attachment 302997 [details] [diff] [review]
bits shouldn't move
>-if ($cgi->param('debug')) {
>- $vars->{'debug'} = 1;
>- $vars->{'query'} = $query;
>- $vars->{'debugdata'} = $search->getDebugData();
>-}
>+$search->addDebugData($vars, $query);
I see no reason to add debug data unconditionally.
>Index: Bugzilla/Search.pm
>+sub addDebugData {
>+ my ($self, $vars, $query) = @_;
>+ $vars->{'debug'} = 1;
This looks wrong to me. If addDebugData() is called, then the caller already has debug=1 defined.
>+sub ThrowInvalidFieldName {
>+ my ($self, $f) = @_;
>+ my %vars = {field => $f};
>+ $self->addDebugData(\%vars);
>+ ThrowCodeError("invalid_field_name", %vars);
Must be $vars everywhere, not %vars.
Also, invalid_field_name is not the only reason why Search.pm may fail. This is only a very partial fix (assuming this patch really works).
Attachment #302997 -
Flags: review? → review-
gah. could you at least read what you've quoted?
i'm changing the convention so that debug=1 is set by the callee not the caller.
![]() |
||
Updated•12 years ago
|
Assignee: timeless → query-and-buglist
![]() |
||
Updated•12 years ago
|
Status: ASSIGNED → NEW
Updated•9 years ago
|
Keywords: good-first-bug,
outreachy
Whiteboard: [good first bug]
Comment 6•7 years ago
|
||
Removing good-first-bug
keyword because team does not have bandwidth to mentor at the moment.
Keywords: good-first-bug
Comment 7•7 years ago
|
||
Removing outreachy
because team does not have bandwidth to mentor this cycle.
Keywords: outreachy
Updated•5 years ago
|
Whiteboard: [good first bug]
You need to log in
before you can comment on or make changes to this bug.
Description
•