When user navigates to nydailynews.com from the Browser App, and selects the '1>' symbol to navigate to tab view, after approximately 1 minute, the tab view displays a folder frowning/sad face with the tag of Daily News America – Breaking. When user selects the '<' symbol to return to Browser view, user sees the message 'Well, this is embarrassing. We tried to display this web page, but it's not responding. However, selecting nydailynews.com from a Google search link redirects to the mobile site for NY Daily News ( m.nydailynews.com) Repro Steps: 1) Updated buri to BuildID: 20140106004001 2) Tap Browser App 3) Clear Browser history and cookies and stored data 4) Type www.nydailynews.com in URL bar 5) Tap '1>' to go to Tab view 6) Wait for the page to load (approximately 1 minute) Actual: The tab view displays a folder frowning/sad face with the tag of Daily News America – Breaking. When user selects the '<' symbol to return to Browser view, user sees the message 'Well, this is embarrassing. We tried to display this web page, but it's not responding. Expected: Page loads successfully without an error message displayed Environmental Variables: Device: buri 1.3 MOZ BuildID: 20140106004001 Gaia: 35a60b82f8cf2d759939a350e2dadbb9d8b2f5dc Gecko: a43cb4b322d3 Version: 28.0a2 Other notes: 1. Using Cellular & Data as the only online setting reproduced the issue. 2. Using WiFi as the only online setting reproduced the issue. 3. Conducting a google.com search for nydailynews.com, the first result is www.nydailynews.com – yet selecting this option from the Google link automatically sends user to m.nydailynews.com and data appears very quickly and without the 'embarrassing error message'. 4. Having multiple tabs open for various websites that included at least one www.nydailynews.com tab causes the nydailynews.com site to crash while the other large content sites (tvguide.com, mlb.com) to load slowly but load without an error message. 5. Per http://www.alexa.com/siteinfo/nydailynews.com, nydailynews.com is ranked as 428th for global views. Repro frequency: 90% (18 of 20) See attached: logcat, screenshot
This issue reproduces on Buri v 1.2 Environmental Variables: Device: buri 1.2 MOZ BuildID: 20140106004001 Gaia: 8441587c3b352e052fee07665c21fd192540f19f Gecko: d552c08a72d0 Version: 26.0
status-b2g-v1.2: --- → affected
status-b2g-v1.3: --- → affected
Does this reproduce on 1.1?
Component: Gaia::Browser → General
(In reply to Jason Smith [:jsmith] from comment #4) > Does this reproduce on 1.1? Yes this does reproduce on the latest v1.1 Buri build. Environmental Variables: Device: Buri 1.1 MOZ BuildID: 20140107041207 Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f Gecko: 66c4a3131c39 Version: 18.0 Firmware Version: 20131115
status-b2g18: --- → affected
Moving over to TE because the problem here is that a desktop site is getting rendered, that so happens to consume a lot of memory on use.
Component: General → Mobile
Product: Firefox OS → Tech Evangelism
I haven't reproduced the tab crash yet (too impatient for that), but indeed, we're getting served the desktop content which is quite heavy. In 1.2, going directly to nydailynews.com results in desktop content. And as already mentioned, following the link from Google results in the mobile site. The URL they link to from their result is: http://www.google.com/url?q=http://m.nydailynews.com/&sa=U&ei=FcvOUvvqG6nOsAS9v4HoDA&ved=0CAwQFjAA&sig2=3qIIE1NUtYcgAST9GmIAIA&usg=AFQjCNEOxV97LWjnuLRX20rRJdwdXldtLg Looks like Google is doing us a favor? We need to reach out to nydailynews.com and ask that they redirect Firefox OS to the mobile site (which they already do for Firefox for Android).
Whiteboard: dogfood1.3 → dogfood1.3[country-all][serversniff][contactready]
Summary: [B2G][Browser]Consistent Browser App crash for website nydailynews.com → [B2G][Browser] nydailynews.com serves desktop site to b2g (which can result in tab crashing)
Firefox OS: http -h GET http://www.nydailynews.com User-Agent:'Mozilla/5.0 (Mobile; rv:26.0) Gecko/26.0 Firefox/26.0' HTTP/1.1 200 OK Firefox Android: http -h GET http://www.nydailynews.com User-Agent:'Mozilla/5.0 (Android; Mobile; rv:26.0) Gecko/26.0 Firefox/26.0' HTTP/1.0 302 Found Connection: close Location: http://m.nydailynews.com/
Reached out on Twitter to the Creative Director.
Assignee: nobody → astevenson
Whiteboard: dogfood1.3[country-all][serversniff][contactready] → dogfood1.3[country-all][serversniff][sitewait]
Trying another contact on twitter. https://twitter.com/MozWebCompat/status/428720279859126273
Response from contact, provided details via email. They are looking into it.
I have discovered similar behavior to this issue from Comment 0 on the website nasdaq.com. When user types that url on the Buri device 1.3 in the browser app, the page does not automatically redirect to the mobile site m.nasdaq.com. Similar to Comment 0 - Other notes #3 - conducting and selecting a google search result takes user directly to the mobile site of Nasdaq. The only difference is the nasdaq site is not displaying an error message, just the page looks awkwardly. Shall I create a new bug for the Nasdaq (and any other) site that demonstrates this behavior or add the appropriate STR and steps in this bug for Nasdaq?
Mclemmons. See comment #7 by mike. Google gives different results if you are a desktop browser or a mobile browser and if Google knows that there is a mobile site AND that you are using a mobile device, it will give the results to the mobile device. So beware of results given by Google, it's helpful for the users but not for testing.
Created Bug 966082 for nasdaq
Response: Fix should be in place. But we are still getting routed to the desktop site. They are reviewing.
Adding the domain name and we are still receiving the desktop content.
Reached out to our contact for a follow up. I noticed that Firefox for Android the "hamburger" menu icon doesn't work on m.nydailynews.com. As in you touch the button but the menu doesn't slide out. Miketaylr did some investigation and says it has something to do with "ADEPRIMO.Mobile.Menu" in the "bundle.common.js" file. It looks like only iOS gets touch event handlers and Firefox gets a click handler, so it's possible click isn't firing for some reason.
It all works fine on my Flame now, including the burger menu :)
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Hm.. selecting entries in the burger menu still sends us to www. not m.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
On Android, a "TypeError: this.osVersion is null" error indicates some problems in their client-side sniffing too.. Anyway, even though the front page is m.nydailynews some sub-pages like http://m.nydailynews.com/new-york have backend-browser sniffing that will redirect to www.
Status: REOPENED → NEW
seems fine now
Status: NEW → RESOLVED
Last Resolved: 5 years ago → 4 years ago
Resolution: --- → FIXED
Component: Mobile → Mobile
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.