Feature tracking. Define the contents of the "Developer" and "Browsing Enhancements" extension packs that are presented through the Firebird installer. Identify any code changes required in the bundled versions of these extensions to meet quality requirements, respecify and implement changes as applicable.

Ok, after reading http://www.bengoodger.com/software/mb/FBInstaller/addons.txt I have a few comments to make: >Additional Browsing Enhancements > > [...] > - enhanced page info Does that mean, that page info will be ditched from the base install? Bug 214265 sounds more like it will stay in a more simplified form. I also think, that we should add some more extensions for additional browsing enhancements here: 1. Tabbrowser Extensions One of the most popular extensions for firebird as well as for seamonkey. IMO a must have. 2. Things They Left Out or Preferential A lot of users in the firebird community and even more users, which still use the appsuite complain about the lack of UI-editable options. Shipping an extension like TTLO or Preferential (only one of them is needed) would address that and would also allow us, to keep our UI-editable options as low as it is now. 3. Themes We should ship 3-5 of the most popular themes, thereby advertising the great customizability of the firebird UI. The best approach would be to contact the guys at mozdev.org and/or David Tenser from texturizer.net to get some numbers on extension- and theme-downloads and then ship firebird with the most popular ones. >Additional Developer Tools > - error console > - inspector > - venkman So far so good, but you should also take a look at the Web Developer extension at http://chrispederick.myacen.com/work/firebird/webdeveloper/

Since mozilla.org is focussing on the enduser now, I wonder how QA will be made for the extensions which are not hosted by mozilla.org. Endusers will get the impression, that those extensions are an integrated part of FB - with the consequences of (maybe) bad reputation for mozilla and invalid bug reports.

Simon, features of TBE might be included in the enhanced browsing pack. From my understanding its more like two extensions, not a dog's breakfast of the most popular ones. There will be one theme only (this has long been established), we're aiming to keep the download as small as possible. Daniel, see my above comment. These addon packs will be part of the official distribution and QA will come through here. Other extensions, well, that's the limitation of unoffical extensions. There's talk of official extension hosting, but that's Future stuff. Dev Pack - Venkman - DOMi - View Source in external editor (valued by some admins, conversion issue)

No idea if this has been decided yet, but I'm curious: What does "Simplified Mouse Gestures" in Ben's list mean? I thought the point was to include existing third-party extensions, not creating new ones that have to be maintained.

Adding DOMI and Venkman dependencies

I don't see ChatZilla on the list, what's up?

Adding Chatzilla and JS Console. Sorry for the bugspam. I'm not sure about external View Source, bug 172817

I'd like the following extentions added to the packs. I use most of them frequently while working on webapplications. For the Developer version: LiveHTTP headers : http://extensionroom.mozdev.org/#livehttpheaders Javascript Console Status: http://extensionroom.mozdev.org/#jsstatus EditCSS: http://extensionroom.mozdev.org/more-info.php/editcss and PNH Developers toolbar: http://extensionroom.mozdev.org/#pnhtoolbar OR webdeveloper: http://extensionroom.mozdev.org/#webdeveloper And to the browserextentions: MNG support: http://extensionroom.mozdev.org/#mngsupport Link toolbar: http://extensionroom.mozdev.org/#linktoolbar

For the developer pack: http://tuxhealth.mozdev.org

Copy Image to Clipboard (bug 210043 which is still waiting for Linux backend) http://extensionroom.mozdev.org/#copyimage (Win32 only)

Adjusting summary in anticipation of a possible fix for bug 224989 and to make finding installer bugs easier.

Moving to new installer component.

Does Composer count as a developer extension?

Sorry to spam (if this is considered doing so!?) I have to agree one a few issues, and disagree on some others (welcome to bugzilla :D) First: Atleast one other theme should be devivered with Firebird Standard. This allows the user to 1) Experience the possiblities of Firebird and Theme switching, and 2) Interest newbies in more themes Secondly: The TBE issue, I definitally DON'T think it should be included, and I'm pretty sure the devs would agree. There is a substancial performace hit, and those features shoul be intergrated in Firebird (hard coded) liek Hayatt has mentioned before. Third: Ben are you willing to "package" non-official extensions? If so, how will you decide on which ones? Honestly I think only extensions witch "Enhance" the browser shoudl be considered (i.e. Image Zoomer, Googlebar, MouseGestures, Autohide toolbox, MNG support, Web Developer, etc.)

Not going to happen before .8. Browsing Enhancements, or complete DevTools, that is.

I'd like to see SVG included in the installer version. If other graphic formats are supported the "one for the future" should be in too.

Ok, Ben, Chatzilla is ready to be included.

I'd vote for the Googlebar (http://googlebar.mozdev.org) to be added. Although there is a Google search field the Googlebar provides much more functionality and makes it easier for users who are used to the functionality of the Google-toolbar (http://toolbar.google.com) to migrate from MSIE to Firebird.

