Closed Bug 1024820 Opened 5 years ago Closed 5 years ago

Search returns different results when pressing submit after typing

Categories

(Firefox OS Graveyard :: Gaia::Search, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jlal, Unassigned)

References

Details

(Whiteboard: [systemsfe])

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
Duplicate of this bug: 1024977
Duplicate of this bug: 1024977
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
Flags: needinfo?(firefoxos-ux-bugzilla)
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.
Flags: needinfo?(jsavory)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(fdjabri)
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.
Blocks: vertical-home-next
No longer blocks: vertical-homescreen
(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.
Blocks: vertical-homescreen
No longer blocks: vertical-home-next
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?] → [VH-FL-blocking-][VH-FC-blocking+]
Component: Gaia::Homescreen → Gaia::Search
Whiteboard: [systemsfe]
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.
Flags: needinfo?(fdjabri)
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.
Flags: needinfo?(jsavory)
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 ago5 years ago
Resolution: --- → WONTFIX
blocking-b2g: 2.0? → ---
You need to log in before you can comment on or make changes to this bug.