Please report any other irregularities here.
Prerequisites: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 Steps to reproduce: 1.Go to MP-dev and open an app with content ratings(https://marketplace-dev.allizom.org/app/test-app-ebaybeet?src=all-reviewed) 2.Press the "Content rating details" button 3.Go back to the app Expected results: "Content rating details" button is still displayed and all info about content details(description under app title, content rating icon) is present Actual results: No content rating info displayed anymore Please see screencast for this bug: http://screencast.com/t/SLFL2FcI5 Please note that after refreshing the Fireplace, the content rating is seen again, but sometimes the description is randomly displayed with Chinese characters (Region was always set to US)
This issue sounds like an issue with geoip. When you return to the Marketplace, if the system has killed the Marketplace app's session, a new session will be created. Geoip-provided regions are not persisted between sessions because that would prevent the server from supplying a new geoip region. When the user returns, the region is effectively null and the content ratings fall back on "generic" rather than region-specific ratings. Victor: Can you confirm that this issue does not occur if you are running the Marketplace using a SIM card (and are using a packaged version of the Marketplace, rather than viewing it in the browser)? It should also not occur if you manually set a region in the :debug page using the region override selector. > after refreshing the Fireplace, the content rating is seen again, but sometimes the description is randomly displayed with Chinese characters This is a separate issue, which appears to be caused by the server choosing the wrong translation for the user. Please file a separate bug for this. Ideally, the server should send a locale object back for the rating.
Assignee: nobody → kngo
I'm giving this issue some thought. The solution might involve a change to how we persist geoip-provided regions. I'll talk to cvan later today.
(In reply to Matt Basta [:basta] from comment #2) > I'm giving this issue some thought. The solution might involve a change to > how we persist geoip-provided regions. I'll talk to cvan later today. Basta, ask me.
After discussing this with cvan yesterday, this is the fix: https://github.com/mozilla/fireplace/commit/6465eb2fdf1c0282408e8748d58a4791c5c62b81 I can't reproduce the issue anymore here, so marking as fixed.
Assignee: kngo → mattbasta
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: 2013-12-17 → 2014-01-07
Verified as fixed : http://screencast.com/t/ffxKBNzoVgBv
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.