Closed Bug 232617 Opened 19 years ago Closed 19 years ago

Location Bar dropdown loads new tab

Categories

(Firefox :: Address Bar, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ali, Assigned: bugzilla)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
OS: Linux → All
Summary: Location Bar dropdown loads new tabs on an inconsistent basis → Location Bar dropdown loads new tab
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. ***
Component: Toolbars → Autocomplete
Keywords: regression
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>
Depends on: 232773
Attachment #140729 - Flags: review?(p_ch)
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.
Blocks: 220229, 232773
No longer depends on: 232773
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
Assignee: p_ch → firefox
Fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #140729 - Flags: review?(p_ch)
*** Bug 215734 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → location.bar
You need to log in before you can comment on or make changes to this bug.