165538 - usatoday.com - assumes that non-Firefox Gecko browsers can't handle Flash

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Dave]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020826

I just gave the code (which I'm about to attach) a once over and I think the
above is what's going on. The script verifies that the platform is "win" or
"mac" and anything else falls through to the default "return 0" at the end of
function sniffFlash.
As a result of this, Linux users (even those running NS4.x) are told to go
install the Flash plugin even if it's install and working.

Reproducible: Always

Steps to Reproduce:
1. Go to bug URL, which should be a "city guide" to Atlanta (there're other
places I've seen this at usatoday.com, but I imagine the above page won't be
moved/removed in the near future).
2. Click on the "Atlanta photo album" link below the picture at top right of page.
3. A popup will appear that, if you're running something other than win or mac,
will tell you to go away and come back when you have flash.
4. You, of course, must have flash installed and working in order for this to
really be a bug.

Actual Results:  
When USA Today assumes, they make an...

Expected Results:  
USA Today should be informed that Linux (and any other other non-windows/non-mac
platforms that do) have flash support.

I get the same message when using NS4.x on Linux, which backs my claim that it's
Linux and not necessarily Mozilla that's being discriminated against. However,
I'm not quite sure, based on the code, that it would work in mozilla.

Comment 1

[Dave]

Attachment: USA Today's flash plugin sniffer code.

Comment 2

[Kai Lahmann (is there, where MNG is)]

I guess there are more way's to end wrong :)

Comment 3

[Dave]

At a second glance, I think they actually did go out of their way to support
mozilla, opera, webtv and any browser that claims to be "compatible" with a
major browser. However, they still appear to have forgotten to support Linux,
which might technically make this not a mozilla bug, but I'll leave it up to the
bug owner to decide that.

Comment 4

[Kai Lahmann (is there, where MNG is)]

uhm.. Flash gone? Who finds some?

Comment 5

[Dave]

Huh? There's still flash on that page in the URL field (click on photo album link).

Comment 6

[hoecoop]

This isn't just Linux.  I am running Mozilla 1.2.1 on Windows NT 4 SP6a.  From
the front page of usatoday.com, when I click on Day in Pictures (under PHOTOS,
near the bottom of the page), I get the message I need to have Flash installed.
 Flash is working fine from any other site I have tried.

Comment 7

[Dave]

OS -> All

hoecoop, what version of flash are you running? One possibility that's occurred
to me is that USA Today might be using Flash6, but haven't been able to test
because that version isn't available for Linux yet.

Comment 8

[Dave]

Flash 6 is finally available for Linux, so I went back to the city photo
galleries and I'm getting the "go get flash" message, even though I have the
latest version installed and have tested it (with a flash6 only animation) to
make sure it works.

If you download

http://www.usatoday.com/js/common/flash.js with wget

you will notice that the sniffEnv function only checks for two platforms (win
and mac) and, in the sniffFlash function, returns 0 if the client isn't running
one of those two platforms.

Based on the above, however, I can't see why it wouldn't work on NT4

Comment 9

[Dave]

Just noticed the Miami photo album appears to display the "go get flash" message
even under windows, which is probably what hoecoop saw.

Comment 10

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 11

[Andrew Schultz]

> Based on the above, however, I can't see why it wouldn't work on NT4

     if(is.win){
        if(is.nav4up){
            if(flash4){ return(1); }
            else      { return(0); }
        }
        else if(is.ie4up){
             ie_foobar();
        }
     }

"nav4up" explicitly excludes mozilla (and opera).

Comment 12

[Bob Clary [:bc] (inactive)]

javascript:agt   = navigator.userAgent.toLowerCase();
alert(((agt.indexOf('mozilla')!=-1) && (agt.indexOf('spoofer')==-1) &&
(agt.indexOf('compatible') == -1) && (agt.indexOf('opera')==-1) &&
(agt.indexOf('webtv')==-1)))

returns true in Mozilla. 

This bug is about the restriction to is.win or is.mac and not about anything
else I believe.

Comment 13

[Andrew Schultz]

Attachment: sniffer.js with line breaks

this is http://js.usatoday.com/_common/_scripts/sniffer.js
Mozilla for windows and linux both get caught up on line 82+
(fxGetNetscapeVersion()) of the attachment:

     82 	 arrUA=strUserAgent.split("Netscape");
     83 	 arrUA=arrUA[1].split("/");
     84 	 version=parseFloat(arrUA[1]);

since Mozilla's useragent doesn't contain the word "Netscape" this produces a
javascript error, which prevents any further useful browser sniffing.  This
show up on JS console as:

Error: arrUA[1] has no properties
Source File: http://js.usatoday.com/_common/_scripts/sniffer.js
Line: 1

the specific OS and flash detection is also in this attachment and looks like
it might work.	I'm not sure where the previous flash.js attachment gets
included in the html (perhaps usatoday upgraded their site).

Comment 14

[Dave]

I believe I probably took flash.js from the City Guide section, which now
appears to work. Most of the cities at

http://www.usatoday.com/travel/destinations/cityguides/index.htm

have Flash photo galleries, all of which appear to work with Moz1.3/Win32. The
polls on the main page, however, don't work on this same browser.

Comment 15

[Dave]

Those city photo galleries, however, don't work on Linux with Debian's Moz1.5
package.

Comment 16

[Hermann Schwab]

*** Bug 231634 has been marked as a duplicate of this bug. ***

Comment 17

[Hermann Schwab]

http://www.usatoday.com/news/snapshot.htm?section=M&label=2004-01-20-contract.jpg
is a flash link from bug 231634.

The flash seems to be flash 4, but they are sniffing for flash 5, and I do´t
know, if the recognize flash 6 or flash 7.
sniffer.js also checks for Opera and Safari, but still has no ControlChars like
CR or LF. 

http://js.usatoday.com/_common/_scripts/usat.js     = 9.395 byte
http://js.usatoday.com/_common/_scripts/sniffer.js  = 6.547 byte

more links in bug 231634

Comment 18

[Hermann Schwab]

replacing non working URL http://www.usatoday.com/travel/extraday/atlanta/worth.htm
with that from Bug 231634, hoping it will last longer than three days.
http://www.usatoday.com/news/snapshot.htm?section=M&label=2004-01-20-contract.jpg

Comment 19

[RobertJ]

I posted this in the duplicate bug (231634) and thought it might be useful to
post it here also. I have Flash v7,0,19,0 installed. I used

user_pref("general.useragent.override", "Mozilla/4.0 (Macintosh; U; PPC Mac OS X
Mach-O; Netscape)");

in the user.js file and the usatoday site properly loaded the Flash.

It appears that by inserting "Netscape" in the user agent info the sniffer "came
to the correct conclusion".

Comment 20

[OstGote!]

*** Bug 299218 has been marked as a duplicate of this bug. ***

Comment 21

[OstGote!]

*** Bug 237459 has been marked as a duplicate of this bug. ***

Comment 22

[OstGote!]

*** Bug 244772 has been marked as a duplicate of this bug. ***

Comment 23

[OstGote!]

*** Bug 251800 has been marked as a duplicate of this bug. ***

Comment 24

[OstGote!]

Could someone figure out what needs to be added to get mozilla recognized and
contact them?

http://www.usatoday.com/marketing/feedback/feedback-online.aspx?type=15

Comment 25

[Andrew Schultz]

They've updated some but are still making invalid assumptions about gecko user
agents.  I filled in the excrutiatingly small form and pointed them to this bug.

The fxGetNetscapeVersion() function in
http://js.usatoday.com/_common/_scripts/sniffer.js assumes that the only user
agents with navigator.appName = "Netscape" and Gecko in the user agent are
Firefox, Netscape and... Safari.  This is clearly bogus.  And... <sigh> all they
use the browser sniffing for is to get the app version that they later use in a
cookie!  So it should really be in a try/catch block and/or fallback to use
something reasonable if it doesn't recognize the appName.

Comment 26

[Nicola Orritos]

I was about to file a bug about my iGoogle personalized home-page, but I found that this bug quite resembles what I'm experiencing. I inserted a Google gadget that uses Flash, but the gadget warns me about the lack of the required Flash plug-in in my Gran Paradiso installation.
I tried the usatoday.com link also and it stills warns me about no Flash...
The problem is that I have Flash installed, as I can see in "about:plugins" page.

Precisely I have: "Shockwave Flash 9.0 r45", in the "NPSWF32.dll" dll; my version of Gran Paradiso is "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4) Gecko/20070427 GranParadiso/3.0a4".

The Google gadget I added is: "http://www.google.com/ig/directory?hl=en&url=http://abowman.googlepages.com/treefrog.xml"

Comment 27

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Nicola, you should file a separate Tech Evangelism bug about comment 26, since it's a different site.

USA Today still gives the bogus error message to non-Firefox UAs (Minefield, GP, Camino), but "suddenly" works in the same browser when the UA contains "Firefox".

Comment 29

[Chris Lawson (gone)]

Do we have any contacts at USA Today? This is *still* a problem eight years on. They've got to be running out of excuses by now.

Comment 30

[David E. Ross]

The cited URI is not the only problem within the usatoday.com domain.  It is likely that all http://www.usatoday.com/news/snapshot.htm pages have this problem and that other http://www.usatoday.com/ are also afflicted.  

I saw this today with the UA string
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205 
        SeaMonkey/2.0.3
but the problem went away with 
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205 
        SeaMonkey/2.0.3, NOT Firefox/3.6.3

I have Flash 10.0 r45.

Comment 31

[Chris Lawson (gone)]

Yeah, this is a problem across the entire site. Sorry if that wasn't clear.

Comment 32

[David E. Ross]

After 8 years, none of the prior comments indicates anyone contacted USA Today about this problem.  When writing a bug report about a broken Web site -- a site where the problem is within the HTML, CSS, scripts, or server -- it is important that the owner of the site be notified.  Putting a bug report on bugzilla.mozill.org will NOT provide that notification.  

I contacted USA Today about this problem today.

Comment 33

[David E. Ross]

This is still a problem.

Comment 34

[Karl Dubost💡 :karlcow]

→ ping sitelife.usatoday.com
PING sitelife.usatoday.com (69.64.158.129): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5


http://usatoday30.usatoday.com/news/snapshot.htm?section=N&label=2010-05-06-volcano
This URL is trying to download assets from a domain which doesn't exist anymore
The snapshot page itself is a 404.
The site has been changed.

Comment 35

[David E. Ross]

Attachment: USA TODAY Snapshots.pdf

Windows 7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 SeaMonkey/2.26.1

The old URI redirected to a new URI, which is now in the URL field of this bug report.  The problem still exists.  See the attached PDF file.

Comment 36

[Karl Dubost💡 :karlcow]

Attachment: usatoday-longlong.png

David, did you try to contact the site?


As you can see in the screenshot. The network takes a very long time before resolving the domain this on Firefox.
"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0"

It took 2,50 min before getting something.

Same thing is happening with Safari. So it's not related to Firefox specifically.



When finally it has finished loading after 3min, I'm reaching this URI, which has issues too. The flash exhibits an XML Error 4.
http://usatoday30.usatoday.com/news/snapshot.htm?section=N&label=2010-05-06-volcano


Note that when I enter directly 
http://usatoday30.usatoday.com/news/snapshot.htm?section=N&label=2010-05-06-volcano
I have the same exact issue of waiting for anything to happen.

The blocking script seems to happen with
http://content.usatoday.com/asp/usatAj/usataj.js

As for UA sniffing, they have plenty of sources of UA sniffing in a couple of scripts.

Comment 37

[David E. Ross]

I reported it this morning.  I would have hoped the originator of this bug report had reported it back in 2002.  Nothing in this regard has changed since then.

Comment 38

[Hallvord R. M. Steen [:hallvors]]

New code looks better: in http://i.usatoday.net/_common/_scripts/sniffer.js look for
navigator.hasFlash=fxHasFlash;
and the fxHasFlash function that just detects whether to use the plugins/mimeTypes-objects or the ActiveX approach. LGTM.