558626 - awesome bar produces "switch to tab" result for tab that is not open

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect)

Comment 1

[Timothy Nikkel (:tnikkel)]

When I try to select that result nothing happens. The specific website was a Zimbra inbox if that matters. I do not have steps to reproduce.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Potentially fixed by bug 546253.

Comment 3

[Christian Ascheberg]

steps to reproduce:
1. set browser.tabs.closeWindowWithLastTab = false (!)
2. open webpage (for example: http://www.einslive.de/)
3. open javascript popup from webpage (for example by clicking "Webradio")
4. close popup
5. open new tab, search for popup in awesome bar
-> closed popup will be displayed as a result

(I've seen some strange bugs with browser.tabs.closeWindowWithLastTab = false recently)

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Was this fixed by bug 546253?

Comment 5

[Timothy Nikkel (:tnikkel)]

I notice it happening so rarely that I doubt I'll be able to confirm that this is fixed.

Comment 6

[Christian Ascheberg]

(In reply to comment #4)
> Was this fixed by bug 546253?

I can still reproduce the bug using the steps above.

Comment 7

[Marco Bonardo [:mak]]

(In reply to comment #6)
> (In reply to comment #4)
> > Was this fixed by bug 546253?
> 
> I can still reproduce the bug using the steps above.

I have tried your steps in comment 3 in latest nightly, and while the page appears in the awesomebar (correct) it's not marked as a switch to tab result here. Please provide better steps if you can still reproduce on current nightly build.

Comment 8

[Christian Ascheberg]

(In reply to comment #7)
> I have tried your steps in comment 3 in latest nightly, and while the page
> appears in the awesomebar (correct) it's not marked as a switch to tab result
> here. Please provide better steps if you can still reproduce on current nightly
> build.

The particular steps I wrote about now work for me, too. I guess it was fixed by bug 583000.
So it seems as if there is currently no way to reproduce the *original* bug anymore.

Comment 9

[Jeff Balogh (:jbalogh)]

I saw an incorrect Switch to Tab this morning, but I don't have a consistent STR.

Comment 10

[Marco Bonardo [:mak]]

(In reply to comment #9)
> I saw an incorrect Switch to Tab this morning, but I don't have a consistent
> STR.

do you recall if you did drag&drop of such tab? if so it's probably bug 589876

Comment 11

[Jeff Balogh (:jbalogh)]

(In reply to comment #10)
> do you recall if you did drag&drop of such tab? if so it's probably bug 58987

I don't think so; I don't do that too much.

Comment 12

[Justin Lebar (not reading bugmail)]

I just saw one of these too.  I don't think I dragged and dropped a tab.

Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre

Comment 13

[eyal gruss]

reproduced with Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre

Comment 14

[Ian Nartowicz]

This happens to me in Firefox/4.0b5pre, regularly enough to be annoying although not frequently, and definitely nothing to do with dragging and dropping tabs because I never do that, in fact I don't have multiple tabs at all.  It seems to relate to pages that were recently open but no longer.  Perhaps still in bfcache?  I haven't been able to reproduce it reliably.

Comment 15

[Ian Nartowicz]

Just had it again.  One window open, no tabs.  The page in question was 9 steps back in the session history.  I don't know if it helps, but it is often (nearly always?) on the same page although a page that I visit frequently:
http://www.bcss.org.uk/foruma/viewforum.php?f=1

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Ian, eyaler: if you could please come up with steps to reproduce that will work on a clean profile, it would help us a lot.

Comment 17

[eyal gruss]

i am not sure that all the following steps are necessary. however they do consistently reproduce the bug for me. 

STR:
1. open firefox with a clean profile
2. type in the location bar: "www.google.com" + enter.
3. open a new tab with new tab button
4. type in the location bar: "www.g"
5. notice that the top suggestion is switch to tab
6. highlight the "switch to tab" with mouse hover
7. move mouse out of the url drop-down menu *without* closing it
8. close first tab with middle click
9. focus is now on second tab and url drop-down menu is closed
10. press keyboard down arrow to open url drop-down menu
11. notice that the top suggestion is again switch to tab, although no such tab is open

Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100921 Firefox/4.0b7pre

Comment 19

[juan becerra [:juanb]]

The steps in comment #17 are reliable. I tried on a Win 7 machine, using the latest nightly with new profile, and I was able to reproduce the problem.

Comment 20

[Dave Miller [:justdave]]

I run into this fairly constantly, too, definitely still an issue in the current nightlies.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100926 Firefox/4.0b7pre

Comment 21

[David]

I can reproduce this bug consistently.  My symptoms: Whenever I go to facebook.com (and only that website for some reason), the "Switch To Tab" option always comes up, even if I have no tab with facebook open.

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Unfocused, for him to take or find another taker. Blair, let people know if there's any information they can provide that would be helpful for debugging this!

Comment 23

[Marco Bonardo [:mak]]

I think what happens in comment 17 is that when you press down, since the text has not changed, we reuse the old result that had the switch to tab entry. It's a perf optimization and could be hard to detect if a tab has been closed while the text did not change (it's also a pretty edge case).
The open page is correctly unregistered. If you type "o" then (so that you have www.go) it will recalculate results and the switch entry disappears. Imo this can't be the reason someone is seing switch to tab entries for non open tabs, since those are usually typing in the locationbar and not just pressing down on a previously typed text, or at least this is what I got.

Comment 24

[Justin Lebar (not reading bugmail)]

FWIW, I've seen this happen with a tab that I'd closed many minutes before, and without any down-arrow shenanigans.  Perhaps the STR in comment 17 don't cover the whole problem.

Comment 25

[Marco Bonardo [:mak]]

indeed, as I said, comment 17 is possibly a regression from a recent bug we fixed that allows to resuse old results if search terms didn't change.
And that's not the bug we were looking for.

Comment 26

[Ian Nartowicz]

I'm sorry I still can't reproduce this but it happens several times a day.  Usually it never fixes itself until I close the browser, but just once a page which was showing "Switch to tab" later came up normally.  Or maybe I imagined it?  There are certainly ways of reproducing this without going through all the steps in comment 17, but other strange ways I've tried to close out an active dropdown don't seem to cause it.

On a related issue since I've already bug-spammed everyone, is it supposed to display "Switch to tab" when the relevant page is already the the active tab that I'm staring right at?

Comment 28

[Colin Barrett [:cbarrett]]

FWIW I'm still seeing this bug and it's quite annoying. I'm happy to help in whatever way, providing a places.db, VNC access, etc.

Comment 29

[Justin Lebar (not reading bugmail)]

I just restarted FF to install the latest nightly build, and some tabs popped up which I'm pretty sure I'd closed a while ago.

I wonder if this is related to the switch to tab issue.  That is, I wonder if the tabs that switch to tab is incorrectly suggesting you switch to are loaded after a session restore.

I'll try to test this the next time I see this bug, but maybe someone else will see it first.

Comment 30

[[not reading bugmail]]

Is anyone seeing this now because of a tab being in another tabcandy group like bug 605710?

Comment 31

[Chris Mounce]

I am also experiencing this issue. I am not using tabcandy/panorama. Using 4.0b7 on OS X 10.5.8.

Comment 32

[Drew Willcoxon :adw]

Probably not helpful, but I just encountered this and dumping moz_openpages_temp shows that it contains the URL for the no longer open tab with an open_count of 1.

Comment 33

[Drew Willcoxon :adw]

(In reply to comment #32)

Actually mine is a different problem: the tab is open but switch-to-tab doesn't switch to it. :(

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I see this a good bit, particularly with https://www.google.com/reader/view/  and http://tbpl.mozilla.org/, both of which are pages I use a good bit, occasionally reload by hitting enter in the URL bar while they're already loaded.  (Right now I'm in a session where I see it with google reader.)

I confirmed that I could get google reader completely out of my sessionstore.js (not in _closedTabs, etc.) by opening and closing additional tabs in the window that had previously had google reader in it, and I still see the problem where google reader shows up as a "Switch to tab" option.

Comment 35

[Marco Bonardo [:mak]]

Drew, if you have to change registerOpenPage/unregisterOpenPage calls, I suggest you to clone code from the Places branch and do changes on top of it, we had to change that code to move it to the autocomplete idl (thus also the tabbrowser calls are different), so you could end up bitrotting easily doing otherwise.
If this ends up being missing calls to other tabbrowser methods, than most likely this won't be a problem.

Comment 37

[Seth Spitzer]

like David in comment #21, I see this with facebook.com

I'm using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

Comment 38

[Christian Ascheberg]

Note, there is a new regression: Firefox now still shows tabs that were open in non-PB mode after switching to private browsing mode.

works:
win32 2010-12-15-03-mozilla-central f11f7ed625ba
broken:
win32 2010-12-16-03-mozilla-central a5413c3c1013

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f11f7ed625ba&tochange=a5413c3c1013

Comment 39

[:Gavin Sharp [email: [e-mail]]]

Please file a new bug?

Comment 40

[Shawn Wilsher :sdwilsh]

(In reply to comment #39)
> Please file a new bug?
And by this, gavin means "Please file a new bug!"

Comment 41

[Christian Ascheberg]

(In reply to comment #40)
> (In reply to comment #39)
> > Please file a new bug?
> And by this, gavin means "Please file a new bug!"

I thought so ;)
I am not sure if my comment was a bit misleading, I commented here because it was about the same topic.
Now I filed bug 620290.

Comment 42

[Marco Bonardo [:mak]]

Unless somebody can help us finding decent steps to reproduce, I think fixing this will end up being hard like teaching my cat to code.

Comment 43

[Fred Wenzel [:wenzel]]

(In reply to comment #42)
> Unless somebody can help us finding decent steps to reproduce, I think fixing
> this will end up being hard like teaching my cat to code.

I was experiencing it with Firefox 4.0b9 today so I tried to reproduce it on a fresh profile and couldn't. However, I have the BarTab extension, and sure enough, after installing it I could consistently reproduce this in conjunction with private browsing.

STR:
- Fresh profile.
- Install BarTab 2.0: https://addons.mozilla.org/en-US/firefox/addon/bartab/
- Go to a memorable website, say facebook.com
- switch to private browsing mode (all tabs vanish, an empty one appears)
- enter "face" -> notice "switch to tab: Facebook" being offered.
- choose that entry from the list, confirm. Notice the awesomebar closing, nothing else happens.
- leave private browsing mode. Your former tabs (including facebook) reappear.
- open a few tabs, *close* the facebook tab.
- enter "face" into the awesomebar.
- notice "switch to tab" being offered, even though there is no facebook tab to go to.

CCing philikon to fix the extension, but I hope if there is (also?) a bug in Firefox, these STR help you figure it out.

Comment 44

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I haven't seen this problem lately.

Comment 47

[George Carstoiu]

Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre

I was unable to reproduce issue following the different STR presented as comments.

Comment 48

[Dietrich Ayala (:dietrich)]

I propose removing blocking status from this bug. There are no reliable STR, reproduction is extremely difficult, and the incidence rate seems to be very low.

Comment 49

[George Carstoiu]

Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre

I was able to reproduce issue with the following STR:

1.Open Minefield with clean profile
2.In one tab load www.google.com
3.In second tab start writing www.goo (Switch to tab should appear)
4.Without pressing enter, close first tab with mouse scroll button
5.Click in the awesome bar and without typing anything else, press down arrow.

Steps to reproduce indicate low occurrence rate.

Comment 50

[Marco Bonardo [:mak]]

(In reply to comment #49)
> 1.Open Minefield with clean profile
> 2.In one tab load www.google.com
> 3.In second tab start writing www.goo (Switch to tab should appear)
> 4.Without pressing enter, close first tab with mouse scroll button
> 5.Click in the awesome bar and without typing anything else, press down arrow.

this seems to just indicate results re-use (the search string did not change)

Comment 51

[George Carstoiu]

Changing in any way the string results in the disappearance of "Switch to tab". 

For example when returning to the awesome bar before pushing the down button, you type an extra character from the address, then you will not get "Switch to tab" anymore.

Comment 52

[Justin Lebar (not reading bugmail)]

(In reply to comment #49)
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre
> 
> I was able to reproduce issue with the following STR:
> 
> 1.Open Minefield with clean profile
> 2.In one tab load www.google.com
> 3.In second tab start writing www.goo (Switch to tab should appear)
> 4.Without pressing enter, close first tab with mouse scroll button
> 5.Click in the awesome bar and without typing anything else, press down arrow.
> 
> Steps to reproduce indicate low occurrence rate.

While this may be one way to reproduce the bug, people have seen it under other circumstances, so I don't think we can extrapolate from the STR to the occurrence rate.  For instance,

(From comment 15)
> One window open, no tabs.  The page in question was 9 steps
> back in the session history.

That said, I used to see this all the time, and now I don't.

Comment 53

[Mike Beltzner [:beltzner, not reading bugmail]]

Agreed with Dietrich; if we get reliable STR, please renominate.

Comment 54

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Haven't seen any additional reports in months, and various people who could once reproduce this no longer can. So it seems to have been fixed by one of the other switch-to-tab bugs.