18349 - query.cgi target_milestone value does not reload form SELECTED item

Status: VERIFIED FIXED

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

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.)

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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
[e-mail] with details of what you were doing when this message
appeared. Thank you."

Comment 2

[Terry Weissman]

[e-mail] 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 .)

Comment 3

[Chris Yeh]

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)

Comment 4

[Andreas Franke (gone)]

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).

Comment 5

[Andreas Franke (gone)]

Sorry, the link is not correctly recognized. Use the URL field instead.

Comment 6

[Stephan Niemz]

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.

Comment 7

[Dave Miller [:justdave]]

moving to real milestones...

Comment 8

[Matthew Tuck [:CodeMachine]]

*** Bug 63655 has been marked as a duplicate of this bug. ***

Comment 9

[Matthew Tuck [:CodeMachine]]

When I noticed this bug, it appeared to me it didn't restore _any_ milestones.

Comment 10

[Matthew Tuck [:CodeMachine]]

Hmm, and components too.  Have the parameters to query.cgi been changed?

Comment 11

[Matthew Tuck [:CodeMachine]]

Components is bug #72379.

Comment 12

[Sean Richardson]

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.

Comment 13

[Matthew Tuck [:CodeMachine]]

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.

Comment 14

[Matthew Tuck [:CodeMachine]]

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?

Comment 15

[Jacob Steenhagen]

Attachment: Add "target_milestone" to the list of fields to be restored

Comment 16

[Jacob Steenhagen]

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.

Comment 17

[Dave Miller [:justdave]]

r= justdave

checked in.

Comment 18

[Matthew Tuck [:CodeMachine]]

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.

Comment 19

[Matthew Tuck [:CodeMachine]]

V.

Comment 20

[Dave Miller [:justdave]]

Moving closed bugs to Bugzilla product