Closed
Bug 928098
Opened 11 years ago
Closed 11 years ago
Resubmitted Super Search query converts/escapes/decodes = to %3D (and adds extra params), which kills results
Categories
(Socorro :: Webapp, task, P1)
Socorro
Webapp
Tracking
(Not tracked)
VERIFIED
FIXED
65
People
(Reporter: stephend, Assigned: adrian)
References
()
Details
(Whiteboard: [qa+])
(Spun off from bug 925691.) STR: 1. Load https://crash-stats.mozilla.com/search/?product=Thunderbird&dump=calbasecomps.dll 2. Now, click "Search" Actual Results: Now, you load https://crash-stats.mozilla.com/search/?product=Thunderbird&dump=%3Dcalbasecomps.dll&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform, which has no results Expected Results: I believe it should be the same as the original query
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → adrian
Priority: -- → P1
Assignee | ||
Comment 1•11 years ago
|
||
Here is what's happening: the page loads with a set of parameters that say "dump has xxx". However, the "has" operator is not allowed for strings, and the dynamic_form lib will thus fall back to using the default "is exactly" operator. When you click "Search", it changes the URL to what it should indeed be, and adds an encoded = in the URL, as that is the operator for "is exactly". My solution is here: https://github.com/mozilla/socorro/pull/1603 It simply changes what the default operator is when a not-allowed one is used. For strings, it will be "contains", which is the closest to what users would expect by typing "dump=xxx".
Comment 2•11 years ago
|
||
Commit pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/03e2118a3a8832a2e07c7c8e48d8f936cf0eae2f Fixes bug 928098 - Made default operator an allowed one instead of "has" when it is missing. r=peterbe
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Target Milestone: --- → 64
Reporter | ||
Updated•11 years ago
|
Whiteboard: [qa+]
Reporter | ||
Comment 3•11 years ago
|
||
I can't actually verify this until bug 872547 is fixed, so I've set that dependency. Should we move this bug's milestone and/or reopen, Adrian?
Reporter | ||
Comment 4•11 years ago
|
||
(In reply to Stephen Donner [:stephend] from comment #3) > I can't actually verify this until bug 872547 is fixed, so I've set that > dependency. Should we move this bug's milestone and/or reopen, Adrian? Spoke with rhelmer, and I'm reopening and retargetting for 65, so this can be fixed and re-tested/verified then.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 64 → 65
Updated•11 years ago
|
Target Milestone: 65 → 66
Assignee | ||
Comment 5•11 years ago
|
||
I believe we can mark this as resolved already. Here is a way to verify it: 1. Go to https://crash-stats.allizom.org/search/?signature=hang 2. I shows data that have the term "hang" 3. Click the search button, it now shows data containing the string "hang" Note that the latest result is slightly different, for example "Change" will be returned in step 3 whereas it wasn't in step 2. I believe this is a good solution for this at the moment. The reason for this difference is as follow: the URL for the search page is generated by a javascript script, based on the search form. However, if a user enters a URL manually, then that user can use values or operators that would not have been accepted by the JS script. At the moment, we do not pass that manually generated URL to the script first, and send it to the webapp right away. It results in queries being performed while it would not have been possible through the UI only. And thus leads to different results being displayed after pushing the Search button (and going through the JS validation). I don't think we want to change that behavior, because it would need adding some overhead in the page load and making it slower. This should be an exceptional case enough that we can afford not to make the normal behavior slower.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Target Milestone: 66 → 65
Reporter | ||
Comment 6•11 years ago
|
||
Thx Adrian, the explanation makes sense to me.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•