Closed Bug 967772 Opened 7 years ago Closed 7 years ago

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


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

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: rkuhlman, Assigned: amirn)



(Whiteboard: [mwcdemo2014])


(2 files)

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.

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

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

Repro frequency: 100%
See attached: screenshot.
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.
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 948313
No longer blocks: rocketbar-search-mvp
Hmm, I may have actually been wrong about the dupe. It seems the problem here is that you aren't showing any results. We have seen some issues due to firewalls and such blocking results from showing.

rkuhlman - can you tell me if you are behind a firewall, and if you have tried accessing the results with Wifi turned off and over a mobile connection perhaps?
Flags: needinfo?(rkuhlman)
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.
Flags: needinfo?(rkuhlman)
Kevin - What do you think - is this still a dupe? This apparently happening on mobile data as well.
Flags: needinfo?(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.
Flags: needinfo?(kgrandon)
Resolution: DUPLICATE → ---
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"}
(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?
Flags: needinfo?(ran)
Also adding Amir in case he sees it first.
Flags: needinfo?(amirn)
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.
Flags: needinfo?(ran)
Flags: needinfo?(amirn)
The AJAX request is going through, and this is the text that the API returns - so it looks like it's definitely a server issue. Perhaps it doing something with request header detection?
This is indeed an server issue.

A fix will be deployed later today. Will update.

Thanks Kevin!
Assignee: nobody → amirn
Fixed and deployed.

Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.