In Opera 4.0, there is a pref that gives you a choice of what your browser is reported as. For example, there is a "report as Netscape 4.72" a "report as Mozilla 5.0" and a "report as MSIE 5.0". Something similar would be nice for mozilla. Such as under the advanced tab, you have several checkboxes/radio buttons. Such as: Pretend to be Netscape 4.08 Pretend to be Netscape 4.7x Pretend to be for Windows Pretend to be for MacOS This would allow compatability with sites that are picky about your user_agent without the problems a fully customizble string would. Also, mabye this pref could be per site, since only some sites don't like Linux browsers, for instance.

enhancement request, however, very unlikely. Setting to nobody@mozilla.org until someone decides to help with this.

adding RFE to summary and setting status to New

This has some interesting possibilities and could help privacy issues out. CCing BenB.

This bug is about UI only. The backend is done - set something.useragent.override (don't remember the exact name) to your favorite UA-string and it will be used.

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

This will also aid web developers who want to test their backend code against various Browsers... Of course for that to be fully realised we would need to support the bugs of other browsers but that's probably never likely to happen. It would still be cool to see the content a website would spit out when seeing a browser of IE5.0 though. This will also elleviate problems with websites reporting "This site must be viewed in IE5.5 only" and similar dumbness. Adding self to CC.

I'm considering doing this myself, providing I can figure out how to do it (first time I've looked at moz's code). Here's my idea for the UI anyway: In Prefs->Advanced, add a page "Identification" with the content along the lines of: Browser Select: ( ) Mozilla (*) Microsoft Internet Explorer ( ) Netscape Navigator ( ) Opera ( ) Konqueror (KDE 2.0+) ( ) Lynx ( ) Other... [ text input ] Currently using: << User Agent String >> Your above selection: << User Agent String >> It may also be wise to include an option: [*] Display User Agent in Taskbar AFAIK, what needs to be done: - above preferences page - Javascript to set the UA on clicking OK - Some form of hook to save the preference. I'll look into how other prefs work, minefield as it is, and see if it's something I can do. In the meantime, if anyone can give advice, pointers, constructive criticism, shout.

do you need to allow people to pick versions, eg opera3.2 or opera4 or opera5?

How about: Netscape 4 ( ) 5 ( ) 6 ( ) IE 3 ( ) 4 ( ) 5 ( ) Opera 3 ( ) 4 ( ) 5 ( ) Konqueror ( ) Lynx ( ) Mozilla ( ) Change to: (........)

doesn't get me 3.2 ... radio buttons won't work for selecting versions, you'll probably need a list or tree list.

I thought about this over the past couple days. The UI depends on what functionality we want to offer: - Choose OS - Choose Browser Vendor/Name - Choose Browser version Each option depends on the choices above it. A matrix can be formed to provide OS->Browser->Version information. This would have to be done in Javascript. My thinking is to provide something along the lines of: ( ) Mozilla Native (<< Normal User Agent String Here >>). (*) Select from choice below. Upon selecting the second option, the following becomes active: Select Operating System: [ Pull down list of OSes ] Once an OS is chosen, an list of available Browsers becomes active underneath: Select Browser Vendor/Name: [ list of available browsers for this os ] Once the Browser has been selected, a final list of version numbers becomes available: Select Browser Version: [ drop-down list of versions available ] Thus to choose Internet Explorer 5.5 on Windows NT4 the screen would be set up as follows: ( ) Mozilla Native (<< User Agent String >>). (*) Select from choice below. Select Operating System: [Windows NT 4] Select Browser Vendor/Name: [Microsoft Internet Explorer] Select Browser Version: [5.5] Wherever we are unable to choose something, it is greyed out. This if from the above selections the Vendor/Name was changed to say "Netscape Communicator" the "Select Browser Version" drop-down would change it's selection to be blank, prompting the user to select the version number ([4.00][4.01], etc.). If you choose Linux as OS, of course the Browser Vendor/Name would also change to blank, prompting for a new selection. This would require a fair bit of Javascript, which I would have to learn, but it would be a good excercise. I would also need to find out how to make the strings involved in the Javascript data localisable. This particular setup would allow us to list OSes for mobile phones which use WAP, or for mobile computing such as handhelds, although I suggest that we concentrate on desktop PC browsers first, and simply add to the matrix to include OS/Browser/Version information for other devices later. CC mpt and german for discussion.

I'm not a fan of this bug. IMO, this is very deep tweak. In fact, you *fool* the server; you pretend sometime you are not. I can't see much value of this, considering that Mozilla is a mojor browser (unlike Opera). I havn't found many sites blocking Mozilla at all, and those that did usually used dumb JavaScript, not the UA-string. I am very much in favor of allowing this as a tweak (which can currently only be accessed via modifying prefs.js/user.js), actually I implemented the backend pref myself. But IMO, this is nothing we should have in our usual preferences UI. *If* you do offer UI, I suggest a textfield with history with some prefilled values (UA-strings of common browsers/OSes). That way, the user fake any browser. But note that you can screw things up completely by doing so (some servers won't serv useful content, if you deliver garbage as UA-string).

Sorry, I meant to include the textfield for custom string in the proposal. Consider the following line right above the "Select from list below" option: ( ) Custom: [ text entry area ]

FYI: I meant *only* that textfield with history (plus maybe one checkbox for 'normal Mozilla string').

I agree with Ben this shouldn't be in UI prefs for regular users at all. Certainly not suitable for the 80-90% case Netscape customers. Kind of ironic: MSIE has used a Mozilla UA string for the longest time since its market share used to be lower then Netscape's. Are we now forced to emulate that emulated string in turn for Mozilla/Netscape, so we can get into sites designed for IE?

OK, I can accept arguments that it shouldn't be in the main Prefs block, even under "Advanced". So for the minority of people who *do* want to be "seen" as another client by a webserver for whatever reason, where do we provide a UI? I'm certainly not happy to make users find out about the prefs file and modify it themselves, that's begging for trouble. It should be noted that some sites provide differing content dependant on the browser id. For instance, a site may provide a basic stylesheet for Nav4.x, an MS-centric one for MS browsers < 5.5, and a W3C-centric one for Mozilla and perhaps other browsers. We are not talking about whether that should happen, but providing a UI to the mechanism allowing for testing of sites in mozilla parading as Nav4.x/other. I also argue against having only a textentry box plus history. People who want to change ID cannot be expected to know what to put into that box, be it "Internet Explorer 5.5" or "WinNT4/Internet Explorer 5.005" or something else. Having a range of plain English options that the user will immedaitely recognise that the application can translate into browse ID is infinitely more sane.

> So for the minority of people who *do* want to be "seen" as > another client by a webserver for whatever reason, > where do we provide a UI? I suggest we don't especially if it comes at the cost of making the simple 90% things harder to find.

you could stick it in Debug, which won't ship w/ netscape *, or if ben comes down against it, you can always release a package that overlays the prefences pane.

