80658 - Site specific User-Agent

Status: RESOLVED DUPLICATE of bug 387416

(SeaMonkey :: UI Design, enhancement)

Description

[basic]

There are some sites that do not support Mozilla's default user agent. Currently
the solution is to change Mozilla's user agent to some other browser's. However
this causes other websites to see Mozilla as some other browser as well. It
would be nice to have site specific user agents. Where say, when visiting a site
with CGI and javascript that doesn't reconizes Mozilla, Mozilla will send a NS4
user agent, but will send the default user agent when visiting other websites.

Comment 1

[Boris Zbarsky [:bzbarsky]]

There is a proposed patch to make the mozilla user-agent easily pref-able. 
There is also a suggestion to make this a sidebar panel...

See bug 46029

Comment 2

[Asa Dotzler [:asa]]

*** This bug has been marked as a duplicate of 46029 ***

Comment 3

[basic]

My suggestion in this bug is to implement a site specific user-agent aka
Konqueror, bug 46029 only allows the user-agent to be changed via pref aka Opera.

Comment 4

[Matthias Versen [:Matti]]

marking new

Comment 5

[sairuh (rarely reading bugmail)]

HJ, do you want this bug?

Comment 6

[HJ]

Ok, my work on bug 46029 is a good start for sure, and some parts of it can be
re-used for this bug. I'm going to ask Steve Morse for his help and expertise,
because he's the one that developed the Cookies and Image manager. The UI part
of bug 46029 will be simplified, as proposed by Matthew Thomas.

Comment 7

[sairuh (rarely reading bugmail)]

oh, this should go over to HJ [not assigned to pchen :) ].

Comment 8

[Azrael AOD]

adding self to cc - thanks for the point-out basic :)

Comment 9

[James Green]

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

Comment 10

[Adam Hauner]

BTW look with Mozilla on http://www.msn.com/ 
I think, that this bug has now a little bigger importance (anyway is MSN.com one
of millions websites and MS is one of millions webpublishers).

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Neil Pryde]

I'm sorry to inform you that HJ won't be able to get to this stuff soon, because
of his 'WAT/9-11' assignment. Please change the "Assigned To" field, if you can,
to someone who's capable of actually working on this bug.

Thank you,
-Neil.

Comment 13

[Jarrod Gray]

The work done here may be helpful: http://uabar.mozdev.org/

Comment 14

[Hixie (not reading bugmail)]

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

Comment 15

[R.K.Aa.]

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

Comment 16

[R.K.Aa.]

this a dup of bug 22995

Comment 17

[Andrew Hagen]

Over a decade ago, DOS was widely used. Many DOS programs, including the widely
used Lotus 1-2-3, checked which version of DOS they were running on, and refused
to start unless the version of DOS matched their expectations. Old programs
refused to run on new versions of MS-DOS, even though there was no technical
problem in running them. This threatened to prevent widespread adoption of new
versions of MS-DOS, and was eating into Microsoft's bottom line.

In response, Microsoft introduced setver. Setver allowed users to trick Lotus
1-2-3 and other specific programs into running by telling them the system was
MS-DOS 2.1, 3.0, or another version. Yet, modern applications would still be
told the true version. It solved a lot of problems for a lot of users.
Eventually, thanks to setver, the bad old practice went away, users got new
applications, and setver was no longer needed. 

Today, web browsers, including Mozilla and its derivatives, are widely used.
Many web sites, including the widely used Passport from Microsoft, check which
version of web browser they are being loaded on, and refuse to load unless the
version of the web browser matches their expectations. Old web sites refuse to
run on new web browsers, even though there would be no technical problem. This
threatens to slow adoption of Mozilla and its derivatives.

Fixing this bug would address the situation. With it and a UI, Mozilla and its
derivatives could be made to work on all of the old web sites that are blocking us.

Comment 18

[basic]

Since filing this bug, years has passed and I think this bug is like a dead
horse now, I'm thinking closing it won't fix?

Comment 19

[HJ]

There are extensions that can do this so feel free to won't fix it.

Comment 20

[Robert Kaiser]

I think this should ideally be implemented in the way described in bug 387416, which a dynamic approach.

Comment 21

[Tony Mechelynck [:tonymec]]

In reply to comment #18, comment #19 and comment #20
- This bug (which is about automatic sitewise UA spoofing, the way Konqueror does it) is distinct from bug 387416 (for which a set of Tools menu entries, allowing _manual_ but fast UA changes, would IIUC be good enough).
- I could find extensions for bug 387416 but not for this one.
- IMHO, fixing this bug would be nice but low-priority. I move that we either resolve this WONTFIX (but only if an extension can be found which does it), or else leave it open, targeted to "Future".

Comment 22

[Robert Kaiser]

(In reply to comment #21)
> - This bug (which is about automatic sitewise UA spoofing, the way Konqueror
> does it) is distinct from bug 387416 (for which a set of Tools menu entries,
> allowing _manual_ but fast UA changes, would IIUC be good enough).

It's not. It's am integral part of what bug 387416 wants to achieve.