steps to reproduce: 1. Launch marketplace prod app expected behavior: Homepage loads actual behavior: I see the marketplace app launch with a white screen with a blue x at the top. I see that very often with the prod app https://www.dropbox.com/s/y3lwgm23kkd3nps/Screenshot%202014-11-19%2015.18.52.png?dl=0 is the requests which are happening.
Happened to me today on desktop (Firefox and Chrome). Like in Krupa's screenshot, it was a problem with the requests to the CDN timing out (preventing any of our static assets to load). Lasted 5-10 minutes and then went back to normal.
OS: Gonk (Firefox OS) → All
Priority: -- → P1
Hardware: x86 → All
Version: 1.4 → Avenir
jason, oremj: Any CDN changes recently? Krupa said it started happening with higher frequency since a month ago roughly. I only saw it today (around 16:20 CET) myself, but since it's a CDN issue, it could just be that Krupa is hitting a PoP that is more unreliable than me.
We haven't made any recent changes to the CDN. The image in comment 0 is 404, could you please reupload or attach to bug? If this does happen again could you provide a traceroute to marketplace.cdn.mozilla.net?
The image was just showing that requests to the CDN were never terminating successfully - they were all going into timeout. I tried tracerouting when that happened, unfortunately I didn't keep the result, it was reaching an edgecast node and then a bunch of no replies. Will keep the result next time...
Kevin just reproduced this on his phone (Flame running 2.2) on Wifi. - He can reach https://marketplace.cdn.mozilla.net/ just fine on his laptop on the same wifi connection. (It's giving a 403 as expected). - He can reach http://marketplace.cdn.mozilla.net/ just fine on his phone (it's redirecting to https://m.f.c/ as expected) - BUT https://marketplace.cdn.mozilla.net/ completely fails in his Firefox OS browser. Blank page. This seems to indicate it's not a routing issue, since he can reach the host just fine over http, and it also works on his laptop with the same connection. I'm starting to suspect an SSL issue of some kind, but we couldn't get more debugging information out of adb logcat.
Note: Both Kevin and Krupa were *not* running kitkcat on their Flames, that that could be an explanation (and that'd make the issue I experienced on desktop the other day a different problem).
We may also be experiencing a related CDN issue in bug 1105495
Did anyone manage to reliably reproduce this ?
Priority: P1 → P2
(In reply to Mathieu Pillard [:mat] from comment #8) > Did anyone manage to reliably reproduce this ? I've not seen this for a while but Krupa's probably the best person to ask. Of course the second this bug gets closed it will start happening again!
I will close this bug as wfm and reopen when we hit the issue again.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
i hit it just now on a 2.0 device. i don't see any errors in logcat but i cannot get ashes since there is no way to get /debug page within the app.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Un-assigning because I really needs STR to move forward.
Assignee: mpillard → nobody
I have noticed this bug several times over the past week or more. I have run into this issue on the Flame 2.0 & 2.1
FYI - I've seen this blue X in the past and have always resolved that issue by correcting the date/time on the device. Not sure if folks have already checked this but I mentioned it as I didn't see any reference to date/time in the discussion above.
This is addressed in several ways (and probably a bunch of other bugs), so we're WONTFIXing this bug noting that the comments describe several things to check if this is your issue.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.