I think some direction is lost here. Changing the user agent isn't just a 'we're a minority browser.. but let us in anyway' idea. It's down to user choice. Some times give different content. Let _us_ choose. Some sites monitor your browser type.. let _us_ choose what data we give. I agree.. this maybe not for 80-90% of Netscape users. But I requested this (via a dupe) not to netscape.. but to Mozilla.. and I know _this_ user wants it. Where it is.. don't care. If people are happier with it in debug.. put it there! Seems to me this is a very simple thing (for those that know how.. then again what isn't.) so how about a patch is knocked up and then we argue about where to put it exactly?

> So for the minority of people who *do* want to be "seen" as another client by > a webserver for whatever reason, where do we provide a UI? Bug 17199. > People who want > to change ID cannot be expected to know what to put into that box, be it > "Internet Explorer 5.5" or "WinNT4/Internet Explorer 5.005" or something else. > Having a range of plain English options that the user will immedaitely > recognise that the application can translate into browse ID is infinitely > more sane. Do you count "Mozilla 4.76 [en] (WindowsNT 5.0; U)" as "plain english" (human language)? If so, this is *exactly* what I suggested with the "prefilled values". > Mozilla.. and I know _this_ user wants it. There is no (legitimate) Mozilla end-user.

Tell me the exact name of that pref setting and I will do this within 15 minutes for you!

For reference, from bug 69025: >>>>> ------- Additional Comments From Boris Zbarsky 2001-02-16 11:38 ------- http://mozilla.org/unix/customizing.html under "useful preferences" lists: // Override the default user-agent string: user_pref("general.useragent.override", "Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5"); <<<<< Ben, anyone who chooses to use Mozilla as a web browser and not to develop it is im my opinion an end-user of the product. Since we do not know how many there are out there, we have to rely on feedback for what people want. In this case there is a minority of demand and the reasons for wanting it are themselves edge-cases. Opera has implemented the basics of what we are asking for. I would like to know the demand Opera saw for including it in their product, so I could email them and post any response here I guess. Timeless: slapping it in debug and thus not having it in Netscape 6 would almost defeat the objective here. Of course, Netscape can do what they like in their product, but if demand exists within the Mozilla community it may also exist within Netscape's clientel. Personally, I prefer the idea of including this with the tree control prefs to alter all possible preferences aka bug 17199. H-J: we appreciate the enthusiasm but it would take 15 minutes just to make the front-end XUL. At least, with my idea you would need to build up the various UA strings the browsers used, and build the UI content based on that. I recommend we defer this bug to the full prefs UI in bug 17199.

Additions come at a cost: they make the product appear more complicated to use and they clutter the already crowded prefs. The aformentioned 80% case has no idea what a user-agent is, why they would want to change it and don't understand why websites may behave differently when emulating a different agent (and how to reset it). To me these cost weigh more then the added benefit for a very small number of netscape users. They are nowhere near as technically interested as the average mozilla contributor.

I had to implement this already for on-line banking. The reason is that some banks don't allow you to use Mozilla5/Netscape6. This because of the password manager, that's to insecure they say. The way it works now is very easy but lacks real power. I will change it to support: ---------------------------- 1 - OS Selection (radiogroup) 2 - Platform Selection (radiogroup ) 3 - Vendor Name Selection (radiogroup) 4 - Major Version # selection (list) 5 - Minor Version # selection (list) Just tell me your options and I will put them in.

german, an pref setting will enable/disable this option! The default setting is 'off' but if you _need_ it, you _can_ switch it on to support an optional UA string. Interactive help files can help people to learn to understand what an UA string is, like the one for privacy already does.

1 - OS Selection should be list 2 - Platform Selection should be list 3 - Vendor Name Selection should be list 4 - Major Version # selection (list) 5 - Minor Version # selection (list) probably should be combobox (like the urlbar w/ its completion menu).

Hmm.. a name for this preference... 'browser identity' or 'user agent' ?? To try not to put of 'simple' users.. perhaps putting this under an 'Advanced' tab. Maybe I speak for myself.. but I like programs that have some options I can hope to one day learn about... I don't like programs that have _nothing_ new to offer me after I use them for a very short time. I think a few advanced preferences will only add depth and complete quality to a product.

Azrael, please don't get into a general discussion, if many prefs are good or bad. We discussed that on .prefs already, feel free to followup there. H-J, if you implement this, you risk a rejection by the module owner. Just to warn you...

Ben, thanks for the warning, I really appreciate it, but we need this really hard, and a.s.a.p. Nice guess Azrael 'Browser Identification' it is. And Timeless your right, list is what we need, I did that for those items. But still need to figure out some lame settings. I'm about to add: ----------------- [o] Restore default settings (quick restore, so no stress). [o] Disable this feature (write false in the pref file). I can use my bank without switching browsers :))

> (write false in the pref file) An empty string disables the override, i.e. uses the native Mozilla string.

[o] Restore default settings (quick restore, so no stress). [o] Disable this feature (write false in the pref file). radio button: ( ) use correct user agent /Mozilla .../ ie, place the correct user agent string in italics (or something which will default to italics if someone objects to <i>) afterthe words 'user correct user agent'

H-J: bear in mind that these lists must be Javascript controlled, the content of each generated based on a matrix. Otherwise you risk people selecting Linux->Internet Explorer->5.3 which of course doesn't exist. Also the two settings for original string and disabling of the feaure should be merged, they do after all mean the same thing. I suggest: ( ) Default. Mozilla normal mode. (*) Specify: [ list of os/browser follow ] Please also have a changing text display showing what the currently selected browser user agent string will be. I'm now writing to the opera-linux mailing list to try to gauge some sort of demand for the feature and ask the staff the original reasons/intentions for the option being put in.

>> Otherwise you risk people selecting Linux->Internet Explorer->5.3 which of >> course doesn't exist. *grins* But what if someone wants to do that? Do we disallow it full stop? Or advise against it somehow?

timeless adds (in my words): Since some users might have an interest/reason to switch the UA several times per session, it might be a solution to implement this as overlay and provide as additional, optinal download, i.e. an XPI file for interested parties to install.

I just inserted an textfield. This for editing by hand, to whatever you like. The default UA string is _always_ visible and you can't edit it. This treeitem is called 'Browser Identity' and will only be visual if, and only if, when pref("enablebrowserIdentity", true) is in your pref file. You can change this 'on the fly', there's no need to end your session, restart the browser and so on. Just go to this setting and pick whatever you like. James, the 'disable feature' radio button is implemented so that you don't have to edit the preference file by hand, if you like to disarm this functionality. Azrael, what about an 'check for vality' button ?

A validity button.. hmm.. would be hard to maintain this.. as changes would be made all the time... perhaps only allow them to select current valid ones... but the user_agent strings of these are visible.. and so if they type in their own one they can mix and match.. and will be aware they could mess it up, or do soemthing weird.

Some screenshots. arrrg screentshots (typo). I'm in urgent need of some help. I need useragent information for: Windows 95/98/Me/Mac/BeOS/Solaris and Linux! Question, how do I get this text to wrap if there's no space left?? example: <text value="some extra long line of text that needs to wrap"> note: <html>blablabla</html> has the same problem!

Screenshots.. one word.. SEXY :)

H-J bugzilla source includes that stuff http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/enter_bug.cgi#193 fwiw, please use MSIE or Internet Explorer, not MS Explorer (that's a different animal). Please replace Modus w/ Mode for en-US if possible, could you please have state 1-2 display the current useragent? state 3 should have OS and Version instead of OS and Mozilla. just as temporary fields. thanks for working on this.