I vote against googlebar. First, there IS the search field already. That would be redundant. I don't think the majority of people would want a whole toolbar.

It might help the Seamonkey to Firebird migration to include TTLO (http://extensionroom.mozdev.org/more-info.php/ttlo )

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

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

Bug 232846 is not a dupe. That very specific and is about a "Web development extension", while this bug is much more general. Added: bug 232845 - Create a "standard extensions" web page bug 232846 - Create a standard "web development" extension with JS Console, Venkman, and DOM Inspector bug 232849 - Make View Source an extension

232845 - Has nothing to do with bundling extensions themselves 232846 - Combining them into a single XPI is not really related. DOMI is already an optional installtion item. These are for the Installer, not generic.

Given the number of Opera users that post in the mozillazine fourms wondering why FireFox does not have X feature from Opera an Opera-like plug-in selection would help them. An Opera-like plug-in selection. http://www.opera.com/features/ 1) MiniT http://extensionroom.mozdev.org/more-info/minit 2) Mouse Gestures http://extensionroom.mozdev.org/more-info/mousegest 3) ImageZoomer http://extensionroom.mozdev.org/more-info/imagezoomer 4) Session Saver http://extensionroom.mozdev.org/more-info/sessionsaver 5) QuickNote http://extensionroom.mozdev.org/more-info/quicknote These are roughly ordered in how often people are looking for this feature at mozillazine.

See also "Help for Opera Users" http://bugzilla.mozdev.org/show_bug.cgi?id=5500

(In reply to comment #8) > And to the browserextentions: > MNG support: http://extensionroom.mozdev.org/#mngsupport > See bug 234649.

I think that the number of opinions about which extensions should be available to the installer could be as numerous as the number of extensions. I know that the different installations of Firefox that I have all have different extensions applied. It ends up being a pain to find all of the extensions that I want to apply on every installation. I'm sure that you can't make everyone happy with the choice of extensions, or even how many and which themes to include. You could come close with the following idea: Have the installer look into the current directory (or a directory specified on the command line) for a special file that direct the installer on which extensions to offer. Maybe the file could include targets for themes to include and even default prefs that might differ from those chosen by the powers that be. Then I can load up a directory with the installer, the themes, extensions and prefs that I want, and make an installation from it. I can give it to my non-technical mom and she can install it without me having to walk her through everything. I can also install the same browser, prefs, themes and extensions on all 6 of the machines that I have. And if the special file isn't there, then the installer can present things in whatever way you would have done it otherwise. Just a thought.

We should have criteria so we don't get into bickering. I think the following criteria would be good: 1) Small, lightweight 2) Being useful for most users 3) Something that helps us compete with other browsers (mostly IE) 4) Something well maintained 5) Unobtrusive Perhaps we should offer some of the bundled extensions as simply install.js files that grab the stuff from the WEb. This would be necessary due to licensing issues for some plugins (bug 229590), and the same idea could be applied to extensions. In the selection list, there could be a list that are already included in the installer, and others that are installed from the web, along with a description of each extension.... kinda similiar to a package manager for Linux. We really need people to see there are extensions. I have already seen an article that complained about lack of features, but didn't mention anything about extensions. Leads me to believe that they didn't know extensions exist. As for which to include, I think we should actually support the ones we bundle, and only ones that are considered small but useful, extremely critical, or something IE users expect (or something that can lure IE users away). A larger selection of unsupported extensions (i.e. supported by 3rd parties), but still considered very useful to a wide variety of people, and well supported by the 3rd parties (i.e. reliable), can be offered as an "Install from web" option within the installer. Even large Mozilla extensions can be offered that way. I realize the people could go and download them after install, but this will make them realize that they are, in fact, there. If they have no connection, the download of the chosen extensions can be relegated until a connection is established after installation is finished (i.e. it would remember which ones they chose until they have a connection). The same scheme would work for plugins and I did mention that in another bug about plugin bundles. View Source, autoscroll, and tabbing are three examples of things that we could give a user a choice to install or not install. The question is: are they large enough and intrusive enough that people really will complain if they are forced to install these things? *** If we give them too many options, it might overwhelm the novice user before they've even installed the software. I do like the option for "Web Developer Features", although this would be better to download from the web during install so everyone doesn't have to download that bundle with the installer (and that's my hopefully correct assumption on how it works now). There are some things we might just want to install by default, so that we don't overwhelm people with choices. That fits into the three things I mentioned before: 1) Being small or lightweight enough that people won't really care 2) Being very useful to a wide range of people 3) Something that can help us compete with IE (or other browsers) 4) Something well maintained I'll add a 5th.. 4) Unobtrusive View Source, as an example is both lightweight, and unobtrusive (If we allow helper application for it). As for competing with IE, well IE offers view source in notepad (and also allows you to assign it to a different application). As for being useful, it depends on the situation. Some people might want to use a helper application, but that number will be a small percentage of users as our user base expands. There are also operating systems we might not be able to depend on a certain text editor being available. Linux is a prime example. So we'd at least want to offer it as an option. So, in conclusion, I think we can asses these 4 criterial I mentioned: 1) Small, lightweight 2) Being useful for most users 3) Something that helps us compete with other browsers (mostly IE) 4) Something well maintained 5) Unobtrusive A less stringent list would be offered for ones to download from the web of (2,3 and 4)

