Closed Bug 18349 Opened 25 years ago Closed 23 years ago

query.cgi target_milestone value does not reload form SELECTED item

Categories

(Bugzilla :: Bugzilla-General, defect, P2)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Bugzilla 2.12

People

(Reporter: dbaron, Assigned: jacob)

References

(
URL
)

Details

(Keywords: dataloss)

Attachments

(1 file)

Add "target_milestone" to the list of fields to be restored
787 bytes, patch
Details | Diff | Splinter Review 
If a remembered query has the target milestone as blank "---" (not nothing
selected, but the last item selected), then when it is *loaded* (not run), it
shows up incorrectly.  The Target Milestone select box has, at the bottom, an
extra option, which is the Component of that query, selected.

TO REPRODUCE:
 * create a named query with
     + Target Milestone = "---"
     + Component = "Browser-General"
 * do "load the remembered query" on that query
 * the select for Target Milestone has an extra option at the bottom,
"Browser-General", and it's selected, so the query doesn't work unless you
change the TM!

(Using NN 4.61 Linux.)
The symptoms of this bug have changed.  Instead of producing the garbled output
described above, Bugzilla instead, halfway through the query page, prints the
warning:

"Possible bug database corruption has been detected. Please send mail to
terry@mozilla.org with details of what you were doing when this message
appeared. Thank you."
Status: NEW → ASSIGNED
Priority: P3 → P2
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
can someone cough up a query that shows this bug and paste it into the bug 
comments? thanks. (or even better, use the URL field)
Whiteboard: 2.14
On the query form, select status=NEW, component=XBL and target_milestone=---

The query you get should be equivalent to this one:
http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&component=XBL&target_milestone=---
result: 12 bugs found.

Now "Edit this query":
result: NEW is selected, XBL is selected, but no target milestone is selected.
The information about the value of the target milestone is lost.

Now, without changing anything, submit that query:
result: 24 bugs found.

Expected Result:
On any buglist, "Edit this query" followed by an immediate "submit" should give
you the same buglist as before (assuming the bug data hasn't changed).
Sorry, the link is not correctly recognized. Use the URL field instead.
URL: http://bugzilla.mozilla.org/buglist.c...
Whiteboard: 2.14 → 2.16
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16
*** Bug 63655 has been marked as a duplicate of this bug. ***
When I noticed this bug, it appeared to me it didn't restore _any_ milestones.
Hmm, and components too.  Have the parameters to query.cgi been changed?
Severity: normal → major
Whiteboard: 2.16
Components is bug #72379.
As noted by Matthew Tuck, it doesn't matter what the target_milestone equals
when a query.cgi URL is loaded, the chosen item in the relevant form
control is not SELECTED.

Adjusting Summary from "problems loading remembered query with --- for TM"
to "query.cgi target_milestone value does not reload form SELECTED item" 
for better searching.

The symptoms here and in bug 72379 are the same; unknown if the cause is the
same. If it is, please DUP 72379 here and update summary to mention 
"component" when fixing.
Keywords: correctness, dataloss
OS: Linux → All
Hardware: PC → All
Summary: problems loading remembered query with --- for TM → query.cgi target_milestone value does not reload form SELECTED item
I noticed last night that this even occurs when pressing the BACK button in the
browser to go back to the query page ... so surely it is JS related.

I just checked ... and it is also happening to version.  So one assumes this is
happening to all product-specific fields and is the same problem.
I suspect what we're currently seeing as bug #72379 is not the original issue on
this bug report, and this bug may be left after this is fixed.  dbaron, do you
remember if you checked the other milestones at the time?
Depends on: 72379
Target Milestone: Bugzilla 2.16 → Bugzilla 2.12
Assignee: tara → jake
Status: ASSIGNED → NEW
Keywords: patch
The symptoms are the same as bug 72379, but the problem is only partially the
same (I thought they were the same until I was testing the patch for bug 72379
and it fixed everything but target milestone).  The problem was that
target_milestone wasn't in the list of form fields that were processed and
checked for default values.  Because of that, the target milestone was never
set.  Because of this the JavaScript bug was never even a factor.

The patch here is only half the fix.  With this and the patch Myk attached to
bug 72379 everything works as expected.
r= justdave

checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assumedly the Javascript bug was still a factor if you hit the back button, but
not if you clicked on Edit Query.  But either way, I'm glad to see both halves
of this checked in.
V.
Status: RESOLVED → VERIFIED
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: