[B2G][Browser] nydailynews.com serves desktop site to b2g (which can result in tab crashing)

RESOLVED FIXED

Status

Tech Evangelism
Mobile
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Montoya Clemmons (MClemmons), Assigned: adamopenweb)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g18 affected, b2g-v1.2 affected, b2g-v1.3 affected)

Details

(Whiteboard: dogfood1.3[country-all][serversniff][sitewait], URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
Created attachment 8357263 [details]
Screenshot of Crash message
(Reporter)

Comment 2

5 years ago
Created attachment 8357265 [details]
Logcat of Browser Tab Crash
(Reporter)

Comment 3

5 years ago
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
Keywords: qawanted
QA Contact: rkunkel
(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
Keywords: qawanted
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)
(Assignee)

Comment 8

5 years ago
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/
(Assignee)

Comment 9

5 years ago
Reached out on Twitter to the Creative Director.
(Assignee)

Updated

5 years ago
Assignee: nobody → astevenson
Whiteboard: dogfood1.3[country-all][serversniff][contactready] → dogfood1.3[country-all][serversniff][sitewait]
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

4 years ago
Trying another contact on twitter. https://twitter.com/MozWebCompat/status/428720279859126273
(Assignee)

Comment 12

4 years ago
Response from contact, provided details via email. They are looking into it.
(Reporter)

Comment 13

4 years ago
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.
Flags: needinfo?(mclemmons)
Created Bug 966082 for nasdaq
(Reporter)

Updated

4 years ago
Flags: needinfo?(mclemmons)
(Assignee)

Comment 16

4 years ago
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.
(Assignee)

Comment 18

4 years ago
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: 4 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: 4 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.