CC Endico - can you grab mozilla.org logs of browsers visiting and help build a list of browser vendor->platform->version UA strings please? I'm pretty sure there must be a webpage with these somewhere... H-J well done on this. We must make sure we can only select from the drop-downs valid browsers, i.e. you cannot select MSIE on Linux no matter which version you choose, Opera 3 doesn't exist on Linux, but Opera 4/5 does, etc. Also, can you change this bug so you have Accepted it please. All: I have received several (5-10) replies from the opera-linux mailing list (it's low traffic) and all of them say they want this feature, mostly because sites are checking the UA string and if it doesn't say MSIE or Netscape 4, you need to upgrade. This is apparently a major problem with online banks. UI keyword added.

James Green, see <http://www.browserwatch.com> H-J, I am confused about the UI. I have no idea how it would work from looking at it. E.g. What's this "Disable..." checkbox? Why the "Override..." box? This "Enable Expert..." is unnecessary.

<!-- something awesome --> Computer time was limited this weekend. I drove off to Germany, in my brand new blue XKR Coupe (Jaguar) to burn some of my 285/30 20 inch Pirelli P Zero's. Hihi, this baby is limited to 155 miles, but at 150 miles you simply gear down to pull trough the barrier and gear up to reach 170 miles. Sorry guys had to tell you this, I feel like reborn in my blue XKR coupe. <!-- off topic end --> First off all, that text align stuff is a well known XUL bug so don't matter. Azrael, remember I have seen the light (XUL) only two week ago but they say: "H-J is a fast student" I hope that's true. Timeless, I wish we where :) and yes it is. If you have the time, can you help me with one issue? I have added this: <?xul-overlay href="chrome://communicator/content/pref/browserIdentityOverlay.xul"?> to preftree.xul but like to add this to the .rdf file. What do I need to do to make this work as rdf overlay? James, what do I need to do to accept this bug? And do you have InfoZip up and running? Ben, I took a look at that site, but I must be stupid because I didn't find useragent info (: Do you have an direction? And I know, you just need to use and then, we can always change things, if it's really necessary. What versions do we support? And for what platforms? Please help/advise!

<http://browserwatch.internet.com/stats.html>, especially <http://browserwatch.internet.com/stats/ua-1.html> and <http://browserwatch.internet.com/stats/ua-2.html>.

Visited the above url's and made a list of the user agents without the frequency/percentage numbers etc. A pure text file of user agents strings. A deleted a few obviously stupid ones, quite alot probably remain.. some are fragmented.. but that's how they were on the site. Just thought it might be helpful and save effort...

Note that some seem bogus, at least the Mozilla/4/5 ones. Mozilla has a much longer string. Looking into a raw access_log file might indeed be better. If someone can provide me with a (Unix) script that extracts only the user-agents, I can run that over my logs.

H-J: you see that button right under "New" named "Accept bug"? Heh, try that :) I suggest a initial listing of standard web browsers such as Internet Explorer, Netscape Navigator (<=3.x, possibly include 4.x and refer to it as Communicator?), Netscape 6, and Opera. Of course, keep the Mozilla standard UA as an always available option. Once those work we can add Konqueror and more. I'd lay off including browsers for WAP devices until we know we can handle WML and XML properly :). The priority should be to get the small list of browsers working, and that requires data of browser/version/os. Oherwise we could let users select Opera 3 on Linux, which shouldn't be possible.

>> Oherwise we could let users select Opera 3 >> on Linux, which shouldn't be possible. Umm.. the whole point is to select a user agent that does not represent the truth. So I don't think that much fuss should be made about _not_ allowing people to have 'wrong' combinations. Plus it makes it more complicated to try and second guess the users choice. Let them select anything and if it isn't a real-world choice.. who cares?

>H-J: you see that button right under "New" named "Accept bug"? Heh, try that :) If you take a look at 'Assigned to:' you see my name, so why should I do this as it seems that someone else already did for me :)

Stupid me, didn't see that, sorry people...

Holy crap, are you kidding me? Lets attach some patches, i'm dying to try this out!

I'm about to start the count down. I had to fix 21 bugs in total. But now i only need to fix 10 more bugs, after inserting that new menulist. Two of them are high prio bugs and two have a low prio state. Six other bugs will be fixed early next week. I asked Neil to review/test the stuff to speed things up a bit. Localization is fine, except for brand names like Opera/Windows/Linux. Do i need to add them to 'pref-identity.properties'? I sure hope not! else 10/4

BTW, one of the low-prio bugs is about the color of the submenus. I need to locate the class name in order to preserve the colors! Can you help me with this one? Or else, i need to dig into the moz source (menulist code).

That color thing seems to be a general problem with <menu> inside <menulists>. Mailnews has the same problem in their "Copies and Folders" preferences in the dropdowns... I've filed bug 72440 on that and attached a patch to it.

Woohoo, one down, thanks to Boris! His patch does indeed solve this problem! Thanks a million Boris :))

Who is willing to help me with the text for the tutorial (More information button). You will be the first to receive a Beta version of this stuff, that's the least i can do in return! BTW 3 more bugs fixed. Poking around in the source helps solving the next high-prio bug and this one will automatically solve two other low-prio bugs.

Found seven bugs, will send report privately later this night.

Hey Neil, I'm still waiting for your 'report'!? Please send it a.s.a.p. because i have a new assignment in Spain starting march 22!

