Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a4pre) Gecko/20100329 Minefield/3.7a4pre Bug 480350 made it so that autocomplete suggests switching to a tab whose URL matches the one currently typed in the location bar. While this may be useful, it will also suggest switching to the current tab, which is kind of pointless, I think. 1. Visit a common URL, like https://bugzilla.mozilla.org/ 2. Type "bugzilla" into the location bar 3. Firefox suggests to switch to the current tab

Displaying the text "Current Tab" instead of "Switch to Tab" would be more informative to the user.

case which is useless and annoying to me, might also confuse normal users: 1. open new empty tab 2. start typing "about" (or less, of course) in location bar -> always suggests to switch to current tab, which is about:blank

After all this time, I still find this annoying, doubly so on a new tab. Can we block on this?

I don't think this blocks. Mildly curious behavior that doesn't come close to causing real problems does not a release hold back. blocking-.

This bug makes it impossible to remove a page from the history quickly. Very annoying.

in bug 582703 we are moving the switch to tab APIs to the locationbar implementation. At this point could be easy to add a API to register the current topmost tab, so that locationbar can discard it.

I encountered this ridiculous bug today. I was at domain.com/this_page.htm and knew of other pages I'd been to on that domain so I deleted this_page.htm and Firefox's top suggestion to me was to switch to...my current tab. Not only does this waste my time and effort, but it does not show the URL and so one may not recognize that this is their current tab and try to switch to it. Some users may be quite confused "that nothing happened". Changing the text to "Current Tab" is informational like telling someone the sky's blue. Technically accurate, but obvious and unhelpful.

Would it be hard to fix? It seems like such a small change Because to be honest its constantly annoying. I very often have to step one more than expected. Plus its totally useless. And the bug is approaching its first birthday...

It also prevents from deleting the url from history as I mentioned in Bug 636992 So fixing this bug will actually fix two bugs. Kill two birds with one stone.

Marco, can you give slightly more detail about what this needs/where this needs to be fixed? I don't have much experience with the larger Firefox codebase, but this seems like a good first bug (I could use a mentor, though).

(In reply to comment #16) > Marco, can you give slightly more detail about what this needs/where this > needs to be fixed? I've sent you a mail with some information.

Fwiw, this is not a good-first-bug, indeed it's pretty tricky to figure out a strategy, but you're free to try or others could suggest one. In the mail I've suggested better bugs you could have fun fixing, thus why I didn't directly post here the content of the mail, it would have been off-topic.

Yes, thank you! Apparently the salient problem is figuring out a strategy for having the autocomplete backend know what the current tab is. It seems to me there would be two possible ways of implementing that: (a) either the browser could call into the backend every time the active tab is switched, or (b) the backend should have a way of querying the browser what the active tab's location is. Supposedly it's implemented the way it is because we don't want the autocompleter backend know about the browser? In which case (b) is undesirable, leaving (a). So I suppose that, similar to registerOpenPage() there could be something like registerActivePage()?

(In reply to comment #19) > (a) either the > browser could call into the backend every time the active tab is switched this could be tricky with multiple windows. > or (b) the backend should have a way of querying the browser what the active > tab's location is maybe, but it's usually wrong to have toolkit query browser for something. toolkit components can be used in different applications than browsers. I was thinking of the possibility to filter this out somehow in the locationbar popup (e.g. present it as a common entry even if it is returned as a special entry), but again that popup is driven by toolkit autocomplete.xml

(In reply to comment #20) > this could be tricky with multiple windows. Ah. So is there some kind of window identifier we can send along?

(In reply to comment #20) > this could be tricky with multiple windows. Not really. You can have code run when you gain/lose focus.

Build ID: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0a1) Gecko/20110815 Firefox/8.0a1 Is there an update to this bug? The issue (with the steps in the Description) is still reproducible on all the channels including the latest Nightly.

Why so serious ... bug this is? I read the problems above and I still think it should not be hard to fix (for people who know the code). Just decide on one thing and fix please! I infer from the above discussion that suggestion (a) is probably not that dangerous.

AFAICS, the current behaviour is: - when entering an (in another tab/window already opened URL) you are suggested the swtich - when the "swtich to" is selected, but Alt+Enter is used,.. a new tab is opened (as requested by this bug). I would suggest that the above is just switched: I.e. default = open new, Alt+Enter = switch This sounds even more reasonable IMHO, because when a user would want to reuse the already existing tab/window,.. he could also just click/Alt+Tab/etc to it, probably with even not more keystrokes or clicks needed. Which is why as of now, entering an already opened address in the bar, rather duplicates normal window/tab switching functionally, for which it is not meant to. So the "switch to" function should better be the non-standard use-case i.e. the one with a modifier like Alt.

Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/559ec6828d6d Address bar should not suggest switching to the current tab. r=harry