UA: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040129 Firebird/0.8.0+ When you manually type a URL into the location bar, and you then drop down the location bar menu and select a URL, Firebird should open that URL in a new tab. It does this on a very inconsistent basis. Steps to reproduce: 1. Open new process of Firebird on linux 2. Type in the location bar the URL of a page that you have never been to before 3. Click on something in dropdown URL bar Actual Result: It opens in a new tab Expected Result: Same 4. Exit Firebird 5. Open Firebird again 6. Type in location bar same URL as in Step 2. 7. Repeat Step 3 Actual Result: The page loads in same tab, doesn't open new one. Expected Result: It opens in a new tab Actual Result (on Windows): It opens in a new tab This seems to be related to some caching issue on Linux, because any URL that has been visited before does not seem to count as having been 'typed in', even if it was. The only way to get the dropdown menu in the location bar to open a new tab is by entering the URL of an unvisited page and then doing it. So even if you open a new Firebird process on Linux, and you go to 20 pages, as long as they're all cached (or in history, not sure), going to the location bar dropdown and choosing a URL there will not load it in a new tab. On Windows this problem does not happen.

Picking a URL should load it in the current tab. If you start typing an entry and then pick an auto-complete entry, it loads in the current tab. It works right in trunk Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040128 Firebird/0.7+ Broken in 01/29 trunk FB

Yup, it looks like the bug is that its actually loading a new tab, when it shouldn't. It's not just limited to autocomplete, but also to clicking on the chevron on the right hand side of the location bar and then selecting a URL. The builds didn't exhibit this behaviour as of 8:46am PST 1/28/04.

Actually, come to think of it, I'm not so sure where the bug is. The only thing that I'm sure of is that there is a bug somewhere here! Windows 2004-01-01: No tab opening behaviour from location bar Linux 2004-01-27: Broken tab opening behaviour (comment 0) Windows 2004-01-28: No tab opening behaviour from location bar Windows 2004-01-29: New tab opens when URL typed into location bar. Linux 2004-01-29: Broken tab opening behaviour (comment 0) I'm so confused!

Ok, so this only seems to happen if you type in a url and press enter and then go and pick a different URL from the dropdown. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040129 Firebird/0.8.0+

Ok, I'm not sure if I was testing it right in 1/28. I'll have to reinstall it and try again.

Ok, so the bug was there in 01/28 trunk, too.

Something changed between the time of the 8:46am PST 1/28/04 and the ftp://ftp.m.o/blah/2004-01-28-15-trunk Win32 builds that caused this new tab behaviour to occur on Windows.

this used to happen most times - for months, now from this morning's cvs it doesn't ?

Still broken for me Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040130 Firebird/0.8.0+

reproduction via a new tab and starting to type a URL and then clicking doesn't load a new tab clicking the drop-down arrow, and then a URL in the case of a tab which has already loaded a page does load it in a new tab - not the same behaviour as comment 0

pch, or any other Firebird developer: It would be really good if someone could define "working" and "correct behaviour" so that we know exactly what it is that Firebird *should* be doing on both Linux and Win32. Then, at least when we test for problems, we have a good reference point for what we know is correct behaviour. I think that right now there is some confusion as to what Firebird *should* be doing, and on if there is a difference between the "correct behaviour" on Linux and on Win32.

aebrahim: where is the ambiguity? on all platforms, every user expects that clicking on a entry will load in the current tab. bonus if the modifier keys are obeyed to load in another tab.

I see this problem on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040114 Firebird/0.8.0+, although I've actually experienced this sporadically far earlier than that.

I can't follow this bug at all, but I can say the pref browser.tabs.opentabfor.urlbar is being ignored when I think it shouldn't be. I've found my build (Gecko/20040130 Firebird/0.8.0+) is being completely consistent in it's behaviour - click with the mouse loads in a new tab always and using arrow keys and hitting enter reuses the tab always (Alt-Enter does a new tab).

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

Based on the comments and some quick testing, here's what I see. Start Firebird, choose a URL from the location bar dropdown: opens in current tab. Type in a URL in the location bar, then press the arrow to open the dropdown list. The dropdown list appears very briefly and disappears again. After that, I can get the list to drop down correctly, but from now on, any URL I choose from the droplist will open in a new tab. If I open a new Firebird window, that window is fine until I repeat the step above, at which point, it also starts opening location bar list URLs in new tabs.

