50158 - clicking on AOL page/links gives asserts, then goes to wrong page

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English US, defect, P2)

Description

[buster]

I don't know if this is one problem, or two.
Using debug build, code from 8/23/00 late pm pst
WinNT 4, using mozilla browser
1. go to www.aol.com
2. click on button "Try AOL Free"
this seems to try to send you to 
http://dynamic.aol.com/cgi/redir-complex?url=http://free.aol.com/tryaolfree/inde
x.adp?11&sid=np1
3. you will get several assertions:
###!!! ASSERTION: Could not provide a substititute font: '0', file 
S:\mozilla\gfx\src\windows\nsFontMetricsWin.cpp, line 2021
4. Finally, if you continue past the assertions, you will be taken to the wrong 
page:
http://www.aol.com/info/international.adp
instead of
http://free.aol.com/tryaolfree/index.adp?124510

Comment 1

[buster]

pretty serious bug since aol is an important web site for us

Comment 2

[Erik van der Poel]

I didn't see any asserts when I tried the "Try AOL Free" button in the small
pop-up window. However, Mozilla did go to that international.adp page instead
of the other one. I'm wondering whether the server is sending different content,
depending on the browser version (i.e. Netscape 4 vs 6).

Comment 3

[Erik van der Poel]

Hi Gagan, is this the type of thing that you have tools for? I.e. checking to
see whether the server is sending different content, depending on the client
version?

Comment 4

[Gagan]

yes a network trace should suffice to catch the mystery here. I'll take a look. 

Comment 5

[Phil Peterson]

PDT agrees P2

Comment 6

[Phil Peterson]

Not holding PR3 for this. Marking nsbeta3- but adding rtm keyword since it's an 
AOL page.

Comment 7

[Gagan]

darin: can you investigate this? 

Comment 8

[Darin Fisher]

Several redirects are happening...  we get into trouble on:

http://free.aol.com/tryaolfree/index.adp?124510

This outputs a frameset, in which one of the frames has some javascript code
that checks "navigator.language" and
"java.util.Locale.getDefault().getCountry()" to determine whether or not to
redirect the frame to the international tryaol site.

I am attaching the page with the javascript in question (actually, the log of
the HTTP transaction).  It must be that we simply aren't announcing our language
and/or country code in the same way that 4.x does.

Someone with more knowledge of the javascript api's want to take a look?

Comment 9

[Darin Fisher]

Attachment: Questionable javascript (w/ full HTTP transaction log)

Comment 10

[Darin Fisher]

Looks like under Linux build 2000100909,

  navigator.language == en_US

which results in "international = true"

Comment 11

[buster]

cc-ing the DOM guys, and erik.

Comment 12

