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

RESOLVED WORKSFORME

Status

()

Firefox
Address Bar
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: tnikkel, Assigned: Unfocused)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [switch-to-tab])

Comment hidden (empty)
(Reporter)

Comment 1

8 years ago
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.
Summary: awesome bar produces "switch to tab → awesome bar produces "switch to tab" result for tab that is not open
Potentially fixed by bug 546253.
Depends on: 546253

Updated

8 years ago
Depends on: 584658

Comment 3

8 years ago
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)
Keywords: qawanted
(Reporter)

Comment 5

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

Comment 6

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

I can still reproduce the bug using the steps above.

Updated

8 years ago
OS: Windows 2000 → All
Hardware: x86 → All
Version: unspecified → Trunk
(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

8 years ago
(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.
I saw an incorrect Switch to Tab this morning, but I don't have a consistent STR.
(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
(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.

Updated

8 years ago
Whiteboard: [needs consistent steps to reproduce]
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

8 years ago
reproduced with Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre
blocking2.0: --- → ?

Comment 14

7 years ago
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

7 years ago
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
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.
blocking2.0: ? → final+

Comment 17

7 years ago
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

Updated

7 years ago
Duplicate of this bug: 598403
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.
Keywords: qawanted
Whiteboard: [needs consistent steps to reproduce]
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

7 years ago
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.
--> 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!
Assignee: nobody → bmcbride
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.
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.
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

7 years ago
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?

Updated

7 years ago
Duplicate of this bug: 611482
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.
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.
blocking2.0: final+ → betaN+
Is anyone seeing this now because of a tab being in another tabcandy group like bug 605710?

Comment 31

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

Comment 32

7 years ago
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.
Status: NEW → ASSIGNED

Comment 33

7 years ago
(In reply to comment #32)

Actually mine is a different problem: the tab is open but switch-to-tab doesn't switch to it. :(
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.
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.
Duplicate of this bug: 612639

Comment 37

7 years ago
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

7 years ago
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
Please file a new bug?
(In reply to comment #39)
> Please file a new bug?
And by this, gavin means "Please file a new bug!"

Comment 41

7 years ago
(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.

Updated

7 years ago
Blocks: 560198
Whiteboard: [softblocker]
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.
Keywords: qawanted
Whiteboard: [softblocker] → [softblocker][needs help finding steps to reproduce]
(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.
I haven't seen this problem lately.
Duplicate of this bug: 628777

Updated

7 years ago
Duplicate of this bug: 618735

Comment 47

7 years ago
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.
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.
blocking2.0: betaN+ → ?

Comment 49

7 years ago
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.
(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

7 years ago
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.
(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.
Agreed with Dietrich; if we get reliable STR, please renominate.
blocking2.0: ? → -
Whiteboard: [softblocker][needs help finding steps to reproduce] → [needs help finding steps to reproduce]
Whiteboard: [needs help finding steps to reproduce] → [needs help finding steps to reproduce][switch-to-tab]
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Whiteboard: [needs help finding steps to reproduce][switch-to-tab] → [switch-to-tab]
You need to log in before you can comment on or make changes to this bug.