User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Please consider having different levels of logging and maybe consider extension logging enabled by default.(From Start) If the JavaScriptConsole may get in the way somehow please find A way to seperate the two. Reproducible: Always For anyone who would like to enable extension logging please follow the steps below. In the Adress bar type ABOUT:CONFIG In the filter(below) bar type Logging Toggle the Extension.Logging option to true. ( It should be the second to the last option shown )

Already planned for 3.0... it is too late for 2.0 since it is almost out the door. *** This bug has been marked as a duplicate of 343553 ***

Robert , What of having Extension logging enabled by default ?

It is currently way too verbose... what messages in the logs are you wanting to have on by default that all people should have without having to set the pref?

Seeing file systems allready have A modification date and LAD/LAS , how about simply the source of the extension. Default Level 1 (At Birth of Install) Then the user could have the option of changing this to 2 3 or 4.

(In reply to comment #4) > Seeing file systems allready have A modification date and LAD/LAS , how about > simply the source of the extension. and what value is this going to provide to the average user? > Default Level 1 (At Birth of Install) This has absolutely no meaning to me... what does default level 1 refer to when all we have today is all or nothing? > Then the user could have the option of changing this to 2 3 or 4. What is 2 3 or 4 when all we have today is all or nothing? As you have shown that absolutely none of this is defined and that the logging has shown to me personally that it provides little to no value for trouble shooting extension manager bugs there is no way this would go into 2.0. I would very much appreciate it if someone took on bringing sanity to the extension manager logging or better still to how we do logging in general. For 2.0 it is way too late to do so but for 3.0 it is definitely a possibility.

Please allow me to be blunt. > Seeing file systems allready have A modification date and LAD/LAS , how about > simply the source of the extension. >>and what value is this going to provide to the average user? Sorry to brake this to you robert, but what part of FireFox do you find Average.? Once someone installs there OS 75% of the time it includes a browser other than one based on the mozilla core. The average user isn't average anymore. And as the popularity of FireFox grows there won't be any need for such personifications. We need to strive to be the best. > Default Level 1 (At Birth of Install) >>This has absolutely no meaning to me... It doesn't need to. >>what does default level 1 refer to Please read comment 3 more carefully , With level 1 or "Default" level I was refering to the most basic and general information. ..The ext. source. Seeing how most platformms (Operating Systems) now use some form of system restore and the "AVERAGE" user installs about 2-5 Extensions A month, And the fact that most operating systems allready log file Modification times as well as file access times and even more verbose logging on some platforms. I see no need for the default (or most minimal) logging stategy to include this information. Unless you would want to record the Standard time of the source location of said extension. >>when all we have today is all or nothing? This is unacceptable , and needs to change , just as you and many others have suggested in the past. > Then the user could have the option of changing this to 2 3 or 4. >>What is 2 3 or 4 when all we have today is all or nothing? Level 2 3 and 4 can be whatever you want it to be. I was simply making A example of possible options. Another option could be logging "Profiles" Where the user could be -prompted at install- which to use logging and at what varasity. >>As you have shown that absolutely none of this is defined and that the logging >>has shown to me personally that it provides little to no value for trouble >>shooting extension manager bugs there is no way this would go into 2.0. I >>would >>very much appreciate it if someone took on bringing sanity to the extension >>manager logging or better still to how we do logging in general. Perhaps what your looking for is simply reasurance on A probably allready thought of stategy? Some type of XML output log ? Limiting developers to only use mozilla's site to host all extensions in developement ? If so.. Would developing some type of code that would be inbeded directly into the core be one of them ? >>For 2.0 it is way too late to do so but for 3.0 it is definitely a possibility. Well , We have to start somewhere. The sooner the better. PS:: Why not pose the question at startup what type of user the package would be working with and from there make the necisary options available to said user? New Intermediate Versed Developer Admin(For House use ofcoarse) Just putting some thoughts out there.

The average statement comes from following the requests from people using Firefox. This is the first or possibly second such request while the vast majority of people using the application have not so much as mentioned a need for this. Striving to be the best does not always mean providing every possible option as Firefox itself has demonstrated. It most certainly means as it relates to Firefox not presenting users with additional user interface and choices when the average user does not care one way or the other about the option. It most assuredly needs to have meaning for me since if it is to be implemented it will first need to be defined and then understood by me. So far you have asked for the source to be logged though we already show the source in the xpinstall dialog. That is by no means anywhere near what will need to be defined and at best all that you have provided is the desire to have multiple logging levels without any real definition as to who the target audience is for these logging levels or what these logging levels will provide. Now, instead of additional witty statements please provide some actual use cases for these logging levels along with what should be logged for these same levels. If the outcome of this definition work shows that the pain to implement / maintain this functionality as it relates to value to the application's user base is reasonable then I will be for adding this... otherwise I won't.

No I guess your right , adding every possible feature/option doesn't realy make you the best , but this day in age I think allot of people would agree with the fact that source and domain spoofing is on the rise. If it's A scenario you need lets take A hypotheticle into account. ____________DRAMAT.. 1______________ User X is or has come across FireFox on a public machine and has now also come across the vast wonderful world of extensions. After several days of use (not in any particular time frame group) user X would like to install A extension found on A particular site (the source) sometime last week. There racking there brain and just can't remember when and where they saw this valuable add-on. Enter the extension log. Later they find that by A mear toggled option within the configuration of FireFox they could have had A complete log and timeframe where and when the extension they wanted was downloaded. ................................................................................. ____________DRAMAT.. 2______________ Another instance A extension log would come into play would be if maliciouse code was ever entered into A XPI , as the popularity of FireFox grows more and more trouble makers are going to find new and mysteriouse waaaays of injecting **** into the pool of the internet. Enter the Extension log. USER X could then trace back -when- -where- & >from there who , how , and then hopefully |arrest| the entity responsible. ------------------------------------------------------------------------------- You know what , I haven't heard much from anyone but you robert on this , I would respectfully like A second opinion. Surely that isn't to to much to ask for seeing this is my first real enhancement request and logging is the issue. There are probably A thousand of reasons out there we can think of for having logging enabled and different verbosities available to power users by default. But mostly importantly it's for the reasons we can't think of. And if you think MY statements are witty , It's from years of experience dealing with other developers on other browser forums such as K-Meleon and Mosaic. Lets keep an open mind!

If there is the possibility of source and domain spoofing then that should be addressed in the user interface and not in the error console or an extensions file log. The extension file log is a separate issue than what you requested for this bug regarding the Error Console. Also, the error console does not persist across sessions which your scenarios require. So, the target audience you see value for per your scenarios are users and not extension developers. Scenario 1 - somewhat of an edgecase in that the majority of extensions are hosted on AMO and the extensionsmirror. Scenario 2 - also is about logging the site where it was installed from. Both are about logging the site where it was installed from and there has been little to no detail about what the other 4 logging levels would provide. Personally, I don't see much value in having multiple logging levels for a file log but I am still open to this being defined / justified. I have kept an open mind and have believed quite strongly for several years that the logging story for the extension manager as well as the app needs significant improvement and I am planning on improving this for the extension manager for 3.0. btw: if I didn't think something needed to be done I wouldn't waste my time discussing this with you and challenging you to further define how it should be implemented.

Scenario 1 - somewhat of an edgecase in that the majority of extensions are hosted on AMO and the extensionsmirror. I have to disagree with you slightly on that. To answer the posed question about different logging tiers... Keeping track of extension -[versions]- would be a very good reason to have a higher tier (Intermediate) that would record the source file time. Tier 2 would also be possibly a good reason to record the standard time of the extension source. Tier 3 and 4 maybe used for debugging information as versions of FireFox increase. There could be A slight possibility to include memory leak information in some of the most advanced tiers. As the average user extends there extension list they will probably want to fine tune there extension experience. And if you feel your time isn't well spent then feel free to put A sign on the registration for bugzilla that says. "Don't bother debating you won't see affirmation or a devils advocate opinion here." :o) Oh and one last time. : There is NOTHING average about FireFox or FireFox extensions for that matter. My frustration and witt is not directed at you robert , sorry if you think so. It's directed at the fact I and many co-workers have no idea where half there extensions they have came from ..., when they where downloaded , OR the valuable extensions functionality they have seen before in the past went and from what Add-On. It's like A crazy paradox. If every extension where signed and had A "leash" we wouldn't have that problem. That's not the case , one extension follows another and another and another. People who want the latest and best usually go(FOLLOW) directly to the source and not AMO. Now if you limited development to AMO , -SOMEHOW?!??? , then that would change things dramatically.

I never stated Firefox was average... what I did state in so many words is that we add functionality for the average use cases and not for the rarely used cases/ The rarely used cases are better served by extensions themselves. I never stated that I was wasting my time in this bug... what I did state is that is that I wouldn't waste my time replying in this bug if I didn't think it was important. I'll create a wiki for what we should do for em logging in 3.0 so this can get properly defined.

Thank you.