[ekrock's old account (dead)]

[gagan asked me to comment on this bug.] Frank, would you or someone else who's 
an expert in i18n please tell us what's the right thing to do? I have no idea 
which string is right; I'm not an expert in this area. i18n experts: please 
consider yourselves empowered to decide what is The Right Thing. The goal is to 
achieve (1) backward compatibility with past behavior, and the client- and 
server-side scripts and sniffers that depend on it, and (2) standards compliance 
(with the RFCs that specify which string to use with what meaning). If these two 
goals are in conflict on this point, (1) may have priority due to the 
unacceptability of Breaking The Web and the lack of time before ship to correct 
any potentially hazardous mistakes. When in doubt, minimal risk is the goal at 
this point. Thanks!

dbaron's UA spec here:
http://www.mozilla.org/build/revised-user-agent-strings.html

... mentions some RFCs that may be relevant. cc:ing dbaron. 

Comment 13

[Gagan]

->ftang for resolution.

Comment 14

[tao]

While 4.x US client returns 'en' for 'navigator.language', Mozilla 5 returns
'en-US'. Both are right according to the Mozilla or the so mentioned RFCs.

There two problems here:
1. The server javascript shouldn't use this information for the sake of
   content negotiation. The u-a string is for statistical purpose.
   The Accept-Language field of the HTTP header is a better choice for
   content negotiation.
2. The u-a sniffer assumes that Netscape does not ship non-US Egnlish client.
   This is not true anymore. Perhaps, it should check appVersion, too. For
   5.0, we use en-US to indicate the US client.

Any chance that we ask AOL to revise the sniffer script? I notice that the
script deal with different version of IE, too.

Assuming "en" == "en-US" is bound to offend non-US English speakers.

Comment 15

[Erik van der Poel]

I'm wondering whether navigator.language really ought to be "en_US" rather than
"en-US". Unix systems often use the underscore (_), but Internet protocols use
hyphen (-). What should navigator.language (JavaScript) use?

Comment 16

[tao]

changing Component to "Evangelism" 

Comment 17

[Frank Tang]

I think that sniffer is simply broken. I got the same result by using 
English 4.73

HTTP_USER_AGENT = Mozilla/4.73 [en]C-NSCP (WinNT; I)

Comment 18

[Frank Tang]

jaimejr, this is not a client bug but a content problem. Please help to find AOL 
webmaster to fix this. Thanks.

Comment 19

[Zach Lipton [:zach]]

Since this is an aol site problem. This bug should be rtm-

Comment 20

[Blake Ross]

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

Comment 21

[Blake Ross]

So is this a server-side problem as Frank suggests, or a client problem?  If 
the latter, this is an rtm stop-ship (per bug 57965, which appears to be the 
same root cause).  If the former, Netscape will have to get in touch with its 
aol contacts...whoever those might be.

Comment 22

[Blake Ross]

Also, Zach, this should not have been rtm- yet (and only managers/PDT should be 
doing that).  Frank's 10-23 14:09 comment only seems to suggest that this is a 
server-side problem, we'll need absolute verification...

Comment 23

[lchiang]

jaime - can you get in contact with Netcenter/AOL folks on this?

Comment 24

[Mike Pinkerton (not reading bugmail)]

cc'ing myself, lisa and jar, from the previous bug that was on the FC watch list.

Comment 25

[Frank Tang]

So here is the buggy script on the server site
var international = false;
if (navigator.userAgent.indexOf("Win") >= 1)  {
        if (navigator.appName == "Netscape") {
                if ((navigator.language != "en") || 
(java.util.Locale.getDefault().getCountry() != "US"))
                        international = true;
        } else if (navigator.userAgent.indexOf("MSIE 3.0") >= 1) {
                // do nothing for IE 3
        } else if (navigator.userAgent.indexOf("MSIE") >= 1) {
                if (navigator.userLanguage != "en-us")
                        international = true;
        } else if (navigator.language != "en-us") {
                international = true;
        }
} else {
        // if we aren't on Windows, be a little more careful about what we call 
"non-US" --
        // the browser may not return the country code, only a language code
        if (navigator.appName == "Netscape") {
                if ((navigator.language != "en") || (java.util.Locale.getDe
fault().getCountry() != "" && java.util.Locale.getDefault().getCountry() != 
"US"))
                        international = true;


I think this is wrong, they can easily change the line

                if ((navigator.language != "en") || 
(java.util.Locale.getDefault().getCountry() != "US"))
                        international = true;

to
                if (((navigator.language != "en") && (navigator.language != 
"en-us")) || (java.util.Locale.getDefault().getCountry() != "US"))
                        international = true;

and change 
 if ((navigator.language != "en") || (java.util.Locale.getDe
fault().getCountry() != "" && java.util.Locale.getDefault().getCountry() != 
"US"))
                        international = true;

to
 if (((navigator.language != "en") && (navigator.language != "en-US"))|| 
(java.util.Locale.getDe
fault().getCountry() != "" && java.util.Locale.getDefault().getCountry() != 
"US"))
                        international = true;

Comment 26

[Jaime Rodriguez, Jr.]

Adding roberts to cc: list. Also, reassigning to roberts, as I am away from the 
office.

JAR - Has there been any comments back from AOL.com on this one?

Comment 27

[Jaime Rodriguez, Jr.]

really reassigning to roberts.

Comment 28

[selmer (gone)]

rtm- was correct.  Several people have commented that the server is wrong.  The
only argument that could put this back on the client is being compatible with
4.x versions.  One of Frank's comments seems to shoot that down too.

Comment 29

[Cindy Roberts]

I sent this bug via email to 3 contacts at AOL.com who may be able to fix the
problem on their side
Jason Mitchell   [e-mail]
Mike Matthews    [e-mail]
Kristen Nuwer    [e-mail]

Comment 30

[Asa Dotzler [:asa]]

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

Comment 31

[Jaime Rodriguez, Jr.]

Cleaning up Whiteboard and Keywords.

Comment 32

[Jaime Rodriguez, Jr.]

Re-assinging to momoi-san.

Comment 33

[Katsuhiko Momoi]

Accepting ...

Comment 34

[Katsuhiko Momoi]

This seem to be working now. 
I don't get re-dorected to an international site.
The sniffer code they're using seems to be considerably
simpler and does Ok:

===============
function checkPage() {
document.cookie = "canwrite=YES";
ac = document.cookie;

  if (ac.indexOf("canwrite=YES") == -1)
  {
  return -4; // -4 Cookies Disabled
  }

  if (!window.navigator.javaEnabled())
  {
  return -3; // -3 Java Disabled
  }
  if ((navigator.language == "en") || (navigator.language == "en-US"))
  return 0; // US User
  else
  return 98; // International User 
  }
===============

Checked on 6/15/2001 Win32 build.

Since the sniffer script has been updated and does 
the right thing, I am going to mark this bug
resolved/fixed.
Please verify.

Comment 35

[Chris Petersen]

Marking verified. Tested on the June 27th build. 

Comment 36

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.