Bug 56061 introduced the about:about page. It displays a clickable list of all the supported about:* Reason: These days, there are so many about:* that it is virtually impossible to discover/stumble on all of them, let alone remember them. Not being able to discover the about:* options means that not being able to use them. Bug 56061 already added the necessary redirector, we just need to add the aboutAbout.html file. This doesn't add bloat because it isn't part of the UI.

This introduces the aboutAbout.html page from bug 56061. It's a generated table with all the about.* The file consumes only 3543 bytes. I'm not sure about the toolkit/jar.mn, because I don't build myself yet. But it needs to be found in chrome://global/content/aboutAbout.html, and adding the file to toolkit.jar/content/global/ works fine.

Comment on attachment 132133 [details] [diff] [review] patch Noririty, can you review this please?

I'm in favour of about:about making an appearance, but maybe strike about:mozilla off the list and keep it a moderately known Easter Egg no? All is better than none though.

Comment on attachment 132133 [details] [diff] [review] patch Now I do build myself. It doesn't compile because the path in the jar.mn isn't correct. New patch coming up.

This one works.

Rob, the list is generated. It's possible to exclude certain items, but it's meant to be complete so that you don't have to remember any other about:.

taking.

targetting for 0.8.

Steffen, I think you need a QA here :-) You should not target bugs at a release without consulting one of the core devs first. Getting review is still a hard thing these days. Use the blocking?-field instead.

Comment on attachment 132445 [details] [diff] [review] new patch Noririty is no member of the peer group. Moving review-request over to Pierre. Pierre, can you please review?

via IRC: Pierre says that he doesn't like these about:-URLs very much. But he will bring this issue up at the next developer-meeting (beginning of next week or end of this week - don't remember correctly) and then you'll get a review+ or a review-

Thanks Simon. Targetting worked for 0.7: Ben went through the list, reviewed the patches and checked them in. :-) I thought the blocking flag was for real release blockers.

Comment on attachment 132445 [details] [diff] [review] new patch mozilla/toolkit/jar.mn is no more. I'll make a new patch shortly.

Same as before, but the file is added in mozilla/toolkit/content/jar.mn.

Comment on attachment 135569 [details] [diff] [review] unbitrotted patch Pierre, please review.

Comment on attachment 135569 [details] [diff] [review] unbitrotted patch mozilla/toolkit/content/jar.mn has just changed. I need to make it consistent.

Comment on attachment 135593 [details] [diff] [review] unbitrot again Steffen: I am sorry not having told you before. We discussed this issue during our last meeting and decided that the benefit/overhead ratio was too low...

-> won'tfix

verified wontfix.

Removing blocking0.8? flag.

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

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

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

(In reply to comment #24) > *** Bug 269430 has been marked as a duplicate of this bug. *** Can we get this re-classified as minor, instead of won't-fix? And why was it removed (or was it "forgotten to be copied over") in the first place? Anyway, if we're going to list some, like about:config, as debugging aids on the Mozilla web site, then we should maintain a master list somewhere. And as I said in 269430, a self-generated list within the FireFox program never gets stale.

I agree with the last comment. Marking this as WONTFIX is absurd as the patch is there, the feature is wanted. I have ample evidence of people actually using this: one possible reason is that they can't remember whether it's "about:config" or "about:preferences" or "about:prefs" or "about:configuration" or "about:setup" or something like that, whereas "about:about" is easy to remember; it's also very useful if you suspect something might be in about:foobar but aren't sure of what foobar that would be. Surely the cost, or overhead, of this feature is minuscule: how is it possible that the benefit/overhead ratio is low?

And incidentally, the fact that this bug has ben dup'ed three times is obvious proof that the users wish for that feature to be present.

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

I see several duplicates of this "feature enhancement". The patch seems already functional, but a decision was taken as "won't fix". No details given :-?. Please, vote this bug. Would you possibly reconsider the "won't fix" decision?. Stephen, please :-)

In the meanwhile I have to use http://en.wikipedia.org/wiki/About: :-p

