Resubmitted Super Search query converts/escapes/decodes = to %3D (and adds extra params), which kills results

VERIFIED FIXED in 65

Status

Socorro
Webapp
P1
major
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: stephend, Assigned: adrian)

Tracking

unspecified

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa+], URL)

(Assignee)

Updated

4 years ago
Assignee: nobody → adrian
Priority: -- → P1
(Assignee)

Comment 1

4 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

4 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

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Target Milestone: --- → 64
(Reporter)

Updated

4 years ago
Depends on: 872547
(Reporter)

Updated

4 years ago
Whiteboard: [qa+]
(Reporter)

Comment 3

4 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

4 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
Target Milestone: 65 → 66
(Assignee)

Comment 5

4 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
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Target Milestone: 66 → 65
(Reporter)

Comment 6

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