(In reply to comment #16) > I can get the list to drop down correctly, but from now on, any URL I choose > from the droplist will open in a new tab. I get this behavior too including the part where the drop down list does not function correctly anymore.

Whenever a textentered event is fired from toolkit\content\global\bindings\autocomplete.xml (to browser.js), the mEnterEvent field is used. mEnterEvent starts off null and stays that way until you press the Return key inside the URL bar, it is then set to the event generated by the keypress: this.mEnterEvent = aEvent; However, next time you select an item from the URL bar dropdown, mEnterEvent still exists and still points to the previous event (though now it only contains some of the properties that aEvent did earlier and the values of those properties are not the same as they originally were). The difference between 0.7 and 0.8.0+ is that the altKey property of this "ghost" event is usually false in 0.7 and usually true in 0.8.0+, this causes BrowserLoadURL() in browser.js to open the location in a new tab in 0.8.0+. I don't have enough understanding of how JS (and the Moz event system) work to know what precisely is happening here but an easy fix is just to clear the mEnterEvent field after use, i.e.: <method name="onTextEntered"> <body><![CDATA[ var rv = this.fireEvent("textentered", this.mEnterEvent); this.mEnterEvent = null; return rv; ]]></body> </method>

Apologies for the dependency-spam. Making this the head bug for all "weird stuff happens when I do X on the urlbar" bugs. I verified in my nearly-tip build that the attached patch resolves all dep bugs and this bug. Specific steps: 1. type in urls into urlbar (adjust to fit your environment) e.g. --> file:///e:/work/mozilla/nglayout.mk [enter] --> file:///e:/home/.profile [enter] --> about: [enter] --> each adds to history 2. type "mozilla", hit shift-enter (goes to mozilla.net) 3. click drop-down chevron, select a file:// url --> get "http://www.file:///e:/work/mozilla/nglayout.mk.org/" (bug 220229) 4. click drop-down chevron, select "about:" url --> get http://www.about:.org/ (bug 232773) Above steps produce desired behavior with the patch. I can't actually reproduce the behavior in this bug, but I believe that the patch will fix that also. I suspect that the trash event which causes this bug never retains the alt- key=true setting.

Do we know what checkin caused the regression?

No one has tracked it down. It's been in there for a long time.

There are only 18 revisions to it. Shouldn't be too hard to track down. http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/toolkit/content/widgets/autocomplete.xml

I'm pretty sure it's not an autocomplete.xml regression, the bug has been there all along (or at least since 0.7), it just wasn't exposed until sometime between 0.7 and now when the value of altKey in the old leftover event structure in mEnterEvent seems to have changed from false to true, it seems more likely that a change somewhere in the bowels of Mozilla exposed the problem, but I could be wrong.

with this official build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040131 Firebird/0.8.0+ I can repro the new tab behavior reliably: 1. type "about:" 2. type "mozilla", hit ctrl-enter 3. click chevron, choose "about:" from the dropdown. New tab pops up, ends up resolving (via IK or DG) to www.about.com. With the next win32 build I could find in the nightly archive here: http://ftp.mozilla.org/pub/mozilla.org/firebird/nightly/2004-02-05-08-trunk/ Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040205 Firebird/0.8.0+ the behavior is gone, as is all the other behavior in the dep bugs. I have a win32 box and there are only Mac and Linux official builds in between 0131 and 0205. Of the unofficial builds: 20040201-aebrahim -- has the bug 20040202-aebrahim -- has the bug 20040203-aebrahim -- has the bug 20040204-aebrahim -- no bug aebrahim's details (from the forum postings: 20040204 -- 04-Feb-2004 08:23 Wed Feb 4 00:50:56 PST 2004 20040203 -- 03-Feb-2004 07:54 Tue Feb 3 00:23:07 PST 2004 Searching bonsai between these two points doesn't show anything obvious that would cause this change in behavior.

only thing ive noticed since the name changed to "firefox" is that using the url dropdown to select a url, opens that url in a new tab instead of the current tab. I just realised the reason for this is that when the name change to firefox happened (which also changed the .exe name), the default browser no longer works because its looking for the old url, and firefox doesnt by default realise that its NOT set as the default browser anymore due to the name change (and so clicking urls from other places also has no effect and nothing happens when you click them if firebird was set as default before). by going into options and clicking set as default browser, now clicking items from the url dropdown opens them in the current tab as expected, instead of in a new tab like it was doing before i did this. may not be related because to be quite honest i dont know what this bug is meant to be, but judging by the "Location Bar dropdown loads new tab" title of the bug, it would seem this is what is happening. Slightly O/T. To be honest i dont see the point in changing the bluddy browser name every release these days, all it does is cause endless hassle and confusion for everyone concerned and isnt even a final name. would it not make perfect logical sense to have just left the name as phoenix (or even left it as firebird) until a 1.0 release when a final and permanent name could be decided?

RE comment 26, Firefox is now the official final product name. It has been trademarked by the Mozilla Foundation.

-> me

Fixed.

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