User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040131 Firebird/0.7 When you type something like about:config and then go back and select it from the URL bar history dropdown causes Firebird to do a keyword search for "about:" I didn't use Firebird much, but I seem to remember Firebird 0.7 wouldn't even save about: in the history. Reproducible: Always Steps to Reproduce: 1.Type about: in the URL bar 2.See that it is in the history and select it Actual Results: Firebird does a keyword search and goes to about.com Expected Results: Either not saved the about: in the history or opened up the correct page (about:)

*** This bug has been marked as a duplicate of 184814 ***

This is not a duplicate of that bug - it is a regression from sometime after the release of Firebird 0.7. I have just re-installed the release of 0.7 and can confirm that it was working properly in that build (selecting from the URL history would bring up the correct page). Reopening.

Just tried it in one of the latest 0.8 nightly's: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040128 Firebird/0.7+ It works in that build - this bug seems to be only in the trunk builds.

This was fixed on 2004-01-28 in the trunk. *** This bug has been marked as a duplicate of 184433 ***

REOPEN: Do we have post-checkin proof this is solved? I see the problem in Firebird 0.7 on Mac OS X, and it looks like there is some problem w/ "about:config" being handed to URL bar. If that forces a DNS lookup, the result would be "file not found", not "connection refused".

NEW: Firebird must have it's own autocomplete code, because I see really weird results: w/ domain guessing off: about: -> http://www.about:.net/ about:config -> http://www.about:config.net/ This is not IK's fault, if you go to google and use "I'm Feeling Lucky", you get: about:config -> http://www.mozillazine.org/misc/about:config/

This is another result of the code in browser.js:canonizeUrl() that rewrites the URL if certain modifer keys are pressed. It was added in rev 1.161, and according to the comment it is there to help out some behavior elsewhere that automatically prepends "www." and adds ".com"/".net"/".org" if shift or alt is held down when enter is pressed. Even with the patch for bug 218447, I still see this bug. I added some debug to canonizeUrl: if (aTriggeringEvent) { dump("triggering event: "+ "shift: "+aTriggeringEvent.shiftKey+"; "+ "ctrl: "+aTriggeringEvent.ctrlKey+"; "+ "meta: "+aTriggeringEvent.metaKey+"; "+ "alt: "+aTriggeringEvent.altKey+"; "+ "relatedTarget: "+aTriggeringEvent.relatedTarget+"; "+ "button: "+aTriggeringEvent.button+"; "+ "\n"); } and it shows this when I click on "about:" in the dropdown: WARNING: Tried to get mouse button for null or non-mouse event!, file e:/work/mozilla/content/events/src/nsDOMEvent.cpp, line 864 triggering event: shift: true; ctrl: true; meta: false; alt: false; relatedTarget: null; button: 65535; I wasn't holding down any buttons, so I don't know where these modifiers are coming from. Also, shouldn't this be mouse event? What kind of event is aTriggeringEvent? Is there a better method of revealing aTriggeringEvent's properties? toSource() just prints {}. Changing summary; as Ben points out, IK isn't directly involved.

An aside; where is the code within Firebird that prepends "www" and adds a TLD when {ctrl/shift}+enter is pressed? Blake's comment suggests that canonizeUrl () is merely to keep the URLbar history in sync with some low-level fixup: revision 1.161 date: 2002/11/08 01:18:39; author: blakeross%telocity.com; state: Exp; lines: +22 -14 Fix bug that hitting ctrl+enter/shift+enter/ctrl+shift+enter to prepend/append to the urlbar url doesn't add that new url to the urlbar history. This info isn't necessary to fix the bug (which has more to do with the JS event being passed to handleURLBarCommand()) but I am curious.

also see bug 233205 for a different bug in canonizeUrl().

I bet this shares the same root cause as bug 220229. I don't want to mark this dup of 220229, since this bug has better information and a smaller testcase ("about:"). anyone mind if I mark the older bug dup of this one?

We don't know that for sure. I'll slap a dependency on it instead and then we can check back when this one is fixed. (In reply to comment #8) > An aside; where is the code within Firebird that prepends "www" and adds a > TLD when {ctrl/shift}+enter is pressed? I created a patch of sorts in bug 221161 for people who wished to change the endings. It's more of a guide than anything else, but it does tell you where to find this stuff (more or less).

> It's more of a guide than anything else, but it does tell you where > to find this stuff (more or less). I got a little confused. Based on the CVS comment, I thought that blake had added canonizeUrl() because there was some underlying ".com" suffixer that was not fixing up urlbar history properly. It turns out that he was fixing bug 177823, and moved the code from BrowserLoadURL() into the new function canonizeUrl().

the suggested patch in bug 232617 comment 18 appears to fix this bug. The aTriggeredEvent appears to be a leftover textEntered event. If I reset mEnterEvent to null, this TriggeredEvent goes away. Using {ctrl/shift}+enter with this patch seems to work as before. I will attach this patch, but I need someone who actually knows how mEnterEvent is supposed to work to review it.

moved dep up to head bug 220229, since that's where the patch suggestion is.

Patrick: re #7: That is great, if "shift: true; ctrl: true;", then I think my Mac is doing something similar, I'll try to hack my browser.js as well. in later comments, it looks like you found the code you were wondering about. I'm wondering if we should be changing the URL as string, historically by-passing the URL parser has not worked well.

On the latest trunk it now opens the correct page, however it still opens in a new tab. Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040210 Firebird/0.8.0+

(In reply to comment #16) > On the latest trunk it now opens the correct page, however it > still opens in a new tab. This probably needs a new bug, anyone has a number already? My about:config says: browser.tabs.opentabfor.middleclick true browser.tabs.opentabfor.urlbar false But the behaviour is exact opposite - middle click loads into the current tab, while selecting from history opens a new tab! (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040515 Firefox/0.8)