Couple corrections: replace Unobtrusive with Unintrusive replace "Even large Mozilla extensions can be offered that way." with "Even large Mozilla extensions that are supported by Mozilla.org can be offered by being downloaded by the installer during the install process as opposed to being built into the installer and increasing its size."

Please wait until the Firefox extension manager is finished being updated before going off on tangents about downloading from the web, etc. Those are other bugs.

i think if we added adblock. that would be nice.

Not going to tackle this now.

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

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

i think the installer should do what it says! currently et pretends to install Additioanl Browser Enhancements: "mouse-gesture navigation, a site navigation bar and other enhanced functionality" and Developer Tools: "error console, the Document Inspector and a JavaScript Debugger" .... but it only effects the DomInspector additional i think the JavaScript-Console shouldn't be in the default-installation, the average-users doesn't need it - just as the installer says it!

Requesting blocking1.0PR and 1.0, see comment 36.

Not going to be able to do a proper job of this until after 1.0, I'm afraid.

This one is precisely the bug I was looking for. I understand that Mozilla has a network installer and a full installer. The same approach could be used here. The installer could be a 'bare bones', pretty much what we already have now, but with an additional installation step. I think of two possible approaches: a) In the dialog for basic/custom installation, there could be a checkbox with the label "Install additional Themes and Extensions", enabled by default. b) The custom installation itself could have a friendly label like the text above (Aunt Tillie is scared about cryptic options) The user would be presented with a list of themes, sortable by popularity (you can count the downloads) or date (to see the most recent ones); Additionally, a tree with extension categories would show up. I think it could show up only the so-called 'supported' extensions, but feature also a checkbox to display 'unsupported' extensions. Of course there would have to be a limit here, like showing up only the extensions hosted in mozdev.org. The 'supported' label would assure that a certain extension would not wreak havoc on the browser, is uninstallable, and so on. The installations would not come bundled, but would be downloaded on-the-fly. The installer would fetch a list from the internet (mozdev.org?) with the latest extension versions and their status. Additionaly, one or two extra packages solely with the extensions (for offline installation) could be made available to be downloaded separately and placed in the same directory of the installer: one with a snapshot of the supported extensions, and another one with the unsupported ones.

There is no network installer for Firefox yet. Perhaps after they implement MSI bug 231062. Also, any items would come from update.mozilla.org (which relies on the mozilla ftp mirrors)

Hi, i dont want you to ship extensions by default. People should learn from the first day they use FF, that its highly customizable during mozilla.update.org. They _have_ to get in touch with installing extensions and themes. I think a more important feature would be: if you have a set of themes and extensions, there should be the possibility to export an .xml file. You can use it later in a fresh installation with an import function, and like if it would be a migration from 0.9 to 1.0, the installer could upgrade the those extensions and themes for you. regards

Default extensions are for modularity's sake. The whole idea is that many of the built-in features of Firefox should be included as extensions so that people could download minimal builds and then choose which of the "supported" extensions they want, instead of downloading everything. For instance, you might select "Web Development Tools", yet that was downloaded with the installer. Such extensions would not be included in the minimal version of the installer, but would be downloadable from the net.

See related bug 326514 - about allowing installation of any non-bundled extension from a.m.o. during the sm/tb/ff installation.

(In reply to comment #43) > See related bug 326514 - about allowing installation of any non-bundled > extension from a.m.o. during the sm/tb/ff installation. > To me, one of the most important points of having "supported" extensions is to define a core set of extensions that end users can count on being available for the foreseeable future, that are up to the same quality standards as the product they extend. Even if non-bundled extensions can be installed during the application install, theres still a strong demand for a set of core extensions that encompass functionality that's demanded by many users, but not part of the products themselves. I would assume that part of the process of implementing this would be to "adopt" those 3rd party extensions that should be part of a default bundle into the mozilla project, making them officially supported? Would it be good to file bugs on individual extensions for inclusion, and are we ready to start doing that, with the individual bugs depending on this one (making this into a meta bug for tracking, as it appears was originally intended)?

Resolving -> wontfix If we want to go down this road a new bug should be filed that reflects where we are today