Closed Bug 80658 Opened 19 years ago Closed 12 years ago

Site specific User-Agent

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 387416

People

(Reporter: basic, Assigned: jag+mozilla)

References

Details

(Whiteboard: parity-konqueror)

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.
Severity: normal → enhancement
Summary: Site specific User-Agent → [RFE] Site specific User-Agent
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

*** This bug has been marked as a duplicate of 46029 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
marking new
Assignee: asa → pchen
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
HJ, do you want this bug?
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.
Status: NEW → ASSIGNED
oh, this should go over to HJ [not assigned to pchen :) ].
Assignee: pchen → bugs4hj
Status: ASSIGNED → NEW
adding self to cc - thanks for the point-out basic :)
*** Bug 101990 has been marked as a duplicate of this bug. ***
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).
*** Bug 111144 has been marked as a duplicate of this bug. ***
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.
The work done here may be helpful: http://uabar.mozdev.org/
*** Bug 140417 has been marked as a duplicate of this bug. ***
Blocks: 71569
*** Bug 154645 has been marked as a duplicate of this bug. ***
this a dup of bug 22995
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.
Keywords: mozilla1.2
Blocks: 173892
Summary: [RFE] Site specific User-Agent → Site specific User-Agent
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?
Whiteboard: parity-konqueror
Blocks: 262663
Product: Core → Mozilla Application Suite
There are extensions that can do this so feel free to won't fix it.
Assignee: bugs4hj → jag
QA Contact: bugzilla
I think this should ideally be implemented in the way described in bug 387416, which a dynamic approach.
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".
(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.
Status: NEW → RESOLVED
Closed: 19 years ago12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 387416
You need to log in before you can comment on or make changes to this bug.