If you use the previous link, *INCLUDE* the final colon (":") in the URL. Sorry by the spam.

re: comment 26; Just because there's a patch, and just because there are duplicates and votes for the bug does not make it an "obvious" feature. The about: dialogs are not intended for anyone but advanced users, and in many cases expose loaded weapons that can be accidentally fired in a way that hoses a user's browser. To make this a feature, make a case for why it's needed in the UI, and why creating an easier way to get at those dangerous options and tools is a tradeoff we should be willing to take. Until then, make it an extension if you find yourself actually needing all of the about:* entries that frequently.

(In reply to comment #32) > about: dialogs are not intended for anyone but advanced users, and in many > cases expose loaded weapons that can be accidentally fired in a way that hoses > a user's browser. Um, no. In precisely one case, about:config, a URL that's much better known than about:about. Not having about:about to hide about:config is security by obscurity. If you have an about:about, and special-case the link to about:config to have some warning text, then you are *better* off. Beyond that, the use-case is in comment 25 - a single URL to remember, rather than searching up the Wikipedia URL from comment 30, remembering that it's generally both incomplete and incorrect but hoping that it still links to the kb.mozillazine.org page, which is slightly less incomplete, but links to nsNetModule.cpp, where any user can find out the about: URLs they can use, by reading the C++ source. Note also bug 349451: on the trunk, we no longer do nothing with about:about, we show an ugly "Firefox can't find the file at jar:file:///Applications/Firefox.app/Contents/MacOS/chrome/toolkit.jar!/content/global/aboutAbout.html." error page. So we need to do something with aboutAbout.html, and having a normal about:about is the most reasonable thing to have there.

(In reply to comment #18) > (From update of attachment 135593 [details] [diff] [review]) > Steffen: I am sorry not having told you before. We discussed this issue during > our last meeting and decided that the benefit/overhead ratio was too low... > I don't really get the thinking here, given the existence of about:robots! How can you justify including that, but not including something that would actually be quite useful!

Just my two cents, however obscure about:foo is, about:about would be just as obscure, i.e. the same people will get to know both URL's, so can't see the danger in implementing, especially now that there's a clear warning for config, the rest of the abouts are more or less harmless.

Voting... This is too useful to ignore.

Just download and install Opera 9.5 and write opera: in the address bar. There you have a great implementation of the "about:" feature. Also notice how opera:about will show you all the paths for different portions of the program like plug-ins, profile, bookmarks and so on. What do I have to do in Firefox if I want to find out where my profile or plug-ins folder is? Go to a search box on a Web page, this sucks.

I have implemented this feature in my own builds and I find it great. Reasons for: - I agree with Natch, this would only be found by the same ones finding the other about:foo urls, most likely even less people. - The other apps want this, only Firefox does not. If implemented this could be moved to toolkit and it would make the switch to toolkit easier for SeaMonkey. - Not having it leaves a ugly error page. - The easter eggs about:mozilla and about:robots could be made hidden on the list. - About:config shows a warning, so it should not endanger the user more than it already does, but it could be hidden if needed. - About:robots was added, which has no useful purpose while the other about: urls and this about: do have a useful purpose. At least about:mozilla shows some of the history of Mozilla. - It is smaller in size than some other about: urls.

Related bugs: Bug 56061 is the original implementation for xpfe. Bug 349451 removed the about:about redirector. To fix this bug, we need to either undo that, or implement our own redirector just like bug 363491 attachment 251448 [details] [diff] [review] did for Seamonkey, but that's 128 lines of js instead of 6 lines of c++...

Since this bug was WONTFIXed 5 years ago in comment 19, we've added quite a lot of new about pages: blocked, certerror, crashes, feeds, licence, license, neterror, privatebrowsing, rights, robots, sessionretore. That's 21 right now. So about:about got much more useful since then. For example, to tell users that we've introduced about:crashes, which isn't linked from anywhere else. Reopening.

This builds on http://mxr.mozilla.org/comm-central/source/suite/browser/aboutAbout.html?force=1, ports it to XHTML and the new about: design I introduced in bug 328563, and replaces the table with a multi-column list (since the table didn't fit on my screen).

The font-size could be larger perhaps.

Still not seeing how the WONTFIX reasoning has changed between then and now. The MNG bug is still WONTFIX, and that's never going to change, so I don't see why this will change either.

Well, let's see: bug mng was wontfixed by the current module owner going on two years ago, because it was a lot of code to support a image format that never caught on; this was wontfixed when (according to owners.html, anyway) hyatt owned Firebird, though it would have been discussed with his peers, pch, bryner, blake and ben, none of whom have been involved for several years, because 3543 bytes was too much bloat for the about: URIs that the developers didn't much like. Since then, Firefox has gone from a 6+MB Windows installer to under 5MB to a time when it was a severity: blocker bug to have the Windows installer go over 5MB to a time when having a 7.5MB installer is just fine. Since then, Firefox has driven the addition of about:blocked, about:certerror, about:crashes, about:feeds, about:privatebrowsing, about:rights, about:robots, and about:sessionrestore: Firefox developers now *love* them some about: URIs, and will include nearly three times the "overhead" that was too much for this for a 64x64px image of a robot. Since the comment 32 reiteration of wontfix because about: URIs are dangerous, about:config, the only one that could possibly let you hose your browser, has sprouted a warning label, which as I said at the time is far more likely to make people think twice about messing with prefs than not having about:about would. But probably the most significant difference between Firebird then and Firefox now is that then the manifesto called for getting rid of both anything remotely geeky in the UI (view-source? toss it! page info? bloat! error console? no way!) and everything related to marketing, and then magically having ordinary users magically decide to use it, while now there's a much better understanding of how powerful a marketing tool it can be to have a few not-in-the-way geeky features that make web developers and geeks think it's better than sliced bread, and they should install it for all their relatives and everyone they know.

Comment on attachment 354044 [details] [diff] [review] another try, 5 years later >+ function findAbouts() { >+ for (var cid in Components.classes) { >+ var result = cid.match(/@mozilla.org\/network\/protocol\/about;1\?what\=(.*)$/); >+ if (result) >+ gProtocols.push(result[1]); >+ } >+ gProtocols.sort(); >+ for (var i in gProtocols) >+ createProtocolListing(gProtocols[i]); >+ } While I like the idea of not having to remember to add new about: pages to about:about, I think that listing useless about: pages (feeds, neterror, etc) runs counter to the intent of this bug, which is providing an index of useful power-user/developer facing control pages. We should probably be explicit about which about: pages are listed in this index, or have some way of hiding the ones that are useless. >+<body> >+ <h1>About About</h1> >+ <p><em>Note: not all of the following URIs may be useful as listed. For instance, some may require query strings.</em></p> >+ <ul id="abouts" class="columns"></ul> <h1>What would you like to know about?</h1> <p>These "about:" pages contain diagnostic information that you may find helpful, interesting, or confusing.</p> I was sorely tempted to go for <h1>What'chu talkin' about, Willis?</h1>

But who will decide which page is useful and which page is useless? Furthermore, anyone knows that any human-maintained list will necessarily end up out of sync. The list needs to be automatically generated, and needs to come from inside the browser, to match the exact version and build options of the browser.

If an about: page doesn't show anything without parameters, it is useless to list in this index.

Perhaps just iterating over everything and excluding those that aren't useful would be acceptable? That way, this won't need any updating every time an about: page lands, and when an about: page that isn't useful lands, worst thing that can happen is that it shows up on this page...

That solution (show all except pages that are manually tagged as useless) is indeed infinitely better than the other way around. But I still think that some page that seems useless to most people may be really useful to a few people. Why not keep the things simple in the browser: a simple complete list, and maybe in the text at the top a link to the documentation for the useful ones.

re: comment 49 - yes, which is what I mentioned in my review. Listen, everyone. If this feature, which is of questionable use in the first place, is to land, then it should land for a reason. "Because the code is written" is not a good reason. The only compelling reason that I've heard for including this is so that people can get an index of the interesting about: pages which may be helpful, not so that they can have a full index of the ones that are used by various areas of the product. Including things like about:neterror and about:cache-entry is not helpful. Period.

In my opinion, the point of an about: page is to reflect the internal state of the browser. An about:about page that gives a static list of about: pages that someone deemed useful is totally useless, it could as well be on the web. To be of any interest, the about:about list must be generated from the internal data structures of the about: handling subsystem. Now, if someone wants to put effort to hide some pages that are, probably, really useless, well... I just think this is wasted effort. I mean, yes, about:neterror is not helpful, but it is not harmful either. Building a complete list from the is helpful from the internal data structures is in itself helpful, because it is guaranteed not to forget anything. And it is _simple_: it's a single loop somewhere in the code, and nothing else anywhere; and once it is written, there is virtually no maintenance required. Any other solution requires maintenance.

I agree. Any 'about:about' that doesn't list all 'about:' pages is not doing its job, in my view, and as other posters have noted will cause maintenance problems as new pages are added/old ones removed. There should not be a problem with pages that do not give meaningful output without parameters. These pages should be outputting error messages if used incorrectly, which tell the user what went wrong (e.g. "No 'URL' parameter supplied to the page - unable to generate any information"). I am aware that this is not currently the case, however, so in the short term they should perhaps be flagged up on about:about. To me the best method would be to have a place to store optional meta-data about each about page (either a central store, or with the individual about pages themselves). However this data is optional and is not used to generate the list - rather the list of pages is generated from the actual list of pages, and if any of the optional data is present then it will be used along with the page name when creating the entry on about:about. If there is no meta-data at all, you end up with a list of links of the form <li><a href="about:config">about:config</a></li>. The obvious meta-data that would be useful would be a 'description', which gives you a bit of info about the page, and which would be output after the link (if present). There could also be a 'needs_params' flag, which if present and set will put the page in a separate smaller list at the bottom, with a note indicating that the following pages exist but do not do anything useful without passing in parameters. Other flags could be added, if useful, e.g. 'ui_alert' for pages which are simply alerts to be shown to the user. I think you get my point. No meta-data is required (so no problem with forgetting to add it). Meta-data for pages that don't actually exist is ignored (so no problem if you forget to remove it when a page is removed). The meta-data can be whatever is needed to make about:about more user-friendly, so should satisfy any objections about the utility of the page (e.g. comment 48). However the page functions fine without it, so the data and mechanisms for utilising it can be added iteratively if it is too much work to do this all at once.

Dynamically generating the list and removing a few specific pages using a blacklist built into aboutAbout.xhtml covers future additions and add-ons like about:accessibilityenabled, about:kitchensink, about:kittens, about:me, about:memory, about:tab, etc. The blacklist only requires a little maintenance when another useless-without-arguments about page is getting shipped. Candidates for the blacklist are: 1. about:blank (useless) 2. about:cache-entry ("The cache entry you selected is not available.") 3. about:certerror (which looks ok, but says "You have asked Minefield to connect securely to #1", and has an empty "Technical Details" section) 4. about:feeds (completely broken) 5. about:neterror (completely broken) That still leaves us with 17 pages. I was tempted to argue to add a second listing for those 5 useless pages, but couldn't find a reason other than geeks demanding a proof for their uselessness. And geeks can hit Ctrl+U on about:about and read its built-in blacklist.

(FTR, Steffen's comment 51 just saved this bug from getting WONTFIXED again) I'd suggest adding: about:blocked (doesn't render properly without the parameter) about:privatebrowsing (already available through tools menu) I'm also tempted to add about:sessionrestore as it can lead to a hoarked state, but I can see it as a potentially useful backdoor to re-restoring your last session.

(In reply to comment #55) > about:blocked (doesn't render properly without the parameter) That page works pretty fine, including the two buttons, except for the missing url and the "ignore warning" link, but you shouldn't click that anyway... It's useful to know how that page looks like in case your friends/relatives mention a scary red page to you... > about:privatebrowsing (already available through tools menu) about:privatebrowsing is actually a different page. It says: "Would you like to start Private Browsing? Minefield is not currently in Private Browsing mode." So that's a description of Private Browsing, whereas the option in the Tools menu starts Private Browsing right away. I'd rather remove that page altogether... > I'm also tempted to add about:sessionrestore as it can lead to a hoarked state, > but I can see it as a potentially useful backdoor to re-restoring your last > session. Agreed.

(In reply to comment #56) > (In reply to comment #55) > > about:blocked (doesn't render properly without the parameter) > That page works pretty fine, including the two buttons, except for the missing > url and the "ignore warning" link, but you shouldn't click that anyway... > It's useful to know how that page looks like in case your friends/relatives > mention a scary red page to you... http://www.mozilla.com/firefox/its-a-trap.html and http://www.mozilla.com/firefox/its-an-attack.html exist as demonstrations of the functionality, and work properly with the exception/pass-through notification. When I look at about:blocked it looks like this: http://www.grabup.com/uploads/35ed508fc56a5631a71d28459e7af429.png which has both the malware and the phishing warnings on a single page, and looks strange to me. > So that's a description of Private Browsing, whereas the option in the Tools > menu starts Private Browsing right away. > I'd rather remove that page altogether... Yeah, that page is what's shown when you start private browsing (the content changes on the mode). I guess I'm OK to leave it, actually. Doesn't really add a lot, but it's not useless, I suppose.

Oops, didn't read closely enough on about:blocked. That's broken indeed. So I'll remove that, and keep about:privatebrowsing.

const kBlacklist = ["blank", "blocked", "cache-entry", "certerror", "feeds", "neterror"]; I also dropped the note.

The value of about:about in the list is questionable as well...

Comment on attachment 397358 [details] [diff] [review] patch with blacklist Requesting review as well. I've locally changed + if (result && (kBlacklist.every(function (element) result[1] != element))) to + if (result && (kBlacklist.indexOf(result[1]) == -1)).

Comment on attachment 397358 [details] [diff] [review] patch with blacklist When I read the title, I thought, "I'm not a Firefox peer, this doesn't apply to me". In going to cancel the review I then read the patch, and lo and behold this is about adding about:about to libxul, which is another kettle of fish, and I don't think I'm qualified to approve that either...

Comment on attachment 397358 [details] [diff] [review] patch with blacklist This is fine, though I really would prefer the strings explaining what the page is, and warning that the contents of the pages listed herein might be confusing are are for diagnostic purposes only.

We've got 2 new about pages: memory and support! I added the following note per comment 64: This is a list of “about” pages for your convenience. Some of them might be confusing. Some are for diagnostic purposes only. And some are omitted because they require query strings.

Comment on attachment 405915 [details] [diff] [review] address comments 62 and 64 >+ var gProtocols = new Array(); [] >+ const kBlacklist = ["blank", "blocked", "cache-entry", "certerror", "feeds", "neterror"]; const BLACKLIST >+ window.onload = Start; >+ >+ function Start() { window.onload = function () { >+ <h1>About About</h1> >+ <p><em>This is a list of âaboutâ pages for your convenience.<br/> >+ Some of them might be confusing. Some are for diagnostic purposes only.<br/> >+ And some are omitted because they require query strings.</em></p> Why is this not localized?

Thanks for the comments. I wasn't sure about the note in general when I wrote the last patch, but now it's localizable, and the title/header as well.

(In reply to comment #67) > Created an attachment (id=409498) [details] > comment 66 addressed I think aboutAbout.dtd is missing in the latest patch.

Comment on attachment 409516 [details] [diff] [review] missing aboutAbout.dtd ui-review has already been done, right?

Indeed, but on a patch without the 3-line note, see comment 64 and comment 65.

Fixed: http://hg.mozilla.org/mozilla-central/rev/f405075062de bz gave his ok over IRC, provided I file a follow-up for Seamonkey (bug 538419) and a bug for adding a nsIAboutModule flag for hiding pages instead of the hardcoded list (bug 538421).