583646 - wrong summary on bugzilla quicksearch results page when product/component shortcut is used

Status: RESOLVED INVALID

(Bugzilla :: Query/Bug List, defect)

Description

[Thomas D. (:thomas8)]

In addition to bug 528962 (confusing bugzilla quicksearch summary), the summary is actually wrong for cases like these (product/component shortcut):

STR

Per https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html, we can limit product or component by using :xyz where xyz is part of the name of a product or component.

Quicksearch for: :Thu html source
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athu+html+source

Actual result

On result page, the following summary is shown:

    * Status:  REOPENED, NEW, ASSIGNED, UNCONFIRMED
    * Product: thu
    * Component: thu
  # * Product: html
  # * Component: html
    * Alias: html
    * Summary: html
    * Whiteboard: html
    * Content: "html"
  # * Product: source
  # * Component: source
    * Alias: source
    * Summary: source
    * Whiteboard: source
    * Content: "source"

The parts of the summary marked with # are wrong and very confusing.
We are NOT searching Product and Component for any other search words if user has explicitly specified :xyz to search those two fields.

Expected result:

Combined with better layout proposed in bug 528962, comment 8, the summary should look like this:

Quicksearch for: *:xyz, search, words*
*Product or Component*: xyz
*Content: search, words
*Status:* REOPENED, NEW, ASSIGNED, UNCONFIRMED

Additional information

I assume there are more quicksearch shortcut cases where the current summary is just wrong. We should test and fix the summary for all shortcuts listed in https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html.

Comment 1

[Max Kanat-Alexander]

No, we are in fact also searching products and components for html and source--the summary is correct.

Comment 2

[Thomas D. (:thomas8)]

(In reply to comment #1)
> No, we are in fact also searching products and components for html and
> source--the summary is correct.

I don't think so, looking at the evidence:

STR

1 https://bugzilla.mozilla.org/buglist.cgi?quicksearch=:thu+html+source
2 Change columns to include "Product" and "component" in result list

Actual result
1 there is not a single bug in the result that contains either "html" or "source" in the product or component column (correct, although it could correctly happen sometimes)
2 all bugs contain "thu" in the product or component column, and "thu" is not searched for in any other field, according to summary (correct)
3 compare: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=:html+source
(we can skip "thu" because of 2)
There are 18 bugs that have "html" in the component field, and "source" in the summary field, but none of them is found in the original search (correct, as they are in the wrong component), e.g. bug 472846.

3 is the proof that you are correctly and definitely NOT searching products and components for any other searchwords (like "html", "source") if :product is specified. Any other behaviour would be another bug.

-> Reopening

Comment 3

[Max Kanat-Alexander]

Click on "Edit Search".

Comment 4

[Thomas D. (:thomas8)]

Sorry, my mistake (lack of knowledge, and wrong time of day). Max, thank you for correction and enlightening. "Edit Search" was very helpful to understand the actual search that happens behind the scenes.

I can now describe the problem more clearly:
While the summary is arguably technically "correct", it is still very confusing:

1) because of the disjointed layout (bug 528962)

2) because of the misleading nature of content (requires morphing this bug, or a new one), as I shall explain below

> Quicksearch for: :Thu html source
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athu+html+source

Current summary for that search is this (folded out from horizontal)

    * Status:  REOPENED, NEW, ASSIGNED, UNCONFIRMED
  + * Product: thu
  + * Component: thu
  # * Product: html
  # * Component: html
    * Alias: html
    * Summary: html
    * Whiteboard: html
    * Content: "html"
  # * Product: source
  # * Component: source
    * Alias: source
    * Summary: source
    * Whiteboard: source
    * Content: "source"

Problem: This summary suggests that there is no difference at all between
a) the way we search Product or Component for "thu" and
b) the way we search Product or Component for "html" and "source"

However, there is a big difference (deliberately no technical query terms here), as seen from "Edit Search":

a) All matches MUST HAVE "thu" in *{Product OR Component}*
-> The search term "thu" must occur in exactly these 2 fields (Product or Component)

b) All matches MUST HAVE "html" AND "source" in *ANY OF {Product, Component, Alias, Summary, Whiteboard, or Content}*
-> The search terms "html" and "source" *may or MAY NOT* occur in Product or Component

In the current summary, there is no visual or other indication whatsoever that ":thu" has a much stronger, namely obligatory filter effect for Product or Component, while "html" or "source" might just "coincidentally" happen to occur in the Product or Component fields (which, for BMO, is somewhat unlikely, as you would need to have a product or component like *thu*html*, *html*thu*, *thu*source*, or *source*thu*).

In other words: Practically (not technically), specifying :Thu will limit the search to Bugs whose Products or Components match *Thu*, i. e., in the case of BMO, mostly the Thunderbird product. In comparison, the occurence of "html" or "source" (the other search words) in the Products or Components fields is non-obligatory, thus pretty irrelevant (practically, not technically).

I conclude that the summary is still very confusing and impractical with regards to the advanced Product or Component filter as in the :thu example, and should be improved, e.g. like this (correction of the expected result of comment 0):

Proposed improved summary (for searches with product/component restriction):

Quicksearch for: *:xyz, search, words*
*Product or Component*: xyz
*Product, Component, Alias, Summary, Whiteboard, or Content:* search, words
*Status:* REOPENED, NEW, ASSIGNED, or UNCONFIRMED

Max, perhaps we could agree that the current format of the summary isn't ideal and could be improved by something along the lines of this comment?