User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060820 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060820 Minefield/3.0a1 about:about is File not found error Reproducible: Always Steps to Reproduce: 1. type a "about:about" in URL bar Actual Results: error message appear File not found Firefox can't find the file at jar:file:///C:/Program　Files/mozilla.org/firefox/chrome/toolkit.jar!/content/global/aboutAbout.html. Expected Results: open /chrome/toolkit.jar!/content/global/aboutAbout.html or Alert dialog appear

Related to, but *not* a duplicate of, bug 220253 - we could avoid the 404 without being sensible enough to have a real about:about.

This still affects FF3 Beta4. Will there be a fix for this at the final release? No real showstopper, but ugly though...

Not gonna block the final release, no.

patch for fix by Paul Rouget attachment 307698 [details] [diff] [review] (bug 421280)

Yeah, I noticed that too, was going to come and submit it, but you beat me to it. Its not horrible, but still ugly...

glandium, can you re-attach your patch here and request review? Thanks!

Actually, I'm wondering... since everyone except firefox wants it, why not have it in toolkit and let firefox unregister it ?

We could call that approach "the bug 365852 solution," if not for the fact that it's already wontfixed.

Okay, so this is the patch I originally sent to #434842, with an additionnal hunk to make it more complete.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.2pre) Gecko/2008070706 GranParadiso/3.0.2pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a1pre) Gecko/2008070703 Minefield/3.1a1pre] (nightly) (W2Ksp4) (Bug still there)

I'm not sure I see why this patch makes sense. Is firefox the only thing setting MOZ_XUL_APP? Would it make more sense to remove about:about from here altogether and let apps that do want it register it? That was suggested in bug 365852 too, no? In any case, I'm clearly not qualified to review this, since I don't know what he MOZ_XUL_APP define actually means.

(In reply to comment #19) > I'm not sure I see why this patch makes sense. Is firefox the only thing > setting MOZ_XUL_APP? Would it make more sense to remove about:about from here > altogether and let apps that do want it register it? That was suggested in bug > 365852 too, no? Actually, it seems that most applications except firefox want it... I know firefox is the big boy, but i don't think that grants bothering all other applications. > In any case, I'm clearly not qualified to review this, since I don't know what > he MOZ_XUL_APP define actually means. MOZ_XUL_APP should be defined for any application using toolkit.

Personally, I would just move the aboutAbout.html file in toolkit and have it installed. If firefox maintainers really don't like this page, they can unregister it from somewhere in browser/

> MOZ_XUL_APP should be defined for any application using toolkit. In which case this patch would disable about:about for all toolkit-using apps, no? That doesn't seem to match the first part of comment 20 well.... I would be fine with adding aboutAbout to toolkit. But I'm not a toolkit peer.

Comment on attachment 322062 [details] [diff] [review] patch removing about:about I can't even set review- on that request (or review+, for that matter)...

nice to have, not a big deal either way.

still not fixed

As per bug 451909, all apps set MOZ_XUL_APP now, so let's just kill this unused code.

Reed, I'm not sure I follow. Doesn't this just remove about:about?

(In reply to comment #31) > Reed, I'm not sure I follow. Doesn't this just remove about:about? Yes, I thought everybody had gotten rid of their implementations for this (meaning we could just remove it), but apparently SeaMonkey still has it... should I just #ifdef it only for SeaMonkey instead?

I don't think we want an #ifdef here. We should't need an ifdef to do what comment 19 suggests. Also, see comment 20 about non-Firefox about:about impls...

I sort of thought the point of http://mxr.mozilla.org/comm-central/source/suite/browser/nsAboutAbout.js was that SeaMonkey didn't trust Firefox not to do exactly this, and so they implemented it themselves, and now removing the docshell redirect is only going to screw over Camino, and only if they move to mozilla-central rather than going to WebKit.

Yeah, if the patch doesn't break seamonkey, and if xulrunner apps (which is what I assume Mike Hommey was talking about) don't care, then it's fine.

(In reply to comment #35) > Yeah, if the patch doesn't break seamonkey, and if xulrunner apps (which is > what I assume Mike Hommey was talking about) don't care, then it's fine. What XULRunner apps (besides SeaMonkey) implement about:about? I don't know of any... so, I think we're fine.

Comment on attachment 344013 [details] [diff] [review] patch - v1 OK, let's do this, then. Please check whether this makes aboutAbout.xhtml unused, and remove it if so (that is, if Seamonkey has forked it). Please keep an eye out for breakage.

cannot reproduce with Firefox/20081024020852-trunk/WinXP Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1b2pre) Gecko/20081024 Minefield/3.1b2pre firefox thanks for fixing this. -> v.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081024 SeaMonkey/2.0a2pre - Build ID: 20081024000423 Trying to browse to about:about leaves the content area blank, with the following messages in the Error Console: [X] Error: [Exception... "'JavaScript component does not have a method named: "getURIFlags"' when calling method: [nsIAboutModule::getURIFlags]" nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)" location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: addToUrlbarHistory :: line 262" data: no] Source File: chrome://communicator/content/contentAreaClick.js Line: 262 [X] Error: [Exception... "'JavaScript component does not have a method named: "getURIFlags"' when calling method: [nsIAboutModule::getURIFlags]" nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: loadURIWithFlags :: line 186" data: no] Source File: chrome://global/content/bindings/browser.xml Line: 186 The latter one happens twice. Now I'm going to test a recent tinderbox-build (maybe this nightly didn't include the fix).

(In reply to comment #40) > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081024 > SeaMonkey/2.0a2pre - Build ID: 20081024000423 > [...] > > Now I'm going to test a recent tinderbox-build (maybe this nightly didn't > include the fix). Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081024 SeaMonkey/2.0a2pre - Build ID: 20081024091143 Nope, no change. Should I REOPEN or file a specific bug for SeaMonkey?

(In reply to comment #41) > Nope, no change. Should I REOPEN or file a specific bug for SeaMonkey? Sounds like a SeaMonkey-only bug to me, so file a new bug for SeaMonkey.

(In reply to comment #42) > (In reply to comment #41) > > Nope, no change. Should I REOPEN or file a specific bug for SeaMonkey? > > Sounds like a SeaMonkey-only bug to me, so file a new bug for SeaMonkey. Filed bug 461552.

Re comment 44: possibly the dupe wasn't really a dupe, but a regression? Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090404 Minefield/3.6a1pre, i'm getting a "The URL is not valid and cannot be loaded". Can anyone please check if this still works or if this has regressed?

That is precisely what you should get: the fix was to make about:about just like about:foopygoats, because neither one is supported in Firefox. Bug 469896 was filed about 3.0.x, where this wasn't and won't be fixed, so there it gives a file not found error instead of a proper (for an about: URL that isn't supported) "not valid and cannot be loaded" error.

I can confirm on 3.5