Last Comment Bug 61071 - Implement navigator.appName and navigator.appVersion according to the HTML spec
: Implement navigator.appName and navigator.appVersion according to the HTML spec
Status: NEW
: html5
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: P3 normal with 9 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.whatwg.org/specs/web-apps/...
: 117274 119949 127020 135790 136745 137732 144064 168768 180440 185318 193338 194797 203922 229761 245014 249327 264334 271896 284795 293629 507870 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-23 03:53 PST by vbreddy
Modified: 2012-09-12 19:56 PDT (History)
41 users (show)
shaver: blocking1.8.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description vbreddy 2000-11-23 03:53:23 PST
From Bugzilla Helper:
User-Agent: Mozilla/4.5 [en] (WinNT; I)
BuildID:    2000101014

navigator.appName peoperty should give the relevent browser name as netscape or 
IE or mozilla, but it is still giving as Netscape. regarding version if I use 
for N6 it is still giving as 5.0 . I accept that navigator.userAgent will give 
correct information on any browser, but why navigator.appName is not working. I 
wanted to know whether it is deprecated(if any)

Reproducible: Always
Steps to Reproduce:
1.alert(navigator.appName)
2.
3.

Actual Results:  it should show the name as mozilla 

Expected Results:  It is still showing as Netscape
Comment 1 Johnny Stenback (:jst, jst@mozilla.com) 2000-11-28 04:03:51 PST
This was debated on the mozilla newsgroups ages ago and it was decided that
navigator.appName should return 'Netscape' even in mozilla since if that were to
be changed every page out on the web that uses some browser sniffing code (and
that's a HUGE part of the current web) would need to recognize mozilla, and that
just won't happen and there's no reason to do that either since mozilla ==
netscape == mozilla as far as content developers are conserned.

Marking WONTFIX.
Comment 2 Fabian Guisset 2001-05-02 13:31:06 PDT
VERIFIED wontfix
Comment 3 Christopher Aillon (sabbatical, not receiving bugmail) 2002-01-14 13:19:29 PST
*** Bug 119949 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Versen [:Matti] 2002-02-21 10:38:12 PST
*** Bug 127020 has been marked as a duplicate of this bug. ***
Comment 5 Matthias Versen [:Matti] 2002-02-21 10:38:50 PST
*** Bug 117274 has been marked as a duplicate of this bug. ***
Comment 6 Adam Hauner 2002-02-21 23:01:21 PST
BTW should anybody update test on URL? Add bug number or change expected result?
(changing Plat and OS to All)
Comment 7 Gilles Durys 2002-04-05 14:14:32 PST
*** Bug 135790 has been marked as a duplicate of this bug. ***
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2002-04-13 18:36:03 PDT
*** Bug 136745 has been marked as a duplicate of this bug. ***
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2002-04-16 13:25:23 PDT
*** Bug 137732 has been marked as a duplicate of this bug. ***
Comment 10 Olivier Cahagne 2002-05-13 01:17:07 PDT
*** Bug 144064 has been marked as a duplicate of this bug. ***
Comment 11 Olivier Cahagne 2002-09-15 03:01:16 PDT
*** Bug 168768 has been marked as a duplicate of this bug. ***
Comment 12 Matthias Versen [:Matti] 2002-11-15 22:26:16 PST
*** Bug 180440 has been marked as a duplicate of this bug. ***
Comment 13 R.K.Aa. 2002-12-15 05:17:20 PST
*** Bug 185318 has been marked as a duplicate of this bug. ***
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2003-02-14 07:11:15 PST
*** Bug 193338 has been marked as a duplicate of this bug. ***
Comment 15 R.K.Aa. 2003-02-24 15:16:35 PST
*** Bug 194797 has been marked as a duplicate of this bug. ***
Comment 16 Will Budreau 2003-02-24 16:39:50 PST
Shouldn't this become an evangelism issue, then if websites are incorrectly
dating the browser software?

See bug 180440 comment 1
Comment 17 timeless 2003-02-24 20:15:28 PST
I've changed the test
Comment 18 Phil Schwartau 2003-04-30 11:49:42 PDT
*** Bug 203922 has been marked as a duplicate of this bug. ***
Comment 19 Nicholas Allen 2003-12-30 20:20:19 PST
*** Bug 229761 has been marked as a duplicate of this bug. ***
Comment 20 Hadrien Nilsson 2004-01-12 01:25:09 PST
comment #1:
« mozilla == netscape == mozilla as far as content developers are conserned »

We are in 2004, this is not true anymore. It is irrelevant to have Mozilla or
Firebird identifies itself as "Netscape".

This bug should be REOPENED.

Many web pages break because they think Mozilla == Netscape 4 !

Other browsers do not use the "Netscape" string and work fine. So why Mozilla or
Firebird should have this nonsense ?
Comment 21 Ben Basson 2004-02-02 06:24:55 PST
I think this should be reopened, part of Mozilla's ongoing branding should
involve seperation from Netscape. This is now a 4 year old bug, and IMO a 4 year
old reason for WONTFIXing it.
Comment 22 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-02-02 08:52:45 PST
While I understand the original motivations and the current motivations of the
Mozilla devs (per alanjstr in MozillaZine,
http://forums.mozillazine.org/viewtopic.php?t=44528&postdays=0&postorder=asc&start=0),
I agree with comment #20: Mozilla is NOT the same as Netscape. Netscape is dead
and gone; Mozilla is its own product now and should not masquerade as Netscape
anymore, IMO.

At the very least, could this be made a hidden about:config pref so that those
of us who don't want our Mozilla programs to be reported as Netscape can change it?
Comment 23 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-03-12 05:54:53 PST
Since it's apparent that this is not a bug, removing self from CC list.
Comment 24 Bill Mason 2004-05-28 19:40:57 PDT
*** Bug 245014 has been marked as a duplicate of this bug. ***
Comment 25 Oleg Sidletskiy 2004-06-30 22:45:39 PDT
*** Bug 249327 has been marked as a duplicate of this bug. ***
Comment 26 Daniel de Wildt 2004-09-21 04:19:14 PDT
I also think that this bug should be reopened

1) I agree as mentioned in comment 1 that there exists many browser sniffer
code. And many of them "thinks" that the user has a netscape browser which
supports "layer" tag. And many of those sites are unusable. A search in bugzilla
on open tech evangelism with the text "navigator.appName" in the comments
results in a list of 121 reported sites. And I think many of them will not work
with firefox or mozilla.
I think many of the sniffer code is used to serve propretiery HTML instead of
default or standard or what code ever. This will probably a reason for many
people to switch not to firefox (or mozilla).

2) Is netscape not brand name of a browser != firefox/mozilla?
Comment 27 Stefan Borggraefe 2004-10-14 03:55:12 PDT
*** Bug 264334 has been marked as a duplicate of this bug. ***
Comment 28 John G. Miller 2004-10-15 03:13:00 PDT
(In reply to comment #26)
I'd also like to add this thought to the proceedings.

Object property in question is the navigator.appName. To myself, this suggests 
that the Netscape (inc) developers got it wrong in the 1st place. Netscape was 
the company name. Navigator was the application name. I would accept Netscape 
Navigator as the full application name in the same manner as IE reporting 
Microsoft Internet Explorer via this property.

Since Netscape Inc. got it wrong should it not be corrected in this newer 
product which nolonger has any ties to the old company.

Or is Open Source reflected by closed minds ?

Note this is a personal opinion and not, in any way, indicative of the company 
that I work for.
Comment 29 José Jeria 2004-11-26 11:54:55 PST
*** Bug 271896 has been marked as a duplicate of this bug. ***
Comment 30 PikeUK 2005-03-04 14:17:05 PST
*** Bug 284795 has been marked as a duplicate of this bug. ***
Comment 31 Ben Basson 2005-04-01 07:36:54 PST
Keeping this for legacy scripts doesn't seem like it has any advantage to me.

Sites are still checking appName for "Netscape", but are version checking it
against higher versions than 5.0 (usually 7), so Mozilla is failing the checks
anyway.

This is confusing to end users who are told that their version of Netscape is
too old when they're using Firefox or Seamonkey. As I said above, this is now
over 4 years old, and so is the reason for keeping it closed.
Comment 32 José Jeria 2005-05-10 08:30:26 PDT
*** Bug 293629 has been marked as a duplicate of this bug. ***
Comment 33 Brian 'netdragon' Bober 2005-08-09 15:19:14 PDT
Reopening this since it's been 5 years since it was marked WONTFIX, and things
have changed significantly (comment #28 and comment #31) and we now have our own
name recognition. We should probably use "Mozilla" for appname on all variants
for simplicity and since Navigator returned "Netscape".
Comment 34 Dan Tobias 2005-08-09 16:17:16 PDT
It would still be kind of "one step behind" to change it to "Mozilla" now, just
as the release of any browser actually named "Mozilla" is being phased out (the
Mozilla Suite is becoming "SeaMonkey" and is not an official Mozilla Foundation
release).  Personally, I wish all browsers would use entirely honest user agent
strings and appName properties, and the meaningless "Mozilla/5.0" at the start
of the UA string were consigned to the ash heap of history in favor of strings
reflecting the particular actual browser ("Firefox/1.1", "SeaMonkey/1.0", etc.),
and the appName following accordingly... and screw the stupid webmasters who
sniff this and restrict access to sites for no good reason.
Comment 35 Ben Basson 2005-08-09 16:23:52 PDT
(In reply to comment #34)
> and screw the stupid webmasters who
> sniff this and restrict access to sites for no good reason.

As I said before, changing these values to realistically reflect the application
being used shouldn't really break any sites. Any browser detect scripts either
know to look for Firefox in the UA string or are simply looking for Netscape 7
(or even 6!)

Since neither Mozilla Suite, nor SeaMonkey, nor Firefox contain anything that
would allow them to pass such checks, most likely this will achieve more useful
messages for the end-user, for example:

"Mozilla is an unsupported browser."
instead of
"Your version of Netscape is too old!"
Comment 36 tyl2 2005-12-22 18:46:46 PST
Someone should change this bug's summary, say by adding the words "Remove" or "Stop reporting."
Comment 37 Doug Wright 2006-01-13 11:19:33 PST
Considering the huge swath of market share that Firefox has picked up in the last year, and the fact that even Netscape is "based on Firefox", it's about time this tie to the past was cut loose. If it were done early enough in a release cycle (i.e. alpha) and some press noise were made "helpful to web developers etc" impact would be minimised.
Comment 38 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-04-18 10:25:26 PDT
Not a blocker (not even clear what the proposed outcome is).
Comment 39 Tony Mechelynck [:tonymec] 2008-03-31 09:59:57 PDT
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033101 SeaMonkey/2.0a1pre

alert(navigator.appName)
        Netscape

alert(navigator.appVersion)
        5.0 (X11; en-US)

I'm not sure what "sensible" values would be (I guess either Gecko and 1.9pre or SeaMonkey and 2.0a1pre) but these ones sure aren't. I'm going to vote for this bug as soon as this comment gets "committed".
Comment 40 Matthias Versen [:Matti] 2009-08-01 22:17:43 PDT
*** Bug 507870 has been marked as a duplicate of this bug. ***
Comment 41 Gordon P. Hemsley [:GPHemsley] 2012-09-09 10:39:53 PDT
Is this still an issue?

* Is navigator.appName frozen as legacy "Netscape"?
** If not, what would the new value be? "Mozilla"? &appName;?
* Is navigator.appVersion frozen as legacy "5.0"?
** I notice that it includes the same parenthetical information as the UA string does, which suggests that it has not been as frozen as some might have thought. (For example, the language was removed from the UA string and navigator.appVersion in bug 572656, which resulted in issues like bug 602291.)

My take on the situation is that they should be frozen as-is for legacy reasons, and this bug marked as WONTFIX (again). There are better ways to get at the browser information, if that is indeed even the best approach for a situation.
Comment 42 Dan Tobias 2012-09-09 10:48:24 PDT
I'm opposed in principle to fossilized "legacy" stuff in user-agent identifiers.

http://webtips.dan.info/brand-x/useragent.html
Comment 43 Gordon P. Hemsley [:GPHemsley] 2012-09-09 11:14:21 PDT
(In reply to Dan Tobias from comment #42)
> I'm opposed in principle to fossilized "legacy" stuff in user-agent
> identifiers.
> 
> http://webtips.dan.info/brand-x/useragent.html

As that page suggests, the UA string is something that is still in active use and active change, gaining cruft as a consequence of that.

On the other hand, navigator.appName and navigator.appVersion have not been changed significantly since Netscape 5.0, which renders them as ineffective methods of identifying user agents. The difference here, then, is that the entire method of identification is negated, rather than only certain values of the method.

Rather than changing the values to something more modern, I am of the opinion (without any actual data to back me up) that things would be better off if navigator.appName and navigator.appVersion were removed altogether. Which is to saying nothing about the value of the status quo.

The status of this bug comes down to two questions:

(1) Do we do something to navigator.appName and navigator.appVersion?
(2) If so, what? Do we change their values? Or do we remove the methods altogether?

Without an affirmative response to (1), there is not much use for (2), and this bug should be marked WONTFIX.

If there is an affirmative response to (1), then further discussion and data gathering would have to take place in order to determine the answer to (2). And only then would an objection to legacy cruft in UA identifiers become relevant (because otherwise these methods are not really UA identifiers anymore).
Comment 44 Dan Tobias 2012-09-09 11:30:30 PDT
Do any standards documents mandate that these items be present, or what their values should be?
Comment 45 Gordon P. Hemsley [:GPHemsley] 2012-09-09 11:56:26 PDT
(In reply to Dan Tobias from comment #44)
> Do any standards documents mandate that these items be present, or what
> their values should be?

Actually, yes:

http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#the-navigator-object

According to that spec, navigator.appName must be either "Netscape" or the actual browser name and navigator.appVersion must be either "4.0" or the actual browser version. Presumably, the former values are for legacy implementations and the latter values are for modern implementations.

Based on our settings, though, we use the legacy value for navigator.appName and the "modern" value for navigator.appVersion.

However, our "modern" value for navigator.appVersion seems to take "Mozilla" as the version of the browser to represent in detail, as the string begins with "5.0" and continues with the basic platform information that is present in the UA string (e.g. X11 or Macintosh).

This violates the spec, as I read it, since we should either be displaying "4.0" or something like "17.0 (Macintosh)" (or "5.0 (Macintosh) Gecko/17.0 Firefox/17.0").

Trying to clarify now whether the intent of this section is to encourage active continued use of these methods. In the meantime, I suppose it's not appropriate to encourage WONTFIXing just yet.
Comment 46 Stewart Gordon 2012-09-09 12:33:40 PDT
What do you mean by "the former values are for legacy implementations"?  That if one day a new, HTML5 browser is made from the Netscape 4.x codebase, the properties shall take these values?
Comment 47 Gordon P. Hemsley [:GPHemsley] 2012-09-09 13:35:31 PDT
(In reply to Stewart Gordon from comment #46)
> What do you mean by "the former values are for legacy implementations"? 
> That if one day a new, HTML5 browser is made from the Netscape 4.x codebase,
> the properties shall take these values?

The HTML specification, in addition to documenting what browsers SHOULD do, also documents what browsers DO do. In this case, the spec recognizes that some browsers have to maintain legacy values for navigator.appName and navigator.appVersion for backwards-compatibility purposes. Thus, browsers who identify as "Netscape" and/or "4.0" for such purposes remain in compliance with the spec, despite using the legacy values.

It has nothing to do with somehow resurrecting the Netscape 4.x codebase and making it HTML5-compliant.
Comment 48 Stewart Gordon 2012-09-09 15:22:33 PDT
What are these backwards-compatibility purposes?  ISTM almost any website that relies on this is likely to be an abandoned site geared towards Netscape 4.x, and so it won't work anyway.

Indeed, for all I know there are probably more sites that use .appName to display something like "Your version of Netscape is too old!" than that use it to try and detect SeaMonkey, Firefox or any other Mozilla-family product.  On this basis, this glitch does more harm than good.

Moreover, this spec is stating that any old Tom, Dick or Harry could write a browser from scratch and choose to make it identify itself as Netscape 4.0, and it would be standards-compliant.  (Where are the pre-HTML5 DOM specs that cover navigator, for that matter?)

Part of the problem seems to be that, back in the day, we had only Netscape, IE and a few other browsers hardly anyone had heard of.  But each was an independent product - we didn't have differently branded browsers with the same code base.  So it might have worked back then as a way of determining browser for compatibility purposes, but it doesn't nowadays.  As such, I'm now inclined to think killing it is the way to go.  Trouble is that within the standards we can't just stop implementing it - W3C would have to deprecate it (indeed, should have by now), and then later remove it from the standard.
Comment 49 Hixie (not reading bugmail) 2012-09-10 18:07:53 PDT
IIRC, the intent of the spec is to allow browsers to return "true" values, or, if they want to return "anonymous" values, to do so by returning values that are vaguely known to be compatible enough with the Web.
Comment 50 Stewart Gordon 2012-09-10 23:26:21 PDT
So "Netscape" is a value that the standard allows so that browsers can remain anonymous if they wish, perhaps to fight against this abomination that is browser sniffing instead of writing portable/standards-compliant/gracefully degrading web pages.

Does it allow browsers to use anonymous user agent strings as well?  (I know Opera gives the user a choice of UA strings to identify itself honestly (well, almost) or pretend to be IE or Firefox, but are browsers allowed not to identify themselves at all by default?
Comment 51 Hixie (not reading bugmail) 2012-09-12 19:56:30 PDT
The HTML spec leaves the issue of the User-Agent header to the HTTP spec.

Note You need to log in before you can comment on or make changes to this bug.