HJ, what is your e-mail address I lost it, sorry (: Here are the bugs i found: 1 - Gecko/ tag is always attached to the prefString. 2 - Netscape6/6.0 tag is always attached to the prefString. 3 - ')en-US' is missing a space. 4 - update menu after selecting OS/Browser. 5 - 'Default' in menu 'Stored' is always checked. 6 - Opera incorrectly displays 'en-US' but that should be '[en]' i think. 7 - all selections for MSIE display 'null' in the specString. 8 - the version menulist always displays Mozilla 5.0 for Mozilla and Netscape 5.0 for Netscape after first startup. note: why don't you use 'Netscape 6.0' in the menu? I think that Netscape 5.0 is more clear to the end-user. I hope you find the time to fix them, before going to spain!?

Shoot, Netscape 5.0 should read Netscape 6.0. sorry for the SPAAAAAAMMMMMMMMM

Thanks for testing Neil. I will try to fix them a.s.a.p!

1,2,3,5,8a and 8b are fixed. 6 - Do you think that's a real problem? Lett me know ok! 4&7 - that are two are real big problems. May the force be with me, hope to fix them today! I need to add platform conditions for it.

Filename: hj-1.jar (made with Info-ZIP's Wiz version 5.02) comm.jar -------- content\communicator\pref\browserIdentityOverlay.xul content\communicator\pref\pref-identity.js content\communicator\pref\pref-identity.xul content\communicator\pref\pref-identityOverlay.xul content\communicator\pref\preftree.xul content\communicator\pref\pref-useragent.xul en-US.jar --------- locale\en-US\communicator\pref\pref-identity.dtd locale\en-US\communicator\pref\pref-identity.properties locale\en-US\communicator\pref\preftree.dtd All files are new, except this two: content\communicator\pref\preftree.xul added: Henk-Johan van Rantwijk <bugs4hj@netscape.net> added: <?xul-overlay href="chrome://communicator/content/pref/browserIdentityOverlay.xul"?> locale\en-US\communicator\pref\preftree.dtd added: <!ENTITY identity.label "Browser Identity"> Add this to your prefs.js: user_pref("useragentoverride.enabled", true); You might see something like this after startup: ------------------------------------------------ user_pref("general.useragent.custom-0", "This with your default useragent information"); user_pref("general.useragent.custom-1", ""); user_pref("general.useragent.custom-2", ""); user_pref("general.useragent.custom-3", ""); user_pref("general.useragent.override", "Mozilla/4.0 (compatible; MSIE 5.01; MacOS)"); You might notice the spoofed useragent here: MSIE 5.01 on a Macintosh !

If you have question, just let me know!

Hm, 'question,' in my last comment should be 'questions'. And my 'replace with' in my editor didn't go the way it had to. So please change this two lines in pref-identity.js: var xul_true = true true should be changed in "true" var xul_false = false false should be changed in "false" if you don't you might see small bugs. Sorry that i didn't see that before. I will also add the missing .html file for the 'More information' button because i forgot to include that file (thanks Neil)! In the pref-identity.xul you see validon="012345678". This are numbers corresponding with the typeOS array. 0=BeOS 1=Linux 2=MacOS 3=OS/2 4=Solaris 5=WinNT 6=Windows 7=Win9x 8=Windows NT. Default all browsers will run on all platforms (but that is wrong). Opera 3.5 should not run on Linux. After changing validon="012345678" in validon="02345678" the menuitem for Opera 3.5 will be 'disabled' for Linux. This way we can define the supported platforms for browsers (I sure hope it works James). I don't know what browser runs on what platform, so please help me with this. Last note: i'm going to Spain on march 27 and not on march 22. So if you testrun it and find bugs, please let me know as soon as possible. Happy testing.

note: I've done a reformat on 80 characters. Also changed the xul-source to support the new XUL standards (that value/label/title stuff). Fixed that two type's and included the missing identity.html file (now renamed to pref-identity.html). so please don't do that yourself! Can't install those .xpi files to update to the latest build for WinNT, keep getting those funny file extensions! Will try later.

In the first release you had to insert some specific settings in pref.js before you could start using this feature. But can you add settings, if you don't know what to put where and what syntax to use? I don't. So the great news now is that you no longer have to insert them by hand because the source will do that automatically for you at first start. The only thing you still need to do by hand is to enable this feature in prefs.js because the default value is false. user_pref("useragentoverride.enabled", false); this setting disables this feature user_pref("useragentoverride.enabled", true); and this setting enables this feature. The latter would be the correct one to enable it. BTW: If you all like to change this, just say so because we can easily change the default to true, but I don't think we should do so. Other settings in pref.js are: -------------------------------------------- user_pref("general.useragent.custom-0", "Mozilla/5.0 (Windows; U; WinNT5.1; en-US; 0.8.1) Gecko/20010323"); user_pref("general.useragent.custom-1", ""); user_pref("general.useragent.custom-2", ""); user_pref("general.useragent.custom-3", ""); user_pref("general.useragent.override", ""); -------------------------------------------- As you can see there are five custom and one override settings in pref.js. .custom-0 stores the default useragent as backup .custom-1 stores the first override useragent .custom-2 stores the second override useragent .custom-3 stores the third override useragent .override stores the new build-up useragent I also solved some minor problems introduced after i replaced value with label. I hope to finish my work today, so all of you can start using it with the latest builds. to do 1: add type="checkbox" to the menuitems (missing checked sign). to do 2: the useragent should always be displayed (missing at first start). to do 3: select the used OS from the system (now only visual after selecting an OS)

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

I'm back and will attach a zipfile this weekend, right after the final test with the latest build. If the submenu colors are working (#72440) we then only have to wait for (#72157) to be fixed, but i'm not sure about (#73011) if that's working at this moment!?

Both (#72440) and (#73313) are fixed. And i'm about to kill that cosmetic (#73011) It seems that i'm the bug creator hihi.

Extract the files and put the extracted files in the corresponding jar files. Make sure to enable it after the first run (see comment 2001-03-24 05:07).

H-J, could you attach a diff against the source tree, including whatever changes need to happen to various jar.mn files?

Wow, it looks like this bug has been taken over by a million monkeys with typewriters since I last saw it. With all the useless commentage, I'm almost tempted to file a new bug and start again ... Now then. *If* this feature makes it into Mozilla (and personally I would like it to, though what I would like doesn't count for much), then the UI will need to be as simple and unobtrusive as possible -- which means it needs to consist of *one popup menu*. That's all. Not an entire prefs panel, with sets of saved strings, independent choice of browser and OS, four popup menus, two radio buttons, two checkboxes, one push button, and a partridge in a pear tree. Just *one* popup menu. Sorry. Now, how do you do it with just one popup menu? Simple. Like this: Navigator identifies itself as: [ MSIE 5.5 for Windows ME :^] When you open that popup menu, it looks like this: +-----------------------------------------+ | Mozilla 0.9.2 for Mac OS (recommended) | |-----------------------------------------| | iCab pre2.8 for Mac OS | | Mozilla 0.9.2 for Linux x86 | | Mozilla 0.9.2 for Windows 2000 | | MSIE 5.0 for Mac OS | | MSIE 5.0 for Windows 98 | Navigator identifies itself as: |* MSIE 5.5 for Windows ME |^] | Netscape Communicator 4.77 for Mac OS | |::Netscape:6.01:for:Mac:OS::::::::,::::::| |----------------------------------|\-----| | Other ... \ | +-----------------------------------------+ Now, what I've shown is obviously what the preset list is going to look like for someone using Mozilla 0.9.2 on Mac OS. For other platforms, the preset list is going to be different, biased more towards the browsers which are available on those platforms. Keep the preset list *short* -- 12 items as an absolute maximum. Choosing `Other ...' opens a dialog which looks like this: +---------------------------------------------------------+ | Navigator Identification :::::::::::::::::::::::::::::::| +---------------------------------------------------------+ | Send this _User-Agent string to Web servers: | | [Mozilla/5.0 (Windows; U; Windows ME; en-US: Internet ] | | ( Set to _Default ) | | | | /!\ Pretending to be a browser other than Mozilla 0.9.2 | | may cause some Web sites to behave unexpectedly. | | | | ( Cancel ) (( OK )) | +---------------------------------------------------------+ If the back-end pref doesn't do it already, don't forget to change what JS reports the browser to be, as well as what the browser sends for HTTP. iCab has a separate pref for each, which is a bad idea -- people who pretend to be another browser, so as to do online banking, are frequently tripped up by the fact that they set one pref but forgot to set the other. And finally, H-J, here's some UI tips for future reference: * In English, there is no such thing as a `modus'. * Warning! If you use exclamation marks in UI text, there's something wrong with your design! * If you have popup menus which contain submenus, there's almost certainly something *very* wrong with your design. Submenus belong in pulldown menus, not popup menus. * Bugzilla is not a chat room. * Don't use checkboxes for turning things off (`Disable Browser Identity settings'), use them for turning things on. * If you have status to report, use the status whiteboard. That's what it's there for. Don't spam the `Additional Comments' field. Keep up the good work ...

mpt: keep your specs out of this bug, a developer is offering a package and it's up to the module owner to decide whether it will be accepted.

Thanks Matthew, but if you read all the *useless* comments, you will see that this is, in a way, something people like. And I'm sorry to see you join us *Monkeys* so late, but as we all can see, your typewriter does work very well indeed. But, and now without joking, you did name some issues i changed already, or working on at this moment. 1 - changed 'Modus' into 'Mode' Sorry, I must have overwritten that .dtd. 2 - removed the exclamation marks. Yes that's better. 3 - about submenus in menulists. I'm not the first, and certainly not the last person to use them. See also bug (#72440 fixed) and (#74508). 4 - chat room?? You must have a very slow Internet connection :)) 5 - i can change that checkbox into a radio button, for example, if you like? Or mark that checkbox by default. You then need to uncheck it to disable this feature. Or should i remove it completely, what do you all think? 6 - status white board aha, i will start using it, whenever possible, still learning. Matthew, 1 - don't you like to see some sort of help for this feature? Remember, this is a deep tweak. So we certainly need that push button. But i personally think that any feature without help, is harder to use for some people. 2 - don't you like to be able to store/save an custom build user agent, so you can use it over and over again? Remember if this is unavailable, you need to buildup the user agent time after time! 3 - and what if i put those submenus for browser versions into the main menulist? That will be a huge, but not impossible change, i think/hope! But i need to investigate this, before making any work of it.

HJ, first off all great work. I do like the store menu but can't find that help file. Is this file missing? And please do not change the menulists i'm used to it already. >> Now, what I've shown is obviously what the preset list is going to look like >> for someone using Mozilla 0.9.2 on Mac OS. You must *obviously* be joking because that won't work at all.

Hey, read what I said: `If this feature makes it into Mozilla (and personally *I would like it to* ...)' [emphasis added]. I would love this feature. I think it would be cool, because it would increase the user's control over malicious/stupid Web sites. But I'm as certain as I can be (without being able to read Blake's or Ben's mind) that this feature is never going to make it into Mozilla if the UI remains anything like it is now, or if it has any UI which takes up a whole prefs panel. It would be rejected on usability grounds. > 3 - about submenus in menulists. I'm not the first, and certainly not the > last person to use them. Yes, I apologize for not having filed a bug to get rid of those awkward submenus before you decided to copy their design. It's not your fault. > 2 - don't you like to be able to store/save an custom build user agent, so > you can use it over and over again? I don't see the point. If you need to use this feature at all, it's almost certainly because a site is trying to restrict access to certain well-known browsers. Those certain well-known browsers, we put in the preset list. There's practically no need to remember multiple other strings, so the usefulness-to-clutter ratio is too low to include that feature. > > Now, what I've shown is obviously what the preset list is going to look > > like for someone using Mozilla 0.9.2 on Mac OS. > > You must *obviously* be joking because that won't work at all. Um, you might think that Mozilla 0.9.2 for Mac OS won't work at all when it is released, but I trust Asa more than that.

Yes Neil, i didn't write one at this moment, sorry. Matthew, it was fun to do this and i have learned a lot. So i really don't care to change or even completely rewrite this feature. But let us please define the specs *before* we start doing it all over again Ok.

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

HJ, please e-mail me and we will start paying you for your work. Even some minor bugs don't stop us from using it, but please fix them. 1 - 'Gecko/builddate' is always added to the useragent. 2 - 'userAgentOS' is null after first start and then selecting a browser. 3 - platform is always the default one (Windows and Linux for our users). 4 - it does not remember the new button state, after first start.

Bugs 1,2,3 have been fixed. For bug 4 is a work around. Select a OS or browser and it will remember the button state (this problem is seen at the first start only). Work around mentioned by kin@netscape.net implemented for expert mode (so we don't have to wait for bug #72157 to be fixed).

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

Please visit http://members.v3space.com/4you2/mozilla/identity/identity.html for the latest screenshots.

please use Windows 2000, and Windows XP instead of NT 5.0 and NT 5.1, NT5/5.1 have no meaning to end users. Similarly don't use Windows 4.10, or Windows 4.90, use Windows 98 and Windows Me

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

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

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

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

I'm not sure the status of this currently, but as an Opera user, I thought I'd add some commments. One thing that Opera does, regardless of the user agent, is stick the word Opera in the user agent string, usually outside the parentheses, i.e. Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 5.02 [en] is the spoofing string for MSIE 5 in Opera 5.02 on Windows 98. This is done so that Opera can always be identified, even when spoofing. Most JavaScript sniffers aren't intelligent enough to look specifically for Opera when spoofing (one reason why so few stat sites show true statistics for the number of Opera users) and then serve content specifically for the browser being spoofed. This can cause problems, however, when proprietary JavaScript is served. That's one of the reasons why Opera chose to support some IE-proprietary JavaScript methods, specifically 'document.all.' Thus, using a spoof may cause problems with JavaScript (spoofing Netscape 4.x may get document.layers, spoofing IE may get document.all, both of which won't work in Mozilla). Putting in the Opera identifier can help avoid this for intelligent webmasters. There are cries for an exactly matched spoof string (I believe this is your method), though, because some sites are smart enough to find Opera when spoofing and then block it. I'm actually disappointed that such a patch is being made for Mozilla. I'd much rather see the time go into informing webmasters that they need to update their code for standards compliance, rather than tricking them into thinking they're not getting hits from Mozilla. There is no reason why Mozilla should not be allowed into any web site, period. Netscape / Mozilla have an opportunity to push for standards compliance, but instead you plan on spoofing archaic browsers? I don't get it. Adding CC to me.

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

Markinh mostfreq at 10 dups.

I just posted a page with detailed correspondences I've had with my bank regarding problems with their JS and the Opera browser. The page is accessible at http://altman_t.web.lynchburg.edu/new/firstunion.htm. I post this here to demonstrate the problems Mozilla users will encounter when trying to get companies to work with Mozilla when the statistics for Mozilla don't reflect spoofed user agents.

H-J: After looking at Tim Altman's comments and page ( http://altman_t.web.lynchburg.edu/new/firstunion.htm ), and took a better look at opera's implementation, I think this "bug": 1 - 'Gecko/builddate' is always added to the useragent. should be put back in as a "feature". With opera, you get Mozilla/5.0 (Windows 98; U) Opera 5.12 [en] for Mozilla 5.0 Mozilla/4.76 (Windows 98; U) Opera 5.12 [en] for Mozilla 4.76 Mozilla/3.0 (Windows 98; U) Opera 5.12 [en] for Mozilla 3.0 Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 5.12 [en] for MSIE 5.0 To make everyone happy maybe it should be there by default but have an option to turn it off.

basic, it is there by default? If yuo don't mess with the override, everything is fine and Mozillaish and specish. If you use override, you must know exactly what you're doing. All seat-bells unlocked.

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

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

DUPs: Most of the dups actually ask for the ability to fake the user-agent, not specifically a GUI, so they are not really dups of this bug, but the older, closed bug 45565. Please mark them as dups of that bug from now on. Only 2 dups ask for a GUI, so removing mostfreq.

<QA_ignore> Well, I cannot agree with that change. This bug presently *has* 11 dups (that is other bugs duped against it, correctly or not). If you disagree with what they should be duped against, you should change the dupings. Presently this bug is the only one on http://bugzilla.mozilla.org/duplicates.cgi without a mostfreq keyword. It is an abnormality and don't be surprised when someone patrolling that page makes it mostfreq, again. </QA_ignore>

All I want to do is to log into my bank and to view certain web pages without having to switch web browsers. Would someone please take time off from discussing the philosophical ramifications and just tell me how to do this?

Ben: I don't agree. For one, this bug has 27 votes, telling it's own tale. Secondly: your counting is wrong. I didn't bother to read all the dups, but dups here that initially specifically compare to Opera's implementation are for instance bug 73838, 76448, 81566, 86820, 89391. Since Opera's implementation is indeed a GUI, it seems reasonable to make those dups of this bug.

Shanti: Presently it is next to impossible. You must quit Mozilla and start from deleting (or renaming) the five Java plug-in DLLs in Mozilla/plugins directory - see bug 93376 (but keep them somewhere for later). Then, edit the Mozilla.org\Mozilla\defaults\pref\all.js preference file adding pref("general.useragent.override", "Insert here the UA you need"); Restart Mozilla and see the page you want. Later quit Mozilla again, delete the pref from all.js, restore the Java plug-in files and live happily ever after... Ben: Do you really think the dups are about this "fix" from bug 45565? I don't. Thefore I restore the mostfreq keyword per R.K.Aa's and my own comments

Correction: Crash with a spoofed IE UA is bug 83376. Sorry.

> Shanti: Presently it is next to impossible. Nonsense. Create a file called user.js in your profile, write user_pref("general.useragent.override", "Insert here the UA you need"); into it, restart Mozilla, done. You can read that at every better Netscape-/Mozilla-FAQ, I might add. > Ben: Do you really think the dups are about this "fix" from bug 45565? Yes, they are asking for the ability to fake another browser. We have it.

> Nonsense. Create a file called user.js in your profile, write > user_pref("general.useragent.override", "Insert here the UA you need"); > into it, restart Mozilla, done. Crash. Remember Shanti wanted to spoof IE (what else if he wanted banking pages?) and read bug 83376. However, spoofing Netscape 4.* would probably work without uninstalling Java.

Ben said: > > Ben: Do you really think the dups are about this "fix" from bug 45565? > Yes, they are asking for the ability to fake another browser. We have it. That's a lame remark and you know it; like telling a user their Mail client can retrieve their mail, providing they don't mind not having a user interface to it. Nonsence, they want a visible way altering their UA string, and just because "a backend system exists" doesn't mean their request has been fulfilled. If all developers took that view, Mozilla would be hopelessly doomed. Mostfreq certainly stands imo. Sorry for the spam, but it needed saying. I'll have to assume that H-J is still not fully fit and thus ask if anyone has enough to time to see that his code works in current builds.

One more reason for this feature to be implemented: MSN.com blocks browsers that do not match certain patterns in their user-agent identification string. See http://slashdot.org/article.pl?sid=01/10/25/1824206&mode=thread

Though they've decided to change that: http://news.cnet.com/news/0-1005-200- 7660935.html Also note that it does not block Netscape 6.1, but will block Mozilla and Opera. MS claims that Mozilla and Opera don't support the W3C standards. Talk about a publicity stunt.

As to the question whether there should be a comfortable UI for changing user-agent string: Yes, yes, yes, dammit. Imagine if we had the same attitude for POP3 mail retrieval: The users are asking for the ability to download POP3 mail. We have it. They can connect through telnet to port 110 of their mail server, login and do a RETR of all new messages, then save all of them to individual .eml files and open in Mozilla!

Tim: they were supposed to change that on Thursday evening. It seems they forgot to add which Thursday as the site is still unazessible to Mozilla. We need to fix this bug soon and even more urgently bug 80658.

If you think that this and bug 80658 are *really* bugs in Mozilla, you've fallen prey to Microsoft's monopolistic message. Not having multiple user-agent settings is not a deficiency in Mozilla. The need for multple user-agents is merely a reaction to Microsoft's behavior. Mozilla can't be reactive. You have to be proactive. The answer is not to implement multiple user- agents or site-specific user-agents. This is an evangelism issue, pure and simple. As I've said before, by hiding the Mozilla user-agent, less webmasters will recognize Mozilla as browser that needs attention. Using IE's user-agent just adds fuel to the fire to not support alternative browsers. I would think that Mozilla developers and users would want the opposite.

Tim: I work in the Mozilla evangelism team. I know how unresponsive some organizations are. What good will come from your high moral ground when to use my on-line banking I have to spoof the user string. Some banks completely refuse to change their policy of not supporting Mozilla. The real world alternative is to use IE. Why should you want me to do that? Speaking about evangelism, this feature is very helpful in evangelist work to check iwhether the problem is how Mozilla renders the page or just the browser detection script the site uses. Sometimes it is the only way to test a page with Mozilla (like in the present www.msn.com situation).

Jacek: Do you think that sites (online banks) that currently block Mozilla and refuse to change their policy will be more likely to change something in the future if they don't see Mozilla showing up in their logs? I don't. I'm not asking you to use IE either. Personally, I'd switch banks. What good is going to come of Mozilla hiding behind IE's user-agent string? If a site thinks that all its hits are coming from IE, what's to stop them from moving to completely proprietary markup? Why not just use MS Word to make the site? IE will display it. I agree that this feature can be helpful for checking if a web site works when identified as something else, as I've done this in the past with Opera. Please don't be so short-sighted. Don't let Microsoft dictate how Mozilla should act. Be your own browser.

> Do you think that sites (online banks) that currently block Mozilla and refuse to change their policy will be more likely to change something in the future if they don't see Mozilla showing up in their logs? How do you expect Mozilla to show in their logs if they block it? Everyone will try once and then switch to the "better" browser blessed by the offending site. For many this will be the end of their Mozilla experience. I do agree that generally we should not emulate other companies' user strings, but I am afraid that some sites could block Mozilla intentionally just to force users the "upgrade" to their products. In this case we should give the users an alternative, not to lose them.

> I am afraid that some sites could block Mozilla intentionally just to force > users the "upgrade" to their products. If their goal is to block Mozilla, they can always do that, unless we completely duplicate MSIE (which would of course be nonsense). The UA string faking just pushes this development out until they block based on their proprietary stuff. The most recent move shows that they don't even hessitate to clearly lie. Can we maybe move the discussion to a newsgroup, like .ui?

Ben: "They" (if you mean the company behind msn.com) claim they are W3C compliant so they cannot use proprietary crap at the same time. <QA_ignore> > Can we maybe move the discussion to a newsgroup, like .ui? Of course we can. I do agree! I love when people continue an off-topic discussion and at the end say we should move it where it belongs. A great way to get the last word! </QA_ignore>

There is nothing stopping us from having both the 'faked' user-agent string for IE/whatever plus a Mozilla brand like "Gecko" in the UA string we give; it'll show up in the server logs that way, assuming the log parsers know about it.

Something to consider regarding a modifiable user-agent: The only reason we need it at all is that web sites distinguish between browsers based on the user-agent. But if the browsers they're trying to distinguish between all have a modifiable user-agent value, then an attempt to distinguish between browsers won't work. Web site authors will be forced to either code their site to a standard that all browsers properly follow, or code their site to the most popular browser. Which one of those they choose will depend on what the goal of their site is, but I would regard either as being superior to the current situation. If the site codes strictly to IE, for instance, then the site may or may not display more or less properly when viewed with Mozilla when it spoofs the user-agent, but this can be fixed in Mozilla itself if it really proves necessary. Some users of sites that don't display properly in Mozilla will complain to the webmaster, which will either cause the webmaster to fix the site or tell the user to use IE, but in either case the webmaster will take some flak for not coding his site to standards. And isn't this exactly what we want? Letting sites truly distinguish between browsers by querying the user-agent string only serves to cause webmasters to take the easy way out, by not even letting certain users view the site with the browser of their choice, or by providing severely reduced functionality for anything but the "preferred" browser. This situation is completely contrary to the original point of HTML. By making it much more difficult if not impossible to distinguish between browsers, we'd be evening things out a bit, I think. Frankly, I think we should never have had the user-agent field in HTTP to begin with.

> I love when people continue an off-topic discussion and at the end say we should > move it where it belongs. A great way to get the last word! Not my intention. Posted to .ui: <news://news.mozilla.org/3BDA052E.2000303@beonex.com>.

It's my understanding that these rude sites that insist on MSIE, look for the string "MSIE". So I suggest that the official Mozilla id String should be something like:... "Mozilla (compatible with MSIE)". That way, rude sites will be fooled, and enlightened sites can still count hits as Mozilla and id it if necessary.

> Additions come at a cost: they make the product appear more > complicated to use and they clutter the already crowded prefs. > The aformentioned 80% case has no idea what a user-agent is, > why they would want to change it The 80% have no idea where the Preferences are in the menus, or why they should change any of them. (If you think I'm not serious, you haven't been watching many end users.) The Preferences dialogs exist for the 18% who know what preferences are and want to change (some of) them but don't want to edit prefs.js by hand. i.e., power users. (The other 2%, programmers, merrily edit prefs.js by hand, and probably use Emacs or something equally arcane to do it.) Bury it under the Advanced tab in the dialog that pops up if they hit the Advanced button under the Advanced pane in the preferences, that's still more comfortable than editing prefs.js by hand. > H-J: bear in mind that these lists must be Javascript > controlled, the content of each generated based on a > matrix. Otherwise you risk people selecting > Linux->Internet Explorer->5.3 which of course doesn't > exist. And the sniffers will tell them they're smoking crack, so what? (I think it's amusing to claim to be using an X11 build on Windows...) Also: Is there a reference chart showing the UA strings used by the major versions of the major browsers on each major platform? Shouldn't there be one on mozilla.org?

There's an optional sidebar "fixing" this bug: <http://mozilla-evangelism.bclary.com/ua/>

there are lists of useragents and things online... chris@tech.com.au: Please don't confuse bugs, this is about prefable useragents not default useragents. Beyond that, your suggestion is extremely silly (not to be discussed in this bug) - if you want to make this suggestion (and risk being flamed), please post to news://news.mozilla.org/netscape.public.mozilla.netlib (read http://www.mozilla.org/community.html first. I'd suggest that you also read the entire netlib group [also available on the web at http://groups.google.com/groups?q=netscape.public.mozilla.netlib&hl=en&btnG=Google+Search ] before posting to understand what views people have on useragents). As for X11 on w32, that's not impossible although it is silly imo.

Why not just use a combo-box with a number of common User Agents? Or a dropdown and a textbox. Then you can modify the string by hand.

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.

default owner...

IMO, this would be bad mozilla; resolving as wontfix.

IMVHO, didn't they say the same about tabbed browsing! -Neil.

Ok.. Dont know who you are Peter Trudell.. You might be the one saying what goes.. But to mark this as RESOLVED? And WONTFIX? Please.. Submit your opinion.. But yours is not the only one This is IMO good Mozilla.. Reopening bug Cant enter my Banks site without this option. Used frequently in browsers not being mainstream.. Opera, Konqueror.

Well, Peter Trudelle is the owner of XPToolkit module. That is unless he hacked into http://www.mozilla.org/owners.html. On the other hand this bug is in XP Apps, not XPToolkit. For example, I would not like people WONTFIXING bugs in my module (Tech Evangelism; Europe: Central, BTW) with such scant info on reasons. I do not know if Don Melton (listed as the owner) a) cares b) is still the owner c) is alive

Don has been gone for a while and Peter has essentially taken over Don's responsibilities... the owners page is way outdated.

Boris: Thanks. That's what I expected. But I do not blame Per-Olaf for not knowing who Peter is. If he (Peter) believes this is a WONTFIX he should write at least a short paragraph why. People do wont this feature (including me). You cannot just say to the 32 voters "this is bad mozilla, good bye".

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

-> default assignee

There are plenty of comments in this bug explaining why it should not be implemented; those who disagree are not going to be convinced by one more, and I have better things to do than argue about it, such as getting the next mozilla1.0, MachV and other releases out. This feature would be a detriment for the vast majority of target users, adding not only complexity and bloat, but the danger of making the browser useless for its primary purpose. It would do nothing for mozilla either, and would be an added impediment to distributors. I can understand wanting access to online banking, but the real answer there is to get evangelists on the job, and increase browser market share, which will happen, but not while adding lots of geeky features like this. The handful of users to whom this is perceived as a beneficial feature in general are probably capable of adding it to their own builds, or creating their own package or distribution. Mozilla is primarily a browser for the masses, regardless of what some contributors may prefer. We cannot add every techie feature that anyone wants unless we take that into consideration. ->WONTFIX

Strange: I always read that Mozilla is not a commercial product and primarly targeted at developers, and that the "average user" will use Netscape or other products based on Mozilla. But your main reason for not implementing this feature is that Mozilla is a browser for the masses. Very strange indeed.

> Strange: I always read that Mozilla is not a commercial product and primarly > targeted at developers, and that the "average user" will use Netscape or other > products based on Mozilla. But your main reason for not implementing this > feature is that Mozilla is a browser for the masses. Very strange indeed. Simon, I think for Peter Mozilla = Netscape. And why not... - Holger

I have mixed feelings about this specific bug. ...but on a more general note, perhaps there is a need in bugzilla (for mozilla) to have NOTNETSCAPE vs WONTFIX Where one means that Netscape engineers will spend no time on it, and the other means that the mozilla community isn't interested in it. In the first case, anybody@netscape.com would ignore the bug, but other folks could submit patches, and if they didn't cause harm, they would be accepted into mozilla. In the second case, anybody@netscape.com would ignore the bug, and no patches would be welcome, and if any were submited, they would be ignored and not applied (althought I guess someone might still send in a patch for the small minority of folks who *really* want the patch to apply to their local trees). Does that sound like a useful distinction? -matt

It seems to me that Peter has a problem with understanding how an open source project works. If he sees no reason for an enhancement but the feature does not conflict with anything, the bug should be reassigned to nobody@mozilla.org and targeted to FUTURE, and not WONTFIXed. Netscape has no need of including the feature if someone adds it. Mozilla is more than Netscape Communicator. Or at least was supposed to be...

As long as Mozilla has a user interface on which commercial products are based (rather than simply being a toolkit and having test apps that test all the features of that toolkit), it's reasonable to mark feature requests that make that UI confusing as WONTFIX. Furthermore, extra features are extra bloat. We can't be small, fast, *and* support every feature anybody ever wanted.

removing self from CC.

> I always read that Mozilla is not a commercial product and primarly targeted > at developers, and that the "average user" will use Netscape or other > products based on Mozilla. That's right. Mozilla targetted at developers (incl. QA) and distributors. However, fixing this bug makes the Mozilla *less* uselable for distributors, because they most likely don't want it in their Mozilla-based product and will have to remove it. That's basically what David Baron said. It can be argued that it might be useful for Mozilla QA. But then it has to go under the Debug menu and a simple, but flexible UI is sufficient (e.g. a textfield with history). > NOTNETSCAPE That's AssigntedTo: nobody@mozilla.org > It seems to me that Peter has a problem with understanding how an open source > project works. If he sees no reason for an enhancement but the feature does > not conflict with anything, the bug should be reassigned to > nobody@mozilla.org and targeted to FUTURE, and not WONTFIXed. No, I think you misunderstood something. The product (incl its UI) needs to be good. Not every feature, esp. in the UI, is automatically good. What good is has to be decided in some way, but if the decision for a particular feature is "not good", then it's WONTFIX, even if working patches exist. > Netscape has no need of including the feature if someone adds it. But Netscape has to take adtion to *remove* it. And it's not only Netscape. It's about every distributor of Mozilla. > Mozilla is more than Netscape Communicator. Or at least was supposed to be... Actually, it was supposed to be less, but that's another story.

Peter is _not_ having a problem understanding how an open source project works. Open source does not mean "anyone can add things if they want to". There is still quality control and a certain amount of central direction in any successful open source project (mozilla actually less so than most). An open source project need not, and usually does not accept all patches....Mozilla is very liberal in this regard, but at times even Mozilla will refuse to take patches. Peter is speaking as a Mozilla component owner, not as a Netscape employee here. I am one of the people who _would_ like this feature (and unlike most of those complaining I've actually done something to help that happen). But at the same time I understand that this is a fairly odd UI feature to have by default... And the component owner is the one who makes design decisions like that; that's the whole point of having component owners. Now since this is an open source project, people _can_: 1) take the existing patch in this bug, update it so it works with current builds, make and XPI, put it on mozdev.org, and maintain it against new releases. 2) fork off a version of mozilla with this patch and take those patches off the trunk that they feel are worthwhile. Yes, we could keep this bug open, futured, helpwanted, assigned to nobody. But if the component owner will never accept a patch to fix it, what's the point? To slow down bugzilla searches?

Or 3) implement the UI in the debug prefs which are items aimed at developers/testers and get taken out of commercial distributions like Beonex and Netscape 6.

Of course 1) has been done, at least twice: http://www.illsley.org/useragent/ http://mozilla-evangelism.bclary.com/sidebars/

I think that since the number of votes place this bug in the top 50, dveditz's option no. 3) should be taken.

If implemented, it would be a very useful tool for us, the evangelist team. See my #129 comment. Voting for option 3).

The Mozilla browser is targetted at typical end-users, who are mostly the same as Netscape users. Major distributors would have little interest in supporting a browser targetted mainly at mozilla contributors and other techies. There is confusion on this only because Mozilla itself is not a *product that is supported for end users*. However, adding this only to debug prefs would be fine.

Reopening per Peter Trudelle's last comment. I think that Debug prefs UI is not removed from the distribution builds of Netscape, only disabled. So, less code would be better here, IMO. Not that important, though.

In particular, this should not measurably affect performance or footprint of production builds.

Someone who wants this better take it, because I'm not assigning any engineers to implement it.

David Illsley's version is now available at http://uabar.mozdev.org/ Clearing the patch and review keywords since these patches have been rejected. If someone takes this up they'll need to re-work it to put these on the Debug prefs pane, not into the standard set (per module owner).

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

(updating summary to match recent comments)

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

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

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

Bug 152067 is not asking for Mozilla to emulate other browsers like opera does . Bug 152067 is asking for Mozilla to ignor browser redirecting code. Bug 152067 Is not a dup go look for yourself.

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

I've started a new project at: http://quickprefs.mozdev.org That will take care of this bug. Why add everything to plain mozilla? What is wrong with using a good add-on for this kind of feature?

re: doing this via an add-on My understanding of the position is that the functionality is core to mozilla's market. Mozilla is not a browser for the masses. There are plenty of projects which use Mozilla technology to create a consumer's browser. Mozilla is a testbed for the mozilla code. As such, it should have features which allow users to test that code (ie: it would be silly to add support for tabbed browsing if Mozilla had no UI support to take advantage of that support). It should also have features to support testing of the product in general (ie: that whole QA menu, the debug section in the prefs, the ability to control HTTP networking in the advanced section of the prefs). Users can't verify that many bugs are only advocacy issues (site sends lame content to mozilla, but good content to msie) without this feature. So, some would argue that this feature is very relevant to mozilla's purpose and should be incorporated into the product rather than asking testers to install an add-on each time they upgrade their nightly build. (Yes there's another bug to allow those add-ons to persist across upgrades.) -matt

Hence why this should be a debug only pref...

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

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

If this is implemented then I should be able to change it from the tools menu or somthing having it only in the preferences will waste time.

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

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

How is this not a RFE bug?

> How is this not a RFE bug? It is. severity=enhancement The RFE tag in the summary is redundant.

alowing to set this for all websites is unacceptable. Doing this for a specific page is ok, but NOT for all pages. It would result in having more MSIE in all logs.

The whole point of adding a debug-only gui to change the UA string is so that people who are evangelizing a MSIE-specific site can quickly and easily prove that the site works just fine in Mozilla. It isnt intended for regular use, thats why it would be "debug only". it isnt intended as a general purpose workaround for crappy sites. Besides when one must spoof the UA string, it is easy to do something like this: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; Mozilla-spoofing-IE)

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

this is actually a invalid bug - we have addons for this.

INVALID per comments.

v

Why is this bug, after more than two years and a lot of comments, not to mention the votes, marked as INVALID? That is rather stupid, it should be closed as WONTFIX. http://bugzilla.mozilla.org/bug_status.html reads: INVALID "The problem described is not a bug" This RFE is a perfectly valid Request For Enhancement, but it simply won't be implemented for mozilla. However, there are 3th party add-on that do this stuff. WONTFIX "The problem described is a bug which will never be fixed." This looks more like it, it won't be part of the mozilla tree so it will never be fixed, but in the mozilla tree that is. Just my $.2 cents

unbunching bugs4hj@netscape.net's panties

.

VERIFIED (like it matters whether it's invalid or wontfix...)

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

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

All REALTORS in US are now required to use IE5.5 at http://mycounty.mlxchange.com website to access database of local listings. No other browser will work accept for aol. I just tried changing user string in Konqueror but after login I got an error for incorrect parameter. Gates has even got his fingers in the Real estate pie.

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

nobody@netscape.com is about to take a long vacation to the bit bucket

Re Comment #199, that URL no longer works.

Sorry for spam, but the default URL for Mozilla Evangelism has moved since this one was entered. Fixing now....and no comments about why I'm doing this on a "WONTFIX" bug ;-)

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