967772 - [B2G][Rocketbar]Typing E.Me terms into rocketbar does not result in E.Me items being displayed.

Status: RESOLVED FIXED

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

Description

[Ross Kuhlman ([e-mail])]

Attachment: rocket_me_comparison.jpg

The rocketbar search results do not populate with E.Me searches. For example, typing 'Social' does not provide the user with the same results as the 'Social' E.Me app. Rocketbar searches only display four E.Me results, and they are usually only loosely related to the search term. The search results for 'social' do not even appear in the E.Me social app search

Repro Steps:
1) Updated Buri to BuildID: 20140204040201
2) Tap on the 'Social' app located under the E.Me bar.
3) Observe search results.
4) Open rocketbar.
5) Type 'social' and wait for list to populate with results.
6) Compare results from step 5 to results from step 3.

Actual:
Rocketbar and E.Me search each produce completely different results.

Expected:
E.Me search and Rocketbar search produce similar or identical results.

Environmental Variables:
Device: Buri v1.4 Moz RIL
BuildID: 20140204040201
Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20
Gecko: c150845d077d
Version: 30.0a1
Firmware Version: v1.2-device.cfg
Notes:

Repro frequency: 100%
See attached: screenshot.

Comment 1

[Ross Kuhlman ([e-mail])]

related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=950720
https://bugzilla.mozilla.org/show_bug.cgi?id=967450

Comment 2

[Kevin Grandon :kgrandon]

This is a duplicate of both bug 966891 and bug 948313.

As it's closest to bug 948313, I'm duping against that for now.

Also - Please don't open bugs for functionality that is not defined in the 0.7 rocketbar spec.

Comment 3

[Kevin Grandon :kgrandon]

Hmm, I may have actually been wrong about the dupe. It seems the problem here is that you aren't showing any E.me results. We have seen some issues due to firewalls and such blocking E.me results from showing.

rkuhlman - can you tell me if you are behind a firewall, and if you have tried accessing the E.me results with Wifi turned off and over a mobile connection perhaps?

Comment 4

[Ross Kuhlman ([e-mail])]

In response to comment 3:
Yes we have a firewall set up on our WiFi router. I do not know the specifics of this particular firewall, and the person who set it up is OOF for a week. If you need information on the specifics of our firewall, please let me know and I will get you any necessary information.

I tried turning off WiFi and only using the mobile connection and still get the same results. I have attached a logcat of the device performing rocketbar searches for 'social' under 4 scenarios: WiFi & Mobile ON, WiFi ON & Mobile OFF, WiFi OFF and Mobile ON, and WiFi & Mobile OFF. I get the same results in all four scenarios, which is strange behavior when WiFi and Mobile are both disabled.

Comment 5

[Ross Kuhlman ([e-mail])]

Attachment: RocketbarSearchDifferentConnections.txt

Comment 6

[Jason Smith [:jsmith]]

Kevin - What do you think - is this still a dupe? This apparently happening on mobile data as well.

Comment 7

[Kevin Grandon :kgrandon]

I'll reopen so we can investigate - but this is working fine for me when I'm on a mobile connection or wifi network without a firewall. Let's look today.

Comment 8

[Kevin Grandon :kgrandon]

Turns out something has regressed here on the API side, we're now seeing these errors: {"errorCode":-9,"processingTime":5.69,"requestId":"IUF02kTVRGo","errorString":"Security Authentication denied"}

Comment 9

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #8)
> Turns out something has regressed here on the API side, we're now seeing
> these errors:
> {"errorCode":-9,"processingTime":5.69,"requestId":"IUF02kTVRGo",
> "errorString":"Security Authentication denied"}

Ran - Any ideas?

Comment 10

[Kevin Grandon :kgrandon]

Also adding Amir in case he sees it first.

Comment 11

[Ran Ben Aharon [:ranbena] EverythingMe]

This is weird. Doesn't work on device but works fine on Nightly.
It's possible this is a bug in our server (though console logs weren't very helpful). We'll look into this in depth on Sunday and let you know.

It could also be a Gecko issue (with POST ajax requests?). If you guys know of a related bug in Gecko, let us know.

Comment 12

[Kevin Grandon :kgrandon]

The AJAX request is going through, and this is the text that the E.me API returns - so it looks like it's definitely a server issue. Perhaps it doing something with request header detection?

Comment 13

[Amir Nissim (:amirn)]

This is indeed an E.me server issue.

A fix will be deployed later today. Will update.

Thanks Kevin!

Comment 14

[Amir Nissim (:amirn)]

Fixed and deployed.

Thanks.