1024820 - Search returns different results when pressing submit after typing

Status: RESOLVED WONTFIX

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

Description

[James Lal [:lightsofapollo]]

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.

Comment 1

[James Lal [:lightsofapollo]]

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

Comment 2

[Kevin Grandon :kgrandon]

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.

Comment 5

[Jason Smith [:jsmith]]

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?

Comment 6

[Jason Smith [:jsmith]]

Need UX's input before I make a FC blocking decision.

Comment 7

[Kevin Grandon :kgrandon]

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.

Comment 8

[Stephany Wilkes]

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.

Comment 9

[Kevin Grandon :kgrandon]

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.

Comment 10

[Jason Smith [:jsmith]]

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

Comment 11

[Francis Djabri [:djabber]]

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.

Comment 12

[Kevin Grandon :kgrandon]

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.

Comment 13

[Jacqueline Savory [:jsavory] UX]

Removing flag as the app should/should not appearing conversation was surrounding app states which I don't think applies to this bug.

Comment 14

[Peter Dolanjski [:pdol]]

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.