BUILD: current trunk STEPS TO REPRODUCE: (these assume that typing "bug" in the url bar gives me the bugzilla query form as the first hit): 1) Type "bug" in the url bar. 2) Hit the down arrow. 3) Hit enter; wait for form to load. 4) Partially fill out form. 5) Decide you want to also do another search. 6) Open new tab. 7) Type "bug" in the url bar. EXPECTED RESULTS: able to hit down arrow once or twice and hit enter to load the bug form. ACTUAL RESULTS: There's an entry to switch to the tab that the load in step 3 happened in, but no entry to do another load of the bug form. DETAILS: I hit this every day and curse it every time; I've just been remiss about filing.

See bug 595046 comment 3 for some related bugs. In particular, bug 596485 is blocking, and the plan is bug 596485 comment 14, which should at least allow you to use "Shift" to override "switch to tab".

The shift thing would work ok for me, yeah.

Shift is not very discoverable and is relatively slow to reach for (weak pinky finger!) and thus slows down navigation. It would be better to make CTRL+T not suggest "Switch to tab" and reserve that behavior for another keybinding.

the bugzilla example in comment 0 is spot on. I'm not keen on the solutions I see in the bugs, key combos which must be repeated on each override, though they may satisfy (the majority of) other people. I'd like a blacklist on URL substring capability. Or ability to totally disable "switch to tab", because there are add-ons which offer workflow that don't cause this problem.

I agree with comment 6 about disabling "switch to tab" for good. This is a complete disaster from a usability point of view. The user's expectation when opening a new tab (or using the address bar in an existing one) is *NOT* to be teleported to some other tab, the expectation is to stay on the tab one is already on. The current behaviour is not a feature, it is a bug and should be fixed. There is no user research (or even a single user request for that matter) that I'm aware of to justify introducing this behaviour so this is pure gold plating. As a Firefox user I find it deeply dissatisfying (well, I find it **** annoying to be frank) and I will be happy to see this go the sooner the better. Note that nothing will be lost: if I want to find an already open tab I'll browse the drop down tab list on the right hand side (LtR interface), and if I didn't realise I already had one instance open of a particular tab and open a second one... what's the big deal? just wasting a bit of memory, that's all. And if anyone is going to insist on keeping this gimmick, at least it should be done right: in the autocompletion section, the "switch to tab" section should be made a hyperlink, or alternatively say something like "press [Shift|Some other key] to switch to tab", so that the default behaviour is the less disconcerting one: to stay on the tab you currently are.

As you can see this is not: 1. a bug about disabling switch-to-tab 2. the mozilla.dev.usability newsgroup 3. a discussion forum So, please refrain from posting off-topic comments in bugs. Fwiw, what you want is bug 530209 and you can already use https://addons.mozilla.org/firefox/addon/switch-to-tab-blacklist/ to blacklist everything (Clearly this is not the right place to ask how).

In particular, as the filer of this bug, I would like to ask you to not try hijacking it. That's _incredibly_ poor form. To counter your anecdote with my own, I love the feature; it's a huge timesaver for me. It has this one quirk, which I have filed. This is not a bug about removing the feature. If you think there should be such a bug, file your own bug.

Re comment 9 - apologies if I misunderstood your bug report. As I interpret it, what you are saying is that if you use the location bar on a tab to open a URL, you expect said URL to be opened in the current tab, regardless of whether the same URL is already open elsewhere. I hope my interpretation is correct? What I am suggesting are these two options in order to achieve your expected result: 1: Eliminate "switch to tab" Result: after step 7, a second bugzilla query form is opened Advantage: Behaviour consistent with the user expectation that the location bar will set the location for the current tab. Disadvantage: Power users lose the ability to use the location bar as a "find my tabs" form. 2: Make "switch to tab" the non-default behaviour, e.g., by hyperlink or modifier key as suggested above. Result: as per above if you proceed according to the workflow you have described. Advantage: User is reminded of the presence of an open instance of target URL, and has the option to switch to it if he so desires. Disadvantage: Needs careful design of the UI so that it does not confuse unfamiliar, and especially non-technical, users. Just to clarify: I do not suggest getting rid of the feature for the sake of getting rid of it, although if I change my mind at some point that will certainly warrant a separate bug. What I am suggesting is that the simplest way to fix the bug you have reported is to revert to previous behaviour which from a user point of view is known, consistent, and reasonably intuitive, rather than introducing additional complications by way of extra key presses, blacklists, additional UI prefs, or even extensions(!) Marco, criticising a "feature" that directly causes a usability bug to be reported is not an off-topic comment, and neither is posting a user story in the absence of any known more formal usability research on the subject matter.

(In reply to comment #10) > Marco, criticising a "feature" that directly causes a usability bug to be > reported is not an off-topic comment, and neither is posting a user story in > the absence of any known more formal usability research on the subject > matter. Unless the fact this is not YOUR bug, nor a discussion forum, thus you can't jump in and say whatever you want just because the bug is about the same argument.

> I hope my interpretation is correct? It's not. Now please stop trying to hijack this bug, ok?

IIRC, the awesomebar has a special bonus for "I often type 'bug' and then select the query page". That bonus corresponds to the cases where you're most likely to have muscle memory. Perhaps we should make that bonus exceed the switch-to-tab bonus; that would fix Boris's problem without demoting switch-to-tab in other cases.

Workaround 1: create a "bq" keyword bookmark pointing to https://bugzilla.mozilla.org/query.cgi, letting you skip the awesomebar entirely. Workaround 2: create a "bs" keyword bookmark pointing to https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%s. QuickSearch really is better ;)

(Of course, if you *do* select switch-to-tab frequently for a given URL, we should remember that too and promote switch-to-tab accordingly.)

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

For what it's worth, this now worksforme, at least with my original steps to reproduce. The URL is higher-priority than the tab in the awesomebar results at this point.