350315 - amtrak.com - Index page never stops reloading

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: English US, defect)

Description

[Kurt Weinschenker]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060825 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060825 Minefield/3.0a1

Amtrak.com's main page never stops reloading with Minefield built with Cocoa widgets (Cocoafox?).  I've noticed I can stop the reloading manually by hitting the stop button.  Page works normally with recent Camino nightly builds.  

Reproducible: Always

Steps to Reproduce:
1.Go to amtrak.com.
2.
3.

Actual Results:  
Page starts loading.  Dates on train reservation start at January 1, page blanks, brings up current date, then reloads in a loop.

Expected Results:  
Page loads, stops with current date.

Recent Camino nightly builds work fine, as have release versions of Camino.  Marking this as major owing to a high profile website.

Comment 1

[Chris Lawson (gone)]

Just a shot in the dark, but if you spoof your user-agent as Firefox 1.5, does the problem go away?

cl

Comment 2

[Ria Klaassen (not reading all bugmail)]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060826 Minefield/3.0a1

Comment 3

[Kurt Weinschenker]

I would expect it to work under Windows -- this build that doesn't work is a recent nightly Cocoafox build.  

I will try to find a Firefox extension to spoof my user-agent, but it may not work either, under Cocoafox.  Give me a day or two.

Comment 4

[philippe (part-time)]

1/ The problem happens both on the 'Cocoa Fox' builds and the regular Minefield builds on OS X.

2/ Once I spoofed my UA as Firefox 1.5:
user_pref("general.useragent.override", "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5");
the endless loop/reload disappears.

Comment 5

[Chris Lawson (gone)]

So this is busted user-agent sniffing per comment 4.

--> Tech Evangelism, but someone else can do it.

cl

Comment 6

[Simon Howes]

Yes, I see this bug present too.


Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060828 Minefield/3.0a1

Comment 7

[Mats Palmgren (inactive)]

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

Comment 8

[Kenneth Calhoun]

Attachment: The javascript in question

Comment 9

[Kenneth Calhoun]

Because the UserAgent string changed from Firefox to Minefield, it fails on the check to see if this browser is Firefox or not. However, the problem here comes in the later string that's supposed to check for Safari. As Minefield is version 3, the code blindly says, "oh, it's a version 3 browser and on a mac, it must be Safari" causing all of the defines from Safari to kick in.

I'd see two fixes. One is the Evangelism route -- pester Amtrak to fix their code, the other I'd see is to alter the User Agent string to something like Minefield (Firefox)/3.0a1, which works just fine. 

Comment 10

[Chris Lawson (gone)]

(In reply to comment #9)
> I'd see two fixes. One is the Evangelism route -- pester Amtrak to fix their
> code, the other I'd see is to alter the User Agent string to something like
> Minefield (Firefox)/3.0a1, which works just fine.

It is not our responsibility to make changes in our code for the sole purpose of allowing sites to continue with badly implemented and poorly thought-out code behaviours.

If Amtrak has a legitimate reason to do browser sniffing, they should be sniffing based on rendering engine, not user-agent name.

BTW, the site

http://geckoisgecko.org/

may be of assistance in convincing them they're the ones at fault here.

cl

Comment 11

[Jesse Ruderman]

It's not just the index page -- the "routes" page and its subpages do the same thing.

Interestingly, the same thing happens with Safari trunk.  I didn't realize the solution was to use a release version of Safari/Firefox until I saw this bug.

Comment 12

[Gervase Markham [:gerv]]

http://www.amtrak.com/lib.js?v=2.2 still has bad sniffing code, but it doesn't seem to make much difference. I could search for train times fine, and there was no continuous reload.

Anyone know of an actual problem still on amtrak.com? Disassociating from bug 334967 meantime; put it back if a problem is found.

Gerv

Comment 13

[Kurt Weinschenker]

Just tested with Camino nightly 2007061419 (2.0a1pr).  Amtrak.com now works normally, so I'm going to mark this as FIXED, if I'm allowed.

Comment 14

[Chris Lawson (gone)]

Restoring dependency for historical purposes.

Comment 15

[Jesse Ruderman]

I still see this problem in Firefox trunk and WebKit trunk.

Comment 16

[Chris Lawson (gone)]

INCOMPLETE due to lack of activity since the end of 2009.

If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself.

Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.