User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1) Gecko/20061010 Firefox/2.0 When we try close last tab when the option "Always show the tab bar" in dialogue [Tools] -> [Options] -> [Tabs] is turned on, the location bar loses focus. It make big sense at this situation to focus location bar -- as it takes place both on Firefox start and when we create new tab with CTRL+T. It is useful and it really make sense. Reproducible: Always Steps to Reproduce: Before reproduce make sure that the option "Always show the tab bar" in dialogue [Tools] -> [Options] -> [Tabs] is turned on. 1. Start Firefox with one tab open. One (empty) tab is open and the location bar has focus. 2. Press CTRL+W. One tab is as before open and empty, but location bar isn't focused anymore. Actual Results: The location bar loses focus though visual and functional statuses of browser and of the tab are the same as right after Firefox start. Expected Results: Location bar must (or very useful/expected-by-user at least) still have focus when user has tried to close last tab. This bug affects Firefox 2.0 at least builds of 2006-09-18, 2006-10-03, 2006-10-10. Probably it may be easily fixed before final Firefox 2.0 ships.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0 I can confirm this behaviour, and personally find it very annoying. Previous releases did not have this problem, so I hope it's an easy fix.

*** Bug 357113 has been marked as a duplicate of this bug. ***

*** Bug 358262 has been marked as a duplicate of this bug. ***

Well, in Firefox 2.0.0.1 it's like to be fixed with CTRL+W, but... clicking on close button of tab still discovers this bug.

In Firefox 2.0.0.2 RC5 this bug reappears.

Would have been a DUPE of bug 365394 if that one had worked out in the first place... marking it as regression of bug 348031 instead.

All it takes is launching our timeout after removeTab launched its own (through addTab and updateCurrentBrowser) to focus the content area. Drivers: Low-risk patch which just exchanges two statements to avoid the second voiding the first (that code path has been tested on trunk for several months now, see bug 348031 comment #12).

Replacing the patch from bug 348031 comment #51.

Comment on attachment 275367 [details] [diff] [review] back-out patch for bug 348031 while keeping this fixed This doesn't need approval at this stage.

mozilla/browser/base/content/browser.js 1.820

Simon: why did you cancel the approval request?

Because I shouldn't have requested it in the first place - this is no security/stability related issue, just some polish which doesn't even affect the default configuration.

https://litmus.mozilla.org/show_test.cgi?id=5003 in-litmus+

Well, this bug is live in Firefox 3 (even in latest nightlies -- Gecko/2008020904): if last tab is closed by Ctrl+W, then focus is in location bar (it's ok), but if we click on close button (!) of the last tab, then location bar focus is lost, and focus is on tab body (as I can consider by pressing Tab and Shift+Tab after clicking on tab close button and watching to order which Fx interface elements is focused according to). In Firefox 2.0.0.12 (Windows, clean new Fx profile) focus is lost on both Ctrl+W and Ctrl+Click. So, as I can see, the bug isn't yet fixed at all. Thanks.

(In reply to comment #14) > but if we click on close button (!) of the last tab, then > location bar focus is lost, and focus is on tab body Different steps to reproduce, different code path, different bug. IOW: Please file a new bug. > In Firefox 2.0.0.12 (Windows, clean new Fx profile) focus is lost on both > Ctrl+W and Ctrl+Click. See comment #12.

(In reply to comment #15) > Different steps to reproduce, different code path, different bug. > IOW: Please file a new bug. Ok, thanks you, Simon. Though it's strange to file a bug with the same title as already existing one and, in fact, with the same logical steps to reproduce (closing last tab -- eigther with shortcut or with equivalent button clicked). What is code path, I unfortunately don't know. > See comment #12. Only thing that I can consider from it is that this bug isn't important for you, but so what differences between the bug that *isn't* fixed at all and the bug fix for which exists but *is not reflected* in public builds? Thanks.