Closed Bug 967772 Opened 11 years ago Closed 11 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rkuhlman, Assigned: amirn)

References

Details

(Whiteboard: [mwcdemo2014])

Attachments

(2 files)

Attached image rocket_me_comparison.jpg (deleted) —
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.
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
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 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?
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.
Status: RESOLVED → REOPENED
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 E.me API returns - so it looks like it's definitely a server issue. Perhaps it doing something with request header detection?
This is indeed an E.me server issue. A fix will be deployed later today. Will update. Thanks Kevin!
Assignee: nobody → amirn
Fixed and deployed. Thanks.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: