This is a follow-up bug from bug 565575, since the problem described there wasn't actually fixed. :) To reproduce: 1. open a new tab 2. cause it to loose focus by clicking in the content area 3. start typing, or switch to a different tab and switch back 4. keyboard input is ignored Recommendations: * if you start typing on a blank tab when it isn't focused, focus the URL field * if the search field or URL field is focused, retain this focus when switching back from a different tab (also related: bug 536576, a subset of this problem) * if you switch back to a blank, unfocused tab from another tab, make sure the URL field is focused It should never be possible to get a blank tab without focus — the easy way might be to just accept keyboard input and focus when it happens, or build logic to make sure it doesn't happen — I'll leave that decision up to you guys, they are equivalent as far as the UX goes.

(In reply to comment #0) > It should never be possible to get a blank tab without focus — the easy way > might be to just accept keyboard input and focus when it happens, or build > logic to make sure it doesn't happen — I'll leave that decision up to you guys, > they are equivalent as far as the UX goes. You mean it should never be possible for a blank tab's Awesome Bar to loose focus, right? In the way you phrased it looks like not letting the entire tab loose focus, which is not nice.

(In reply to comment #1) s/loose/lose/ >_>

(In reply to comment #1) > You mean it should never be possible for a blank tab's Awesome Bar to loose > focus, right? In the way you phrased it looks like not letting the entire tab > loose focus, which is not nice. No, it should respect whatever focus was there if any (ie. if you were in the search field), but if there is no focus, either accept keyboard input and autofocus the URL field when you start typing — or activate the URL field when you switch to the tab.

Will this be fixed for 3.6 ? or only for 4.0 ? :-( Sorry for posting the question here i hope there is no trouble.

(In reply to comment #4) > Will this be fixed for 3.6 ? or only for 4.0 ? :-( Sorry for posting the > question here i hope there is no trouble. 4.0 or later only.

The change is done in a do{...} while(false), don't know why so I didn't remove it.

Buu-Minh made his first patch at the Stanford Open Source Bootcamp! :)

Comment on attachment 527969 [details] [diff] [review] Patch This seems to lack significant parts of what this bug is asking for, e.g. "2. cause it to loose focus by clicking in the content area; 3. start typing [...]" or "if the search field [...] is focused, retain this focus when switching back from a different tab".

(In reply to comment #8) > Comment on attachment 527969 [details] [diff] [review] > Patch > > This seems to lack significant parts of what this bug is asking for, e.g. "2. > cause it to loose focus by clicking in the content area; 3. start typing [...]" > or "if the search field [...] is focused, retain this focus when switching > back from a different tab". This does get us improved behavior, though — although there are more cases we need to solve, we don't have to solve them all at once.

Filed a follow-up to handle the remaining issues, bug 652600.

Comment on attachment 527969 [details] [diff] [review] Patch Per comment 10

Landed: http://tbpl.mozilla.org/?rev=e0110ab48587 ... and backed out again because of test failures (test_bug493251.html, browser_addon_bar_shortcut.js, browser_bug427559.js, browser_bug462289.js, browser_bug565575.js).

gURLBar.focus() will also select the contents if the textbox had not been previously focused, so focusAndSelectURLBar() isn't needed for blank tabs. Test fixes coming next.

Comment on attachment 549310 [details] [diff] [review] updated to tip focusAndSelectURLBar was correct... The gURLBar.focus() behavior you're seeing depends on browser.urlbar.clickSelectsAll.

Oops, inserted a trailing space. I removed that on my local copy of the patch.

Comment on attachment 549321 [details] [diff] [review] patch v3 >+ // Focus the location bar if the tab is blank or, in non-fullscreen mode, >+ // if it was previously focused for that tab. >+ if (gURLBar && (newBrowser._urlbarFocused && !window.fullScreen || >+ isTabEmpty(this.mCurrentTab))) { Can you either reword that comment or make the code match the sequence currently described? E.g.: if (gURLBar && (isTabEmpty(this.mCurrentTab) || !window.fullScreen && newBrowser._urlbarFocused)) { >- if (!window.fullScreen) { >+ if (!window.fullScreen) > gURLBar.focus(); >- break; >- } else if (isTabEmpty(this.mCurrentTab)) { >+ else ------------------------^ trailing space

Does that patch actually provide some value over the first patch? The first patch seems to result in more readable code.

(In reply to Dão Gottwald [:dao] from comment #18) > Does that patch actually provide some value over the first patch? The first > patch seems to result in more readable code. I've become indifferent about this bug. If you have a patch in mind, feel free to write one, and I can review it.

The new tab page now contains focusable elements for accessibility.