Closed Bug 61071 Opened 24 years ago Closed 2 years ago

Implement navigator.appName and navigator.appVersion according to the HTML spec

Categories

(Core :: DOM: Core & HTML, enhancement, P5)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: venur, Unassigned)

References

(
URL
)

Details

(Keywords: html5) 

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
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.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
VERIFIED wontfix
Status: RESOLVED → VERIFIED
*** Bug 119949 has been marked as a duplicate of this bug. ***
*** Bug 127020 has been marked as a duplicate of this bug. ***
*** Bug 117274 has been marked as a duplicate of this bug. ***
BTW should anybody update test on URL? Add bug number or change expected result?
(changing Plat and OS to All)
URL: http://mozilla.org/quality/ngdriver/s...
OS: Windows NT → All
Hardware: PC → All
*** Bug 135790 has been marked as a duplicate of this bug. ***
*** Bug 136745 has been marked as a duplicate of this bug. ***
*** Bug 137732 has been marked as a duplicate of this bug. ***
*** Bug 144064 has been marked as a duplicate of this bug. ***
*** Bug 168768 has been marked as a duplicate of this bug. ***
*** Bug 180440 has been marked as a duplicate of this bug. ***
*** Bug 185318 has been marked as a duplicate of this bug. ***
*** Bug 193338 has been marked as a duplicate of this bug. ***
*** Bug 194797 has been marked as a duplicate of this bug. ***
Shouldn't this become an evangelism issue, then if websites are incorrectly
dating the browser software?

See bug 180440 comment 1

I've changed the test
*** Bug 203922 has been marked as a duplicate of this bug. ***
*** Bug 229761 has been marked as a duplicate of this bug. ***
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 ?

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.
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?
Since it's apparent that this is not a bug, removing self from CC list.
*** Bug 245014 has been marked as a duplicate of this bug. ***
*** Bug 249327 has been marked as a duplicate of this bug. ***
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?
*** Bug 264334 has been marked as a duplicate of this bug. ***
(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.
*** Bug 271896 has been marked as a duplicate of this bug. ***
*** Bug 284795 has been marked as a duplicate of this bug. ***
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.
*** Bug 293629 has been marked as a duplicate of this bug. ***
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".
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
Assignee: jst → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: desale → ian
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.
(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!"
Someone should change this bug's summary, say by adding the words "Remove" or "Stop reporting."
Flags: blocking-aviary2?
Flags: blocking-aviary2? → blocking1.8.1?
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.
Not a blocker (not even clear what the proposed outcome is).
Flags: blocking1.8.1? → blocking1.8.1-
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".
Assignee: general → nobody
QA Contact: ian → general
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.
Whiteboard: [closeme WONTFIX 2012-10-09]
I'm opposed in principle to fossilized "legacy" stuff in user-agent identifiers.

http://webtips.dan.info/brand-x/useragent.html
(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).
Do any standards documents mandate that these items be present, or what their values should be?
(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.
URL: javascript:alert("navigator.appName="... → http://www.whatwg.org/specs/web-apps/...
Keywords: html5
Summary: navigator.appName and navigator.appVersion → Implement navigator.appName and navigator.appVersion according to the HTML spec
Whiteboard: [closeme WONTFIX 2012-10-09]
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?
(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.
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.
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.
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?
The HTML spec leaves the issue of the User-Agent header to the HTTP spec.
Bulk priority change, per :mdaly
Priority: P3 → P5
Severity: normal → S3
Severity: S3 → --
Status: NEW → RESOLVED
Type: defect → enhancement
Closed: 24 years ago → 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.