Closed Bug 1024820 Opened 5 years ago Closed 5 years ago
Search returns different results when pressing submit after typing
Searching (via the rocketbar on the vertical app) has inconsistent results depending on how you search: STR: type 'phone' (do not hit enter) the phone app appears in the results press enter the phone app disappears from the results Expected After pressing enter results should be added or be identical to those seen while typing.
This is fairly simple the search app goes through entirely different code paths depending on the event dispatched https://github.com/mozilla-b2g/gaia/blob/master/apps/search/js/search.js#L102 input emits a 'change' and pressing enter emits 'submit' https://github.com/mozilla-b2g/gaia/blob/master/apps/search/js/search.js#L110 Fairly sure this only searches via the web provider
Yeah, this is actually by design. We do a 'pure' E.me API search on enter, and different ones for autocomplete. Users can change the default search provider in settings. I know.. it's weird.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Per the dupe - This is creating a bunch of confusion to our daily testers. I think we need a consistent design in autocomplete & hitting enter on e.me search. UX - Can you look into this problem & suggest a solution?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Need UX's input before I make a FC blocking decision.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?]
Users can (and probably should) switch to google in the settings app. This makes it a lot more clear. UX and product have already looked at this behavior, but we can make some updates (or even change the default), if we want.
Flagging Francis since he's been working on this a lot this week but, per our daily SysFE triages/stand-ups, the partner work is not complete so that's good to bear in mind. Also flagging Jacqueline since I recall some IRC chat on when apps should/should not appear from yesterday. Reassign as appropriate.
Moving to block vhomescreen.next. If we do fix it great, and let's ask for approval. This could definitely be better, but is mostly implemented to spec.
(In reply to Kevin Grandon :kgrandon from comment #9) > Moving to block vhomescreen.next. If we do fix it great, and let's ask for > approval. This could definitely be better, but is mostly implemented to spec. I don't think I agree with that justification. Just because an implementation is implemented to spec doesn't mean it's right. Naoki & I have done another exploratory test run on this & have concluded that the existing implementation when hitting enter is unacceptable, as the user is getting less search results than they initially expect (e.g. no marketplace download suggestions upon hitting enter). This is a blocker from QA's perspective.
Component: Gaia::Homescreen → Gaia::Search
Naoki & I > have done another exploratory test run on this & have concluded that the > existing implementation when hitting enter is unacceptable, as the user is > getting less search results than they initially expect (e.g. no marketplace > download suggestions upon hitting enter). This is a blocker from QA's > perspective. The general idea is that pressing Enter should hand over to the search provider and provide dedicated results from the search provider. However, I agree this approach makes more sense for search providers like Google - if e.me is set as the default search provider, I would be ok keeping the existing results in, as e.me is a bit of a different case.
It would not make sense to show existing local results in an EverythingMe search landing page. Perhaps we should show additional EverythingMe results? In smart collections for example we can load more results as the user scrolls, maybe we should show 2-3 pages when they load this page.
Removing flag as the app should/should not appearing conversation was surrounding app states which I don't think applies to this bug.
Moving this to WONTFIX as bug 1026293 would remove e.me as one of the search engines available on Enter press which would eliminate this issue.
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.