Closed Bug 232773 Opened 16 years ago Closed 14 years ago

Selecting "about:" url from the URL bar history prepends "www.", adds ".org"

Categories

(Firefox :: Address Bar, defect, minor)

defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: thesh_bugs, Assigned: hewitt)

References

Details

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:)
Summary: Selecting about: from the URL bar history causes firebird to do a keyword search → Selecting "about" url from the URL bar history causes firebird to do a keyword search

*** This bug has been marked as a duplicate of 184814 ***
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → DUPLICATE
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".
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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/
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.

Summary: Selecting "about" url from the URL bar history causes firebird to do a keyword search → Selecting "about:" url from the URL bar history prepends "www.", adds ".org"
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). 
Blocks: 220229
> 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.
Blocks: 232617
No longer blocks: 232617
Depends on: 232617
moved dep up to head bug 220229, since that's where the patch suggestion is.
No longer blocks: 220229
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)
Status: NEW → RESOLVED
Closed: 16